[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Patch command execution

From: Zack Weinberg <zack_at_codesourcery.com>
Date: 2002-02-08 22:09:28 CET

On Fri, Feb 08, 2002 at 08:59:55AM -0600, cmpilato@collab.net wrote:
> That's correct. I means that conflict resolution is this simple:
> edit out the conflict markers in working_file.00000.12345.rej
> rm working_file
> mv working_file.00000.12345.rej working_file
> So it gives the same beautifully easy CVS conflict resolution
> mechanism plus protection against checking in bogosity (without at
> least some human intervention).

After some thought and IRC discussion, it seems to me that a modified
version of this concept is best.

svn update runs the equivalent of diff3 -E wc gca latest > wc.conflict.
The -E switch mimics what CVS does. There is also -A, which puts more
information into the conflict file, but that could potentially be more
confusing - I'm happy to make that available through user preferences,
but don't think it should be the default.

If diff3 exits successfully, indicating that there were no conflicts,
we rename wc.conflict over wc, delete gca and latest, and proceed.

If it exits unsuccessfully, wc is left untouched and wc.conflict is
left in place. svn commit will refuse to check wc in so long as
wc.conflict exists. So far, this is cmpilato's scheme.

Twist #1: In addition to the above, gca and latest get renamed out of
the admin area, so the user sees

$ ls wc*

where XXX and YYY are the revision numbers of those versions of the
file. This allows the user to run a merge tool of their choice to
resolve the conflict (there are plenty of these). Perhaps we ought to
offer a wrapper so that

$ svn resolve --tool=xxdiff wc

would spawn xxdiff with the proper arguments on wc and its cousins.
(and --tool could be set in a .svnrc)

(For extra clever points, svn resolve with no arguments could
sequentially walk you through resolving all the conflicts in the
current working copy.)

Twist #2: We permit the user to substitute a tool of their own for
the initial diff3. This could be, for instance, a shell script that
mimics the current diff+patch operation. Or it could be a more
intelligent program, that can narrow down diffs within line
boundaries, or understands how to merge binary files, whatever. You
could even have it spawn a graphical merge tool immediately.

I'm not sure when the gca and latest files should get deleted. I
don't think they should block commits, but should a commit or a
subsequent update delete them automatically?

What should the effect on update be if a conflict file exists?

Other thoughts?


p.s. Bitkeeper has an interesting feature: when a conflict occurs, it
creates a micro-branch for one set of changes. Then it does the merge
within the repository, just as if it were a branch merge. This means
both sides of every merge are preserved in the repo for future
reference. If I remember correctly, it's flat impossible to create
conflicts in the checked-out files.

This is of course easier for a system with an "every WC is a
repository clone" model. However, I don't think it is strictly
necessary to have that to implement this feature, and branches are
just as easy (easier, in fact) in Subversion, so post 1.0 we might
want to consider this.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:05 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.