Re: Coflict marker detection proposal

[Noel L Yap]

If conflict detection is to cause an error rather than a warning, then a "cvs
merged" command or equivalent would be appropriate to override the check.

Noel

>--- Forwarded mail from Greg Woods:

>> Then, as Paul suggested, CVS must provide a way to specify the conflict
marker
>> detection algorithm if it will allow pluggable diff/merge tools.

>Don't you think that's something for the person who designs a new
>CVS-like tool with "pluggable diff/merge tool" support to decide?

>I.e. it's totally irrelevant at this point.  No such tool exists!
>Arguing about its mythical features is a stupid waste of time.

Greg, you wrote the following:

--> Date: Thu, 12 Jul 2001 22:43:38 -0400 (EDT)

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

This whole debate spawned out this specific comment, requesting debate
about a possible new feature.  My proposal as it stands today, meets
both of your criteria:

1.  It does not break the design of CVS; existing functions are modified
to incorporate new capabilities (specifically, additional merge  and
conflict detection algorithms).

2.  It does not break backwards compatibility of the repository; in fact,
it makes no changes at all to the repository's format.

The revised merge algorithm remains unchanged from my original posting:

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

I'll amend the proposal to add the following:

After the merge completes and before the result is committed, the user is
expected to review any diagnostics produced by CVS and the merge tool, and
review and repair any files indicated as having conflicts.

CVS performs a pre-commit check to verify that conflicts encountered while
merging the contents of the file have been resolved.  This check tests a
couple of aspects of the file, namely its modification time in the filesystem,
and the presence of mark-up symbols embedded by the existing ASCII-based
merge algorithm.  This check will be left unchanged in the absence of -kb.
In the presence of -kb, the symbol check will be omitted because the merge
algorithm employed in that case does not perform a content merge of the
working file and thus does not introduce conflict mark-ups.

FUTURE ISSUES:  We recognize that this is not a general solution to the
merge problem.  It has been recommended in the past that a method be
introduced to CVS in which a site administrator be able to register merge
tools that are appropriate for the many data types that might be stored in
a CVS repository.  This recommendation remains, but with the stipulation
that such merge tools be paired with other tools that analyze the state of
merged files and notify CVS if merge conflicts have not been resolved (if
such a test is possible or appropriate for the data type at hand).

I believe that this has addressed all of Greg's concerns as well as
possible, in the context of not changing the existing user model.  If
the users are willing to invoke a command to explicitly notify CVS that
conflicts have been properly resolved, then Greg's suggestion of doing
so could be implemented in addition.  (Individual merge algorithms and
pre-commit checks could implement this themselves if necessary for their
specific data types, but doing so will add some burden to the user.)

I'd be interested in hearing from the lurkers on this subject.  If you
manage binary files, would implementing this proposal serve your needs
better than CVS currently does?

Greg:  Constructive criticism is welcome.  Vaccuous arguments that CVS
doesn't do it, that CVS was not designed to do it, that CVS should not do
it because you don't want or need it to, and comments about peoples'
ancestry and mental health are not constructive.  If you believe that
this discussion is a waste of time, then you may gracefully drop out.

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

_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs




This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.