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

[Kaz Kylheku]

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. 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.

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.

-- 
Meta-CVS: directory structure versioning; versioned symbolic links;
versioned execute permission; versioned property lists; easy branching
and merging and third party code tracking; all implemented over the
standard CVS command line client -- http://freshmeat.net/projects/mcvs