[Top][All Lists]
[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
>
- Re: Coflict marker detection proposal, (continued)
- Re: Coflict marker detection proposal, Noel L Yap, 2001/07/16
- RE: Coflict marker detection proposal,
Jimmy Rimmer <=
- Re: Coflict marker detection proposal, Noel L Yap, 2001/07/17
- Re: Coflict marker detection proposal, Noel L Yap, 2001/07/17
- Re: Coflict marker detection proposal, Noel L Yap, 2001/07/17
- Re: Coflict marker detection proposal, Noel L Yap, 2001/07/17
Re: Coflict marker detection proposal, Noel L Yap, 2001/07/17