Re: Countering the usual diatribe against binary files, was cvs diff, proposal for change
>--- Forwarded mail from [EMAIL PROTECTED] >On Tue, 9 Sep 2003, Tom Copeland wrote: >> 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. >Not necesarily. Your project also depends on some operating systems and >libraries. You don't check in glibc2, the Linux kernel, or every >Windows DLL that your program uses. Your makefile needs GNU make 3.79 >or later, so better check that in too! I have worked in environments (in Unix) where the entire tool chain, along with compilers, system headers and libraries, standard utilities, and everything, were checked in and run in a chroot environment. I have personally version controlled the hardware, though not with CVS... (Sound crazy? Try building a product from scratch that's bug-for-bug identical to an earlier release after upgranding an operating system, then have the customer test it on an old installation. Believe me, it's far preferable to keep old build machines in mothballs.) >Sometimes it's okay for binary components and tools to come from >outside of the version control system, subject to some constraints like >``requires glibc 2.1.3 or later, and Linux kernel 2.4.43 or later''. Control what you can, remember what you can't. If you can match the proper tool chain with the source code then you don't have to check in the tools. Some people find it easier to check them in. My preference is to check in third-party products that contribute to the product in the way that source code does. Stuff like the tool chain and the OS I'm content to remember in the form of version numbers collected in a file that can be diff'ed at a later time. Whenever a build runs, it's sometimes useful to diff such data with that from the prior build to detect changes to the build environment. When reproducing an old build, I collect the data from the build host and compare it with that collected by the original build and flag differences as warnings. The data that I collect include things like the following: - The output of uname to get the OS major and minor version numbers. - A list of patches that have been applied to the machine. - Mount points, including automounts. - A list of installed packages and versions installed on the machine. - For tools not installed with the OS or in packages (e.g. Gnu tools), the version number as produced by a command line option. If no such option is available then I use a checksum. Ditto for libraries that I link with. Though I have not needed to track the following, I can see some value in doing so: - Sizes of memory, swap, and temp partitions. - License keys. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Countering the usual diatribe against binary files, was cvs diff, proposal for change
>--- Forwarded mail from [EMAIL PROTECTED] >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... I have never run into problems branching binary files, except for the "cvs update" command doing funny things when it thinks that diff3 is a reasonable merge tool for arbitrary data. But then, those situations are not expected to produce meaningful results, so no biggie. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Countering the usual diatribe against binary files, was cvs diff, proposal for change
On Tue, 2003-09-09 at 13:06, Kaz Kylheku wrote: > On Tue, 9 Sep 2003, Tom Copeland wrote: > > 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. > > Not necesarily. Your project also depends on some operating systems and > libraries. You don't check in glibc2, the Linux kernel, or every > Windows DLL that your program uses. Your makefile needs GNU make 3.79 > or later, so better check that in too! I think one difference here might be that it's difficult (impossible?) to have 2 versions of glibc on a machine, but it's quite simple to have 5 or 6 version of the BCEL jar file on a machine. Would you agree that it might be unreasonable to expect someone who wants to compile, say, Jakarta Tomcat, to have to download the source for and compile the dozen or so jars on which Tomcat depends? > Sometimes it's okay for binary components and tools to come from > outside of the version control system, subject to some constraints like > ``requires glibc 2.1.3 or later, and Linux kernel 2.4.43 or later''. I think we're slowly converging towards agreement... Yours, tom ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Countering the usual diatribe against binary files, was cvs diff, proposal for change
On Tue, 9 Sep 2003, Tom Copeland wrote: > 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. Not necesarily. Your project also depends on some operating systems and libraries. You don't check in glibc2, the Linux kernel, or every Windows DLL that your program uses. Your makefile needs GNU make 3.79 or later, so better check that in too! Sometimes it's okay for binary components and tools to come from outside of the version control system, subject to some constraints like ``requires glibc 2.1.3 or later, and Linux kernel 2.4.43 or later''. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Countering the usual diatribe against binary files, was cvs diff, proposal for change
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
Re: Countering the usual diatribe against binary files, was cvs diff, proposal for change
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
