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