info-cvs
[Top][All Lists]
Advanced

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

RE: Coflict marker detection proposal


From: Jimmy Rimmer
Subject: RE: Coflict marker detection proposal
Date: Mon, 16 Jul 2001 18:31:48 -0700

This looks like a great idea.

The tail should NEVER wag the dog in software.  The tools should adapt to
meet the needs of their users, not the other way around.

-----------------------------------------------------------------------
 Jimmy Rimmer, Software Engineer           address@hidden
-----------------------------------------------------------------------
"Keeping a positive attitude, if nothing else, will annoy enough people 
 along the way to make it worth the effort."                 --Lord Hep


> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> Sent: Monday, July 16, 2001 5:10 PM
> To: address@hidden
> Subject: Re: Coflict marker detection proposal
> 
> 
> >--- 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
> 



reply via email to

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