Re: conflicts, history, and the Principle Of Least Surprise

I'd just tlike to add a little paint to this bikeshed ...

I find two issues very important: one is handling of binary files, the
other is what to do with files that contain conflict markers.

We can't use diff3 for binary files, but it would definitely help to
have the various intermediate files around just like with a normal
merge, so that the user could chose which file to keep (or even manually
run an external merge tool).

For text files, it would be *really* nice if we could make sure that the
user can't accidentally commit a file that contains conflict markers.
Since scanning the file is typically not enough, I'd suggest that we
require some kind of user action to remove the "conflicted" state from
the file, e.g., "svn ci --force" (which should behave like "svn revert"
with --depth=0 and no implicit targets), or perhaps a new command (svn
resolve?) would do it. This command could also remove the merge source
files.

Now a small wish ... It'd be nice if "svn up" could take a --no-merge
option, so that it would *not* merge modifications into the working
copy, but would only set the conflict state and provide the various
versions needed for the merge. In fact --no-merge would be the default
(and only) behaviour for binary files.

Karl Fogel wrote:

>I've just reviewed the recent thread about whether we should put
>conflict markers in files, or continue using .rej files as we have
>been, or do something else entirely. There was no clear consensus,
>but some important principles nevertheless emerged. Although many of
>us started by saying "I do/don't like conflict markers", further
>discussion revealed the real issue to be a perceived tradeoff between
>convenience and information preservation -- people who like conflict
>markers lauded the ease of editing the newly marked-up working file,
>whereas people who don't like conflict markers were opposed to the way
>the working file gets all mucked up (i.e., information loss).
>
>Based on the discussion, here is a new proposal. Its guiding
>principles are that
>
> a) Update and merge should be consistent with each other in conflict
> handling [I hope this is not controversial!]
>
> b) We should (locally) preserve all information that could be
> useful in resolving the conflict.
>
> c) We should behave as similarly to CVS as possible -- the Principle
> Of Least Surprise. This is really important, and was not given
> enough attention in the previous discussion imho. There's no
> point being gratuitously different if we can be an intuitive
> superset instead.
>
>The proposal is simply:
>
> Updates and merges use 3-way diff. If there are conflicts, we put
> conflict markers into the working file, and save the following
> three files somewhere obvious: the old working file, the old
> text-base, and the new unmodified file (i.e., the right-side merge
> source, which in `svn update' is simply the new text-base).
>
> The conflict time is recorded in .svn/entries. At commit time, we
> error if the working file has not been modified since the conflict.
> Otherwise, we allow the commit, and automatically remove the other
> three files (which are just sitting in the working directory with
> intuitive extensions).
>
>Here is a more formal description of the above. First, definitions:
>
> OLD-BASE: The unmodified original revision of the file.
>
> MERGE-BASE: The left-side source of the merge; in updates,
> this is the same as OLD-BASE, in merges, it is
> usually not.
>
> MERGE-TGT: The unmodified new revision of the file. In
> updates, this also becomes the new text-base.
>
> OLD-WORKING: OLD-BASE + pre-merge local mods
>
> MERGED-WORKING: `diff3 -Em OLD-WORKING MERGE-BASE MERGE-TGT`
>
>If there were no conflicts, then the merge replaces OLD-WORKING with
>MERGED-WORKING (and in the update case, MERGE-TGT becomes the new
>text-base; but in the merge case, we simply don't keep MERGE-TGT).
>
>If there *were* conflicts, we still replace OLD-WORKING with
>MERGED-WORKING, but we also save OLD-BASE, OLD-WORKING, and MERGE-TGT
>in the working directory, with intuitive extensions. We remove them
>at commit time, if the commit succeeds. The commit does not succeed
>unless MERGED-WORKING has been modified since the conflict was
>received, or if --force is passed.
>
>(Also, "svn update" should probably remove those extra files whenever
>it touches a conflicted file, or maybe punt or otherwise behave
>specially on conflicted files; but that's bikeshed-painting at this
>point, we can perfect it later.)
>
>Note that this proposal does not preserve all the information when a
>*non*-conflicting merge is done into a locally modified file.
>Interestingly enough, no one seemed to consider that important. We
>seem to be paranoid about information loss in the conflict case only.
>Seems like a practical attitude to me, fwiw.
>
>Further Note: Yes, this does pretty much obviate the need for Sean
>Russell's nifty patchify.sh script. Sorry about that, Sean!
>
>I think this way pretty much addresses all the concerns raised. While
>awaiting comment, I'm going to proceed as if implementing the above
>proposal, since under the hood it doesn't differ greatly from other
>plausible solutions, and it's a lot easier to code for a known target
>than for a scatter plot :-). So don't panic if you see checkin
>comments referring to the above behavior as a goal.
>
>-Karl
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org