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