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

[Jeff King]

> From: address@hidden [mailto:address@hidden Behalf Of
> Thornley, David
> Sent: Wednesday, July 11, 2001 12:35 PM
> To: address@hidden
> Subject: RE: How well does CVS handle other types of data?
> 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.

Exactly. "Source code" and "binary data" are quite conceptually different.

> 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?

A CVS repository for source code and a network directory for binary data
with an established, enforced naming and access procedure.

> 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....

That depends on the filetype. Merging Word files is easy, as it's simply a
binary format for text. But how exactly would you merge a JPEG? It doesn't
make sense.

> 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.

I agree, assuming we're talking about datatypes that can be automatically
merged with a reasonable process.

> 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.

This makes no sense. Supposed you have a blank bitmap for a "tools" icon.
Two people make concurrent changes to it: the first person draws a hammer,
the second person draws a screwdriver. How could this be merged? You don't
want some weird hammer-screwdriver hybrid. You need to manually choose which
version to use. This is why having a separate, manually controlled directory
structure for binary data is the best solution.

> And a lame script will make merging GIFs easy?  You're not making sense
> here.

No, the concept of merging GIFs at all is what's not making sense.