info-cvs
[Top][All Lists]
Advanced

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

Re: How well does CVS handle other types of data?


From: Greg A. Woods
Subject: Re: How well does CVS handle other types of data?
Date: Sat, 14 Jul 2001 14:07:58 -0400 (EDT)

[ On Friday, July 13, 2001 at 21:19:06 (-0700), Paul Sander wrote: ]
> Subject: Re: How well does CVS handle other types of data?
>
> The existing CVS user model can be maintained without change, even if the
> merge tool is swapped out with another, such as the trivial selection I
> suggested.

You did not propose (most recently) any mechanism for swapping the merge
tool!

You proposed a silly and error-prone way to provide a default action for
the handling of conflicts in files declared to be unmergable by the fact
they have a sticky '-kb' flag set in the RCS file.

> Okay, it's possible that the user might commit an incorrect result of a
> merge.

MIGHT!?!?!?!?  It happens very regularly, even with expert users using
only text files!!!!!

>  But how is that different from today's treatment of ASCII text?
> The user must still build and test his code before committing, and that
> should be sufficient to turn up any problems with the merge.

Well, for one at least CVS tries to keep track of remaining conflicts in
normal text-based merges.  Your proposal seems to eliminate the
conflicts immediately and thus nearly guarantees that users won't even
know to look for potential problems in the specific affected areas.

The point of automated merging is to reduce the amount of energy that
would otherwise be necessary to handle frequent merges.

The success of automated merging in CVS is due primarily to the
limitation of using it _ONLY_ to manage content which can not only be
regularly merged using the Unix diff3 algorithms and in which conflicts
encountered during merges can be marked and in which the outstanding
conflicts can still be detected.

If CVS is to ever do anything better for handling some small amount of
non-mergable content then it MUST use its conflict tracking ability to
ensure that users are not only made clearly aware of the need to
manually "merge" some non-mergable file, but to also ensure that until
the user explicitly takes some declarative action to state explicitly
that the "merge" has completed successfully, no further action (either
update or commit) must be permitted against the unmerged file.

> The existing warning of a conflict during the merge is sufficient to
> alert the user to a possible problem.

No, it is not.  The initial warning is only just that -- an initial
warning.  CVS must now continue to detect that the conflict remains
until it has been explicitly resolved and in the mean time avoid doing
anything further that will "damage" the file.

>  CVS can assume that if the
> file has been modified before a commit that the file is safe to commit.

Maybe.  That's a very unix-centric view of the world though, and it's
not anywhere near a safe assumption even on a unix filesystem.

We've long known that CVS' reliance on timestamps is fraught with errors.

> If the user commits the wrong thing, shame on him.  But he can do that
> anytime, regardless of whether or not a merge is involved.

In this case CVS itself in effect created the scenario, just as it does
when it inserts merge conflict markers and extra changes into a working
file during a text merge.  It must now ensure that the user does
something to actually resolve the conflict that it created.

> CVS should and does allow committing the result of a merge, even if
> conflicts were not properly resolved.

Yes, it does, but that's a VERY MAJOR bug!  CVS MUST NOT allow files
with remaining conflicts to be checked in.  It also MUST NOT continue to
add new changes to files with unresolved conflicts.  CVS is only partly
successful in these respects now with text files (though it seems the
fixes I introduced yesterday in the version I use has greatly improved
its success at handling merge conflicts).

>  Remember, only the user can
> determine when conflicts have been correctly resolved; CVS cannot,
> nor should it pretend to.

CVS knows exactly when text-based merge conflicts have been resolved.

(the correctness of the resolution is obvioustly not in its domain)

> This behavior should exist regardless of the merge algorithm, be it
> the existing RCS merge program, a trivial selection, or something else.

If CVS is to better handle non-mergable files then it must maintain
external state indicating whether or not a conflict remains.

> In other words, leave the file out of date and warn the user.

Yes, exactly.

>  Leave it
> to the user to futz with additional CVS commands pull out the relevant
> versions into temporary copies and invoke the proper tool.

Well, the level of difficulty is only an artifact of the interface.

For the trivial cases where one of the three revisions in question is to
be used in place of doing something more sophisticated, a single command
can choose the correct version from one of the three available and
simultaneously mark the conflict as resolved.

>  Finally,
> the user must bring the file up to date in a second pass and install the
> result of the merge on top of the up-to-date file.

IFF the merge required some external tool, sort of -- the actual process
would be to simply call "cvs merged" or whatever after the external tool
has created the result.

> My proposal, using the "checked-out" hint, accomplishes the same thing.

No, it absolutely does not!  You've provided a "default" action which is
guaranteed to produce the wrong result at some point thus ensuring that
either a mistake is made (i.e. the wrong result is committed), or that
the user has to go to further 

> The difference is that it takes two steps to produce an up-to-date file
> containing the result of a merge (update, merge), rather than six (update,
> update -p, merge, rm, update, mv).

If the user-interface is too complex then front-end tools are trivial to
design and implement....  Think of the command-line CVS as an assembler
with many small bits that can be put together to do complex actions.

> I agree that the -kb switch is the wrong place to indicate the merge
> behavior.  I've recommended all along that some notion of file type
> be recorded in the RCS file.  I used -kb for my proposal just because
> it exists today.

Well, even proposing '-kb' is short-sighted as it instantly assumes the
file has one type throughout the lifetime of its name!

> Your proposal doesn't really do much other than to optionally disable CVS'
> commit-time warning of a possible prior conflict.

huh?  that's completely wrong -- completely opposite of what I said!

>  It does not make the
> issue of handling binary files easier.

That's a blanket statement that has no meaning in this context.  CVS
does not handle non-mergable files well at all so anything which makes
it possible to reliably handle them in a manner that's not error prone
is an improvement, no?

>  You state explicitly that the
> user must still perform the existing practice of performing binary merges,
> plus add a new step.

Yes, that's the key (though the "new step" can be combined in the case
where there's no actual "merge" activity to be performed).  This is
simply an extension of the conflict marker to file types in which
conflict markers and conflicting changes cannot easily be inserted.

Unlike your proposal the resolution is always explict and at the
discretion of the user.

> My proposal simply swaps in an alternate merge algorithm for files that
> do not contain ASCII text.  Because the alternate merge algorithm is a
> switch, the hint is simply a declaration made in advance as to what the
> desired selection should be in the event of a conflict.

Paul either you're misleading people purposefully, or you're getting
lost here yourself.  We're not talking here about an "alternate merge
algorithm"!  We're talking only about merge conflict resolution.  Your
most recent proposal does not add any new merge technique, nor does
mine.  You've simply proposed a fault-prone mechanism for doing a
default conflict resolution action when a non-mergable file is
encountered during a merge and I've proposed a more explicit mechanism
for managing the conflict state when "merging" non-mergable files.

>  Because the user
> specifies the desired behavior, the result is totally predictable and
> (assuming the user knows what he's doing) it is probably even useful.

No, in your proposal the user does NOT specify a "desired" behaviour.
They specify a DEFAULT behaviour.  The result, while predictable and
potentially useful in some narrow application domains, is just as easily
incorrect.  Your proposal omits the key requirement of forcing the user
to finalize the conflict resolution.

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