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

Re: xxdiff support for subversion

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2004-02-25 22:55:39 CET

Ben Collins-Sussman <sussman@collab.net> writes:

> I think you're confused about why/when svn uses diff3 functionality. It
> does the merging *internally*, not interactively with the user.

That describes the internal diff3, the external diff3 may be

> Basically, it happens whenever you run 'svn update'. The client already
> has two files: the working file, and a pristine copy of the original
> repository file (in .svn/text-base/). During the update, the server
> sends a *new* repository file down to the client. Now the client has to
> do a 3-way merge: it must compare the old and new repository files, and
> then merge those differences into your working file. Usually this is a
> no-brainer, but if your working file already has local mods, you might
> end up with conflicts.
> Subversion has this diff3 ability built-in to its own libsvn_diff. If
> you specify an 'external' diff3 program, it's going to use that program
> to do the internal merging.

If Subversion is configured to use an external diff program then that
program will be used when the user invokes "svn diff".

If Subversion is configured to use an external diff3 program then that
program will be invoked when the user runs "svn merge". It will also
be invoked when the user invokes "svn update" or "svn switch" on a
working copy with local modifications.

> In any case, at no point does the user interact with any of this. After
> the update is completed, the user *does* have the ability to resolve
> conflicts using a 3rd party tool like xxdiff. That's because Subversion
> not only creates conflict markers within the working file, but leaves
> behind all three fulltext-files for you to examine. Those are the 3
> files you'd feed to xxdiff.
> Someday, we might add client-side hooks that would magically spawn
> interactive conflict resolution tools in the *middle* of an update, but
> we have no concrete plans for that yet, it's only been bantered around
> as an informal idea. For now, people will have to use xxdiff on
> conflicted files *after* the update.

It's possible now, we don't need any more hooks. Consider an
interactive diff3: it get invoked with a number of parameters, three
of which are the files three files involved in the three-way diff.
The program needs to resolve any conflicts and write the result of the
merge to stdout. Subversion will use whatever gets written to stdout
as the new working copy. The external diff3 program can create
windows, prompt the user, play music, etc. If your graphical merge
tool doesn't write to stdout then use a wrapper to invoke it and they
copy it's result to stdout.

Here is a very simplistic interactive diff (it's not useful beyond
showing that an interactive diff3 is possible):

$ cat mydiff
read -p "resolve the conflict: " x
echo $x
$ svn st wc
M * 1 wc/foo
Status against revision: 2
$ svn up --diff3-program `pwd`/mydiff wc
resolve the conflict: some rubbish
G wc/foo
Updated to revision 2.
$ cat wc/foo
some rubbish

Philip Martin
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 25 22:55:28 2004

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

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