[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Sander
Subject: Re: How well does CVS handle other types of data?
Date: Sun, 15 Jul 2001 14:04:47 -0700

>--- Forwarded mail from Greg Woods:

>[ On Friday, July 13, 2001 at 21:19:06 (-0700), Paul Sander wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>> 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.

>You did not propose (most recently) any mechanism for swapping the merge

>You proposed a silly and error-prone way to provide a default action for
>the handling of conflicts in files declared to be unmergable by the fact
>they have a sticky '-kb' flag set in the RCS file.

There's a difference between the two?  My proposal replaces the ASCII
text-based merge with a trivial selection in the presence of -kb, with
user specification of conflict resolution.  That is most definitely a
replacement of the merge algorithm.

>> Okay, it's possible that the user might commit an incorrect result of a
>> merge.

>MIGHT!?!?!?!?  It happens very regularly, even with expert users using
>only text files!!!!!

You mean, they don't compile and test their code before committing it?
My, my.

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

>Well, for one at least CVS tries to keep track of remaining conflicts in
>normal text-based merges.  Your proposal seems to eliminate the
>conflicts immediately and thus nearly guarantees that users won't even
>know to look for potential problems in the specific affected areas.

When CVS performs a merge, it displays diagnostics indicating the merge
status.  Users are expected to read and comprehend those diagnostics.
In that context, how can they possibly not know where to look for
potential problems?  CVS tells them what specific files are suspect
during the merge.

>The point of automated merging is to reduce the amount of energy that
>would otherwise be necessary to handle frequent merges.

>The success of automated merging in CVS is due primarily to the
>limitation of using it _ONLY_ to manage content which can not only be
>regularly merged using the Unix diff3 algorithms and in which conflicts
>encountered during merges can be marked and in which the outstanding
>conflicts can still be detected.

The diff3 stuff is just an artifact of the implementation.  There are
other options.  If the merge algorithm can be replaced, then so can the
pre-commit conflict detection algorithm.

Right now, the pre-commit conflict detection algorithm is "grep '^>>>>>>> '".
I claim that for binary files, one viable choice for that algorithm right
now is /bin/false, thus requiring the user to read CVS' diagnostics during
the merge.

>If CVS is to ever do anything better for handling some small amount of
>non-mergable content then it MUST use its conflict tracking ability to
>ensure that users are not only made clearly aware of the need to
>manually "merge" some non-mergable file, but to also ensure that until
>the user explicitly takes some declarative action to state explicitly
>that the "merge" has completed successfully, no further action (either
>update or commit) must be permitted against the unmerged file.

>> The existing warning of a conflict during the merge is sufficient to
>> alert the user to a possible problem.

>No, it is not.  The initial warning is only just that -- an initial
>warning.  CVS must now continue to detect that the conflict remains
>until it has been explicitly resolved and in the mean time avoid doing
>anything further that will "damage" the file.

Fine.  We make it a requirement that, if a new merge algorithm is
implemented, then a matching conflict detection algorithm must also
be implemented.  This is a general solution to the problem you raise.

[skipping a bunch of stuff that becomes moot in light of the above...]

>>  Leave it
>> to the user to futz with additional CVS commands pull out the relevant
>> versions into temporary copies and invoke the proper tool.

>Well, the level of difficulty is only an artifact of the interface.

Let's change the interface, then.  I've made one proposal that simplifies
things for the user, amended above to address your concerns.

>For the trivial cases where one of the three revisions in question is to
>be used in place of doing something more sophisticated, a single command
>can choose the correct version from one of the three available and
>simultaneously mark the conflict as resolved.

Are you willing to invoke that command for every file in which conflicts
are detected?  Even ASCII text?

The reason I ask is because I want the CVS interface to behave identically
from the user's point of view, regardless of what type of data is being
used.  Telling the user that they must do a "cvs merged" for some kinds of
files and not others is too confusing; the update/edit/compile/test/commit
loop must not sometimes be update/edit/compile/test/merged/commit.

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

>IFF the merge required some external tool, sort of -- the actual process
>would be to simply call "cvs merged" or whatever after the external tool
>has created the result.

>> My proposal, using the "checked-out" hint, accomplishes the same thing.

>No, it absolutely does not!  You've provided a "default" action which is
>guaranteed to produce the wrong result at some point thus ensuring that
>either a mistake is made (i.e. the wrong result is committed), or that
>the user has to go to further 

There's nothing "default" about it.  The user specified the action he
wanted.  This is, from CVS' point of view, not a mistake.  We can't
stop the user from saying the wrong thing.

During the merge, the user is told where the conflicts are.  CVS leaves
it to the user to do the right thing with the output of the merge.

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

>Well, even proposing '-kb' is short-sighted as it instantly assumes the
>file has one type throughout the lifetime of its name!

Well, my opinion on this is well known:  A file's lifetime is determined
by its entire revision history, not by its location in the filesystem.
Let's not get into that argument here.

I believe that a data type specification must be made as a neewphrase
in the admin section of the RCS file.  CVS has no provision for that
at this time, so the next place to look for now is at the -kb switch.

>>  You state explicitly that the
>> user must still perform the existing practice of performing binary merges,
>> plus add a new step.

>Yes, that's the key (though the "new step" can be combined in the case
>where there's no actual "merge" activity to be performed).  This is
>simply an extension of the conflict marker to file types in which
>conflict markers and conflicting changes cannot easily be inserted.

>Unlike your proposal the resolution is always explict and at the
>discretion of the user.

I claim that it's unnecessary, because the user already knows when he's
resolved merge conflicts, and CVS should not try to second guess him.
Adding the new step is just another overhead that gets in the user's way.

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

>Paul either you're misleading people purposefully, or you're getting
>lost here yourself.  We're not talking here about an "alternate merge
>algorithm"!  We're talking only about merge conflict resolution.  Your
>most recent proposal does not add any new merge technique, nor does
>mine.  You've simply proposed a fault-prone mechanism for doing a
>default conflict resolution action when a non-mergable file is
>encountered during a merge and I've proposed a more explicit mechanism
>for managing the conflict state when "merging" non-mergable files.

I've been saying for a long time that any file is trivially mergeable.
That means that any file can be merged using a trivial selection algorithm.
This is no different than having a text file in which 100% of the content
has been changed.  The user chooses one version or the other.

My proposal is to formalize this, and make it actual merge algorithm in the
presence of -kb.  The conflict concerns are the same, and the treatment of
conflicts is the same.

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

>No, in your proposal the user does NOT specify a "desired" behaviour.
>They specify a DEFAULT behaviour.  The result, while predictable and
>potentially useful in some narrow application domains, is just as easily
>incorrect.  Your proposal omits the key requirement of forcing the user
>to finalize the conflict resolution.

This makes no sense.  The user specifies the treatment of the files in
the presence of conflicts in such a way that the output of the merge can
at least be opened by the user's tools.  And not only that, the user has
specified what he expects to see when he opens that file.

Okay, maybe he needs to make changes to the file.  So be it.  The same
thing happens when merging ASCII text.

If it's soooo important that CVS block commits until it thinks the user
has done the right thing (despite what the user thinks), then the conflict
detector can be made to be more appropriate to the data type.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]