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

[Paul Sander]

>--- Forwarded mail from address@hidden

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

Source code is anything that can't be derived automatically from something
else; it's the definitive source of some aspect of a project.  Source code
can take any form, but CVS best supports source code that's ASCII text.

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

This does not work under the following circumstances:

- You need several versions of the same files to be available concurrently.
- The binary files are part of the development effort.

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

Here are a couple of ways the come to mind immediately:

- Select one of the three contributors.
- Load all three into a graphical editing tool on different planes, and
  bring all of the available graphical manipulations to bear.

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

Do the merges really need to be automatic?  That's the current CVS user
model, but there is great demand to have CVS run interactive merge tools
instead.

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

No, having an appropriate merge tool is the best solution, and CVS should
be extensible enough to register it and map it to the proper data types.

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

It makes perfect sense, given the context that GIFs are source code and
demand the same treatment as text.

>--- End of forwarded message from address@hidden