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

[Paul Sander]

>--- Forwarded mail from Greg Woods:

>[ On Friday, July 13, 2001 at 11:06:30 (+1000), Sven Dowideit wrote: ]
>> Subject: RE: How well does CVS handle other types of data?
>>
>> Greg - what is wrong with providing extra support for non-mergable files?

>There wouldn't be any problem if you could do it without breaking either
>the design or backwards compatability of the repository....

>I invite you to write both a concrete detailed implementation proposal,
>as well as perhaps an example implementation, if you think otherwise.

Okay, I will do so now:

Whenever a merge is required, check if the -kb keyword expansion flag
is applicable.  If it is (via command line, .cvsrc, or RCS file, in that
order), use an alternate merge method as described below.  Otherwise,
retain existing behavior.

If the -kb option applies, then the following cases happen:

1.  All three versions are identical (either identical versions, or bit-for-
    bit identical).
2.  The contributor differs from the ancestor and checked-out copies, which
    are identical.
3.  The checked-out copy differs from the ancestor and contributor, which
    are identical.
4.  All three differ.

The user supplies a hint to the client, via command line, environment, or
other means, that determines how to resolve conflicts.  The hint has one
of five values:  ancestor, contributor, checked-out, oldest, and newest.
The "ancestor" value indicates that the common ancestor replaces the
checked-out copy, discarding both changes.  The "contributor" value indicates
that the contributor to the merge replaces the checked-out working copy,
discarding local changes.  The "checked-out" value indicates that the
checked-out working copy is left alone.  The "oldest" value causes the
contributor to replace the checked-out working copy if the contributor
is older than the checked-out copy.  The "newest" value causes the
contributor to replace the checked-out working copy if the contributor
is newer than the checked-out copy.  The age of the contributor version
is extracted from the RCS file.  The age of the checked-out working copy
is determined by its modification time in the filesystem.

In case 1, the checked-out copy is left alone, and the merge indicates
success.

In case 2, the hint is used to determine which version of the file
replaces the checked-out working copy.  If the checked-out working
copy changes, its original content is renamed.  The merge indicates success.

In case 3, the checked-out copy is left alone, and the merge indicates
success.

In case 4, the hint is used to determine which version of the file
replaces the checked-out working copy.  If the checked-out working
copy changes, its original content is renamed.  The merge indicates a
conflict.

Note that CVS already performs all of these computations already.  All
that is needed is to test the -kb option and replace the RCS "merge"
program with the appropriate copy.

A better implementation could send the ancestor and contributor versions
to the client (as needed), along with the data type, and have the client
invoke the proper merge tool.  The data type could be stored as a newphrase
in the RCS file.  But this is not required for an initial implementation.

>> Would it not be more useful to be able to set a file to be non-mergable, and
>> then add support to require a lock to be placed on that file before changes
>> can be allowed to be committed.

>You really can't do that without breaking the design and the
>expectations it sets for users.

In other threads in the past, I've shown that adding locking does neither
of these.  But that's another argument that I won't get into here.

>> The only remaining issue would be the merging of branches, and again this
>> seems trivial - simply leave it up to the user to decide what to do!

>That's where we're at now and that's why this stupid issue keeps rearing
>its ugly head.

CVS could help a little bit, as shown above.

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