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

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Friday, July 13, 2001 at 12:39:29 (-0400), Steven Rosenstein wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>>
>> Given all that you've stated below, it seems that the crux of your argument
>> turns on the ability of a file to be "mergable".  In my unadorned, pooh-like
>> brain, I ask the simple (and rhetorical) question, "why?"  Why can't I have a
>> simple switch which tells CVS that for this file or this directory or this
>> repository, I simply want to turn merging (and all CVS file manipulations)
>> *off*.  Period.  Nothing more.

>Well, if you just want to turn off merging completely then you have to
>come up with some way to tell CVS that you've done the merge manually
>and that there are no more conflicts so it's safe for "cvs commit" to
>procede.

All that CVS does today is to notify the user when it thinks there might
be a problem during the merge.  After that, it checks for hints that
there might have been a problem in the past and issues warnings.  This
second test is not robust, simply scanning for artifacts in the source
file that happen to resemble diagnostics inserted by the existing hard-coded
merge tool.

The existing CVS user model can be maintained without change, even if the
merge tool is swapped out with another, such as the trivial selection I
suggested.

Okay, it's possible that the user might commit an incorrect result of a
merge.  But how is that different from today's treatment of ASCII text?
The user must still build and test his code before committing, and that
should be sufficient to turn up any problems with the merge.

>I.e. if you tell CVS not to merge something when it thinks it has to
>then you've got to let it keep track of the fact that a manual merge is
>necessary and thus you've got to have a way of telling it that you've
>done the manual merge.

The existing warning of a conflict during the merge is sufficient to
alert the user to a possible problem.  CVS can assume that if the
file has been modified before a commit that the file is safe to commit.
If the user commits the wrong thing, shame on him.  But he can do that
anytime, regardless of whether or not a merge is involved.

>With automated merges the assumption is that if there are no conflicts
>then the merge was successfull and beyond whatever external criteria are
>placed on your development process, CVS is happy to commit the merged
>result unhindered.  You don't want that to happen though if you've
>disabled automated merges because then you would be allowed to do a
>commit without resolving the implied conflits in the un-merged files.

CVS should and does allow committing the result of a merge, even if
conflicts were not properly resolved.  Remember, only the user can
determine when conflicts have been correctly resolved; CVS cannot,
nor should it pretend to.

This behavior should exist regardless of the merge algorithm, be it
the existing RCS merge program, a trivial selection, or something else.

>I don't know exactly how best to indicate that the manual merge has
>successfully completed without conflicts though -- perhaps if a new
>subcommand were added "cvs merged", or a new option to "cvs update",
>which would change the string in the third field in CVS/Entries to
>something like "manual merge OK" and then "cvs commit" would look for
>that as the indicator that the ``conflict'' had been resolved....

I don't oppose this, but I also don't see the need for such a feature.
The existing behavior is adequate, and telling CVS explicitly that a
merge was completed outside of its process just adds an extra step for
the user to unblock commits.  I think it would be annoying, but livable.

>In the case for merges of branches I think the only thing you have to
>watch out for in addition is that CVS doesn't think the file still
>contains unresolved conflicts (I'm not sure of the status of this
>feature in CVS currently though).  Perhaps if your "switch" also turned
>off conflict detection that would be all that's needed.

>In the case of merges needed for concurrent edits the trick would be to
>just not ever do the "update" (i.e. not update the ancestor revision in
>the CVS/Entries file) and the user would then manually merge into a
>temporary file, remove the file and "cvs update" it (thus making CVS
>believe that the ancestor is the current head and that no merge was
>necessary), then move the merged copy into its place (thus making CVS
>think that there's only local changes to the file and no merge is
>necessary).

In other words, leave the file out of date and warn the user.  Leave it
to the user to futz with additional CVS commands pull out the relevant
versions into temporary copies and invoke the proper tool.  Finally,
the user must bring the file up to date in a second pass and install the
result of the merge on top of the up-to-date file.

My proposal, using the "checked-out" hint, accomplishes the same thing.
The difference is that it takes two steps to produce an up-to-date file
containing the result of a merge (update, merge), rather than six (update,
update -p, merge, rm, update, mv).

>Note that you'd have to do this on a per-file basis.  CVS doesn't manage
>directories, only the files within them.  (I suppose you could have your
>switch enabled as a sticky flag such that it's turned on for all files
>when you checkout or update a directory tree, but I'm not sure that
>would be sane except in a very narrow range of circumstances.)

>I'm not sure if '-kb' is the right "switch" to use here though.  The
>problem is that it would then have an even more over-loaded purpose that
>might at times be at cross purposes to this handling of manual merges.
>It would probably be better to add a new feature, and preferrably one
>that could be changed on a per-revision basis.  Perhaps a new "nomerge"
>state would be better.   I think this is one case where using a new
>state would not ever conflict with the "dead" state too....

I agree that the -kb switch is the wrong place to indicate the merge
behavior.  I've recommended all along that some notion of file type
be recorded in the RCS file.  I used -kb for my proposal just because
it exists today.

>This is, I think, very much different than Paul's strange '-kb' merge
>hint proposal.  In my proposal above the user simply always has to
>manually resolve the implied conflict of merge of a non-mergable file
>and there's no silly default to cause accidents and confusion.

Your proposal doesn't really do much other than to optionally disable CVS'
commit-time warning of a possible prior conflict.  It does not make the
issue of handling binary files easier.  You state explicitly that the
user must still perform the existing practice of performing binary merges,
plus add a new step.

My proposal simply swaps in an alternate merge algorithm for files that
do not contain ASCII text.  Because the alternate merge algorithm is a
switch, the hint is simply a declaration made in advance as to what the
desired selection should be in the event of a conflict.  Because the user
specifies the desired behavior, the result is totally predictable and
(assuming the user knows what he's doing) it is probably even useful.

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