Red Hat Bugzilla – Bug 190482
cvs-import.sh puts very large binary! files in CVS
Last modified: 2009-09-14 09:54:44 EDT
Description of problem:
This has been discussed somewhat on f-e-l: I've created a package of the
background music for a game which I've packaged and once the packages was
approved I ran cvs-import.sh on the SRPM. Source0-Source3 were large (1-10Mb)
.ogg files still cvs-import.sh decided to put them in CVS.
_Large_ binary files in CVS
Only text files in CVS, or atleast not _large_ binary files.
I've seen cvs-import do the same with smaller .ogg files and .png's used as icons.
I'd be happy to fix this up but I'd like to know more about what the dev's would
expect the script to do. What should happen to large binaries that are SourceX?
How big is a large binary? How do we notify the user that they have to do
something different with those binaries?
(In reply to comment #1)
> What should happen to large binaries that are SourceX?
Same as with Source0: put in the lookaside cache
> How big is a large binary?
I tend to say all binaries belong outside of CVS. But sometimes a package
contains a small .png as icon. That could stay in CVS I guess so say anything >
> How do we notify the user that they have to do
> something different with those binaries?
We don't upload them to the lookaside cache, put them in sources and .cvsignore
and things should then just work as normal.
Notice that some time ago I got hit by this again, with a multiple MB large .bz
file, I think the current script works with file extensions, so atleast at .bz
to the list.
A better / real fix would be very welcome.
Here's the problem, stuff that goes into cvs is version controlled. Stuff that
goes in the repo is not. I'm under the opinion that anything written by us
(something not upstream) should go in cvs and not the repo.
Then how about putting files with a full URL in the look-aside and the rest in CVS?
Also here is my problem:
get a 10 Mb mail from the commit as the commit mail contains a copy of some blob
as new in CVS file
(In reply to comment #4)
> Here's the problem, stuff that goes into cvs is version controlled. Stuff that
> goes in the repo is not. I'm under the opinion that anything written by us
> (something not upstream) should go in cvs and not the repo.
Even though it's not directly version controlled, we'll keep all the old
versions around. They're stored on the server side in paths based on the
md5sum. And given that they're binary files, that's not any more or less space
efficient than directly in CVS.
And it's definitely nice from the POV of not generating monster commit mails +
being easier to upload/download efficiently.
If it's fine with the dev's its fine with me. If someone submits a patch it
will greatly speed this fix up, otherwise I'll get to it in the next couple of
Ugh, still not fixed, I got hit by this while trying to import a soundfont
package, where the source tarbal is a .sf2 (soundfont2) file, so it wanted to
put a 33MB file in cvs!
Luckily cvs-import.sh is interactive now a days so I could abort it before it
actually did that.
Hi, is this fixed now? If not, can you please close this and file a ticket at https://fedorahosted.org/fedora-infrastructure/ (login with your FAS credentials)? We aren't using bugzilla for tracking Infrastructure tasks anymore.
Closing this out, please reopen if needed.