Re: Countering the usual diatribe against binary files, was cvs diff, proposal for change

[Tom Copeland]

On Tue, 2003-09-09 at 12:12, Kaz Kylheku wrote:
> On Tue, 9 Sep 2003, Tom Copeland wrote:
> > On Mon, 2003-09-08 at 16:00, Greg A. Woods wrote:
> > > I can import gigabytes and terabytes of binaries into CVS too, but no
> > > matter how much I try I'll never be able to use branches meaningfully in
> > > such a repository, 
> > 
> > Hm.  Do CVS branches not work right with binary files?  I've used
> > repositories that had lots of binary files (mostly jar files) checked
> > into them with lots of branches and haven't seen problems yet...
> 
> JAR files are derived objects, not primary objects.

Right... although in the case of 3rd party libraries, the line gets a
bit blurry.  If my project depends on, say, BCEL, I think it's
reasonable for me to check the BCEL jar file into my module/lib
directory.

>  You never have to
> care that derived objects are not mergeable, because you merge their
> corresponding primary objects (.java source files, in this case) and
> rebuild the derived objects.  These newly generated derived objects
> are then checked in.

Right on, for my code, yup.  3rd party jars are, I think, another
matter.

> It's usually a bad idea to add derived objects, such as compiled object
> files, to the version control system. From time to time it's
> justifiable; for example, if you have some large body of stable code
> that changes infrequently, it can save you time not to recompile it, at
> the cost of a larger repository and longer checkout time.

Yup, I think 3rd party jars are in this category.

But back to the original question - is there any reason why a branch
would not work with a binary file?  I haven't seen any problems yet...

Yours,

Tom