RE: How well does CVS handle other types of data?

[Thornley, David]

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> 
> [ On Wednesday, July 11, 2001 at 08:52:37 (-0500), Daniel 
> Beckham wrote: ]
> > Subject: Re: How well does CVS handle other types of data?
> >
> > Greg, as someone else pointed out.  It's a rare project 
> that does not have a
> > few binary files peppered in the source for various 
> 
> The more rare the binary files, the more sense it makes to keep them
> separately.
> 
Why?  It may make sense to you, with your applications, but I don't
see that it makes sense for mine.  I would rather group conceptually
related files together rather than files of the same datatype.

> The more common the binary files, the more sens it makes to use
> something other than CVS (if not for them then for everything!)
> 
OK, what?  For my purposes, it has to support concurrent development
and branching, and right now my company isn't going to spend gobs
of money.  It has to be reliable.  Heck, it has to be widely used
and considered reliable.  The source code repository here is very
valuable, and we don't want to take chances.

So, given these constraints, what should I use?

> It's irrelivent whether or not you "need" to merge binary files.  You
> may *have* to!!!!  If you use branches, and if changes to binary files
> are made on branches then you _MUST_ "merge" them!!!  CVS 
> simply cannot
> do that and the only way to resolve the conflict is to choose one
> revision.

And the version control system that allows branching and makes it
relatively painless to merge binary files that get changed in a merge
would be....

We've got to have branching.  We can put up with a certain amount of
pain with merging if we have to.  I think CVS does the best possible
thing here.

Consider a GIF that is changed on a branch and (in a different manner)
the main trunk.  Where is the tool that will merge it like CVS merges
text files?  Does it also work with PNGs and JPEGs?  Any other binary
files we're likely to need?  If you know of such a tool, I want to
find out about it.

  If you're lucky there'll only be one or two such conflicts
> during a branch merge and manual cleanup is easy.  However if 
> you've got
> dozens of GIFs, for example, and you end up with a conflict on each,
> then you're in for a much more difficult cleanup.
> 
> > And in rebuttle to your comment.. there is no right tool 
> for the job.
> 
> What are you talking about?  Of course there's a "right" tool, even if
> its some lame script you write that used gtar over SSH and carefully
> named files and directories!
> 
And a lame script will make merging GIFs easy?  You're not making sense
here.

For any job of reasonable complexity, a lame script is not the right tool.
I think version control counts as reasonable complexity.

For many jobs, there just isn't a right tool.  For some, there is a right
tool,
but accumulating all the "right tools" is impractical.

I think it more appropriate to think in terms of a "best" tool, not a
"right" tool.  For many scenarios that involve binary files, CVS is the
best tool I know of.  Being told to drop CVS and write a lame script
that keeps track of versions by dated tarball sounds to me a lot like
using a worse tool, not a better.

(Disclaimer:  on the Plato-Aristotle axis, I'm a firm Aristotelian who
carries and uses a Swiss Army knife.  YMMV.)