[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: binary files bad idea? why?

From: Greg A. Woods
Subject: RE: binary files bad idea? why?
Date: Mon, 5 Jul 2004 17:38:27 -0400 (EDT)

[ On Friday, July 2, 2004 at 22:25:27 (-0400), Eric wrote: ]
> Subject: RE: binary files bad idea? why?
> At 2:11 PM -0400 7/2/04, Greg A. Woods wrote:
> >Why is it so damn hard for everyone to keep this simple fact in mind?
> Because it is entirely possible to use CVS in a manner where this 
> simply isn't an issue.

Ah ha!  So, we finally get back around to this issue!  What a long trip
it has been!  ;-)

Now if you remember what I stated at the beginning then you'll realize
just exactly why what you've said above is the wrong answer.

Don't put binary files into CVS and expect it to work 100%.

CVS cannot detect and manage changes in any meaningful way in files that
are not organized as lines of text, and many of the most common and most
important delta management operations that CVS does involve three-way
merges of deltas with the hope and expectation of avoiding conflicts in
those merges.  One seldom-changing binary file in a large project
(e.g. thevery few found in all of the NetBSD source tree) isn't an issue
provided the human management of the project contributors keeps a sharp
eye out for problems with these files (e.g. through peer pressure in the
NetBSD group, combined with the fact that most/all of those binary files
are "owned" by one developer).  However the more binary files your
project has, the more times they are changed, the more diverse the
working directory hosts, then the more problems binary files will cause
if they are committed to a CVS repository.  Putting binary files in CVS
is a bad idea, always was, and always will be.

I.e. unless you have extremely pressing reasons for including binary
files in your repository (e.g. as in NetBSD they are very rare and
extremely stable and "owned" by one developer and because NetBSD also
strives to use CVS as a source distribution tool), then it's best to use
other tools and procedures for managing your binary files outside of CVS.

Don't put binary files into CVS and expect it to work 100%.

Use the most appropriate tools for the job.

CVS is not a complete software configuration management system.

> Furthermore, CVS does provide some facilities to use it in a 
> non-concurrent manner adding further protections.

No, not really -- some of what's there doesn't work right and the rest
is a bunch of half-baked add-on hacks that don't meld with the design or
goals of CVS and which, as proven by this ever repeating cycle of
discussion, causes more confusion and more headaches to naive users than
could ever be made back in long-term benefits to anyone.

Ultimately this is the core problem with true open-source software --
there are just way too many cooks in the pot.  CVS could have been ever
so much more for those using it in the way it was designed if it hadn't
been for so many people trying to fiddle with things they obviously
never really understood deeply enough.

> If you know what you are doing and what to expect, clearly using CVS 
> and binary files will never be a problem.

Well, that might be true for a computer, were there ever a full SCM
system that used CVS internally, but it will never be true for humans,
especially those that don't have a deep enough grasp of fundament SCM
principles (which means almost everyone since it seems they still don't
teach SCM well enough at anywhere near the number of the places where
computer programming is taught and most programmers still don't have the
slightest clue about SCM, with some even having trouble with the most
basic versioning schemes!).

                                                Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]