Re: giving up CVS

[Kaz Kylheku]

In article <address@hidden>, Greg A. Woods wrote:
>[ On Friday, September 14, 2001 at 14:25:41 (-0500), Thornley, David wrote: ]
>> Subject: RE: giving up CVS
>>
>> Almost by definition, you lose the main reason for considering CVS.
>> This does not necessarily make it a losing proposition.
>
>That alone does not.  However all the other things CVS is, and is not,
>together make it a losing proposition for use in tracking changes to
>unmergable files.

What exactly do you mean by ``tracking''? CVS can ``handle'' unmergeable
files in a reasonable way. It can store version of them, allow you to
tag them, branch them, retrieve past versions and all that.

CVS can trivially merge a binary file change, when the substrate
against which it is being merged has not changed: e.g. the binary file
has changed in the branch, but not the trunk. No problem, the branch
version supersedes and everything is cool.

In cases where the merge cannot be done because the substrate has changed,
you are given both versions of the file, and can choose either one, or
do some kind of blending betwen them using external tools, if possible.
At least CVS identifies the conflicting files and gives you the relevant
objects involved, thereby establishing a clear context for you to take
some action.

This level of support is adequate for many kinds of binary objects that
may occur in a software project, such as GUI icons or what have you.

If someone changes an graphic image on a branch, and someone else on
the trunk, the two can get together in some run-down cafe, and sort out
their artistic differences over a capuccino. :)