RE: cvs update; merge

[Thornley, David]

> -----Original Message-----
> From: Andreas Lindgren [mailto:address@hidden
> Sent: Thursday, August 30, 2001 6:02 AM
> To: address@hidden
> Subject: RE: cvs update; merge
> 
> 
> 
> Larry Jones writes:
> > > moral:   If you are using any binary files across 
> > platforms, default should
> > > be binary, not ascii.
> > 
> > Real moral: Don't use CVS for binary files.
> 
> We are moving from VSS to CVS (at last) and have a "culture", 
> or working
> process, among the developers how the source handling works. 
> One of the
> things in that process is that we have one build machine for each
> platform which does daily builds. The resulting build targets and
> installation kits are checked into the version handling 
> system for later
> tracing, e.g. to have the source code label automatically match a
> specific build.
> 
I don't see why you'd need to check the build in.  For this purpose,
CVS is about as useful as properly named tarballs (or zip packages,
if you're on MS Windows, I guess).  You should have the sources for
any significant build tagged, of course, but there's no advantage in
checking in the build.

> Are there any negative effects (except for the repository growing in
> size) of keeping this kind of binaries within CVS?

Not as far as I know.

 We do not have need
> for merging (neither of version branches nor simultaneous edits), or
> using any cross-platform features except maybe for .pdf files 
> which are
> generated on one platform, but included in the distributions on all
> platforms. In other words, the versioning system are for the binaries
> only a storage for history.
> 
This leaves me wondering why CVS?  You don't want to do anything it's
particularly good at, and do want to do things it's no better at than
any other version control system, and worse than some.  Concurrent
development
with automatic merge is a big win, as is the branch management with merge
(not so automatic), and those make CVS worth using even when it isn't
really well suited for other things you're doing.  Are you at least hoping
to get developers to do things concurrently or thinking that branches
might be useful in the future?

If not, you're basically asking how best to misuse CVS, and the support
from this list (which I greatly value) is going to be much less valuable
to you.  Perhaps Greg should repost a list of C/S version control systems
that support nonconcurrent editing better than CVS and may store binaries
better.

> I have now gotten acceptance and resources to switch from VSS 
> - I would
> hate to have to take a step back here...
> 
Not that I'd want to encourage anybody to continue using Microsoft products
in such a critical area, but there's got to be systems better for your needs
than both VSS and CVS.