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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs