[Top][All Lists]

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

Re: Coflict marker detection proposal

From: Greg A. Woods
Subject: Re: Coflict marker detection proposal
Date: Mon, 16 Jul 2001 22:55:29 -0400 (EDT)

[ On Monday, July 16, 2001 at 17:10:24 (-0700), Paul Sander wrote: ]
> Subject: Re: Coflict marker detection proposal
> 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:

Your recent proposal is not the same as your earlier 'pluggable'
diff/merge proposal.  If even you can't keep them straight in your head,
how are you ever going to implement even one of them?

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

I never debated those issues.  (and I agree your recent proposal does
not violate those requirements)

However your recent proposal is a lame hack.  It's definitely not a new
merge algorithm, just a lame way to provide a default conflict
resolution strategy that leaves the user in an even more error-prone
situation than they're in with CVS today.  It does nothing to actually
solve the problem of handling unmergable files in a way suitable for
generic use.

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

I don't see how that solves anything, or really even changes anything
from what CVS does now.

> 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 suspect nothing's going to happen down either avenu until you show
"running code and consensus".....

> Greg:  Constructive criticism is welcome.

I gave a rough sketch of my counter proposal.  I've heard no complaints
about it yet....

                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>

reply via email to

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