You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Martin Blais <bl...@furius.ca> on 2004/02/24 18:23:36 UTC
xxdiff support for subversion
hi all
is there anyone using xxdiff along with subversion?
if so, then could you indicate how?
xxdiff is my file comparison and merge tool. as of the 3.0 release, i
added some features to xxdiff that make it even easier to integrate
with various VC systems. in particular, there is a new "--decision"
option which forces the user to exit with one of "accept", "merge",
"reject" codes; that can make it very easy to implement an interactive
conflict-resolution system on top of the update or merge process.
xxdiff also allows you to interactively select the diff hunks to
produce a merged result if necessary. also, xxdiff supports 3-way
diffs and merges, you can find it here::
http://xxdiff.sourceforge.net/
i'm assuming that subversion itself would be invoking xxdiff; from
reading the docs it seems to me that subversion is smart enough to
integrate visual comparison programs like that, rather than to have to
write a script that does that stuff by fetching various versions of
files to temporary files and then invoking xxdiff like i do for some
other systems. i wrote a wrapper script that can visualize the output
of "cvs diff" directly, that could be another way::
http://xxdiff.sourceforge.net/#tools
i read the book and then have been fiddling with subversion last night
when i heard v1.0.0 had been released and simply attempted replacing
"diff-cmd" in my user config (~/.subversion/config); the documentation
does not indicate how to format the arguments and replacing diff-cmd
seemed to behave differently when specifying more than a single
argument, so i wrote a very simple wrapper script that deals with the
default arguments that are given to diff and it works in that specific
case.
i would like to know all the various ways and situations that
subversion can invoke it, all the use cases, to make that script more
general, and also all details on how to make it integrate better.
basically, any info for this to be done "right" would be appreciated.
as the author of xxdiff i would be happy to implement, distribute and
maintain that wrapper script.
thanks.
cheers,
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: xxdiff support for subversion
Posted by Martin Blais <bl...@furius.ca>.
(me again)
also, i wrote a short document short descriptions of some of the xxdiff
features that can be used to integrate xxdiff with vc systems, surely some
ideas there must apply to subversion::
http://xxdiff.sourceforge.net/doc/xxdiff-integration.html
cheers,
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: xxdiff support for subversion
Posted by Martin Blais <bl...@furius.ca>.
On Wednesday 25 February 2004 15:40, Ben Collins-Sussman wrote:
> Hope this clarifies things.
very much so thank you! i thought that part of the roles for these hooks were
intended for display for "svn diff" and that as such i would not need to
implement a script to loop over the files and inspect the status.
one use for a update or merge hook i subversion would be to prompt the user
with a tool such as xxdiff and selectively merge changes depending on the
user's answer (even for changes with no conflicts). the alternative requires
interpreting the output of "svn status" _before_ merging and calling svn
update selectively after displaying diffs. i did implement something like
that over CVS but it was tricky (although in the end i managed to make it
work reliably). i feel it would be nicer to just hook into subversion's own
update semantics rather than to try to interpret things the same way.
anyway, to do that, i can use "svn status -N" and "svn list -R" and connect
matching pairs, but i still would have to deal with file deletions/additions
manually.
also, it should be *very* easy to build a tool that can preview and resolve
conflicts graphically with xxdiff _after_ update/merge, especially since it
leaves the 3 files (with CVS i had to extract them). i will do that at some
point and distribute it with xxdiff.
thanks.
cheers,
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: xxdiff support for subversion
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@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
different.
> 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
#!/bin/sh
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
Re: xxdiff support for subversion
Posted by Ben Collins-Sussman <su...@collab.net>.
I think you're confused about why/when svn uses diff3 functionality. It
does the merging *internally*, not interactively with the user.
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.
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.
Hope this clarifies things.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: xxdiff support for subversion
Posted by Martin Blais <bl...@furius.ca>.
hi
i implemented a quick wrapper that accepts those options for the switches that
subversion's uses for diff and diff3 and it fails when i set diff3-cmd. i'm
not sure what role it uses diff3 for, and it seems to read the output to
perform some other task than display, i did not have time to look at the
subversion source yet to figure out the problem.
to provide integration with external diff programs subversion would need to
define clear "roles" for when and why it invokes the external diff. e.g. is
the program used for display? it is used to compute deltas? to extract
patches? perhaps we need to have separate configuration variables for all
these roles...
one functionality that i would implement immediately if i were to switch over
to subversion would be a repository-diff script, where i could visualize
changes that would occur on an commit (including pending merges, displayed
with 3-way diffs). in other words, go through all the elements in the
checkout area, if there is a newer revision in the repository or if the
element has been modified locally, show a visual diff of the files (3-way if
both cases present).
i was expecting a 3-way diff display upon running "svn diff" on an element
which 1) has been modified locally and 2) for which a more recent revision
exists in the repository (for that element). doesn't seem to work that way,
and the --notice-ancestry doesn't seem to do it (btw what does it do? the
book doesn't say much and the mailing-lists/man either, i assume it follows
"copy" history?).
BTW, is there a way to make disable comments on commits? in .cvsrc i used
commit -m ""
cheers,
On Tuesday 24 February 2004 14:31, Ben Collins-Sussman wrote:
> On Tue, 2004-02-24 at 12:23, Martin Blais wrote:
> > i would like to know all the various ways and situations that
> > subversion can invoke it,
>
> To make svn use an external diff program, you can either pass
> '--diff-cmd', or set the runtime variable 'diff-cmd' in the config file.
>
> Looking at svn_io_run_diff() public API (and code), it seems that we're
> expecting the diff program to take exactly two file arguments.
>
> You can also pass extra arguments to the external diff program by using
> the -x option, for example:
>
> $ svn diff foo.c bar.c --diff-cmd /usr/bin/gnudiff -x "-u -b"
>
> When dealing with external diff3 programs, it looks like we're pretty
> much assuming GNU diff3 only... our code to set up arguments looks like
> this:
>
> /* Set up diff3 command line. */
> args[i++] = diff3_utf8;
> args[i++] = "-E"; /* We tried "-A" here, but that caused
> overlapping identical changes to
> conflict. See issue #682. */
> args[i++] = "-m";
> args[i++] = "-L";
> args[i++] = mine_label;
> args[i++] = "-L";
> args[i++] = older_label; /* note: this label is ignored if
> using 2-part markers, which is the
> case with "-E". */
> args[i++] = "-L";
> args[i++] = yours_label;
> args[i++] = mine;
> args[i++] = older;
> args[i++] = yours;
>
>
> I don't think our diff3 was designed to be super flexible with various
> 3rd party merging tools. Originally, svn *required* an external diff3,
> and our function svn_io_run_diff3() was only written for that purpose.
> After Sander wrote a homegrown libsvn_diff, using external diff/diff3
> became optional.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: xxdiff support for subversion
Posted by Martin Blais <bl...@furius.ca>.
On Tuesday 24 February 2004 14:31, Ben Collins-Sussman wrote:
> I don't think our diff3 was designed to be super flexible with various
> 3rd party merging tools. Originally, svn *required* an external diff3,
> and our function svn_io_run_diff3() was only written for that purpose.
> After Sander wrote a homegrown libsvn_diff, using external diff/diff3
> became optional.
hi ben
note a little detail: xxdiff does not actually compute the diffs itself. it
invokes GNU diff under the hood. if the libsvn_diff() function actually
implements a better diff algorithm, i could make xxdiff read that instead of
doing the diffs itself. xxdiff would then need to be fed the two or three
files and the diff output. i never had to implement that, but it would not
be too hard.
that was not needed for ClearCase integration: in complicated cases
ClearCase's cleardiff generates better (i.e. smaller, or less) hunks than GNU
diff, and users wanted to use it, but since cleardiff outputs POSIX diff
format xxdiff already parses that, ClearCase users would simply tell xxdiff
(in ~/.xxdiffrc) to invoke cleardiff instead of GNU diff. so in this case
xxdiff still ends up spawning diff and reading output from a pipe. i did not
have to change a thing.
i guess the question comes down to who invokes xxdiff vs. subversion commands:
either one writes a script that figures out what has changed from 'svn
status' output and then invokes many xxdiff on files separately, or we let
subversion figure out all the changes itself (better IMO) and it itself
invokes xxdiff when needed.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: xxdiff support for subversion
Posted by Ben Collins-Sussman <su...@collab.net>.
On Tue, 2004-02-24 at 12:23, Martin Blais wrote:
> i would like to know all the various ways and situations that
> subversion can invoke it,
To make svn use an external diff program, you can either pass
'--diff-cmd', or set the runtime variable 'diff-cmd' in the config file.
Looking at svn_io_run_diff() public API (and code), it seems that we're
expecting the diff program to take exactly two file arguments.
You can also pass extra arguments to the external diff program by using
the -x option, for example:
$ svn diff foo.c bar.c --diff-cmd /usr/bin/gnudiff -x "-u -b"
When dealing with external diff3 programs, it looks like we're pretty
much assuming GNU diff3 only... our code to set up arguments looks like
this:
/* Set up diff3 command line. */
args[i++] = diff3_utf8;
args[i++] = "-E"; /* We tried "-A" here, but that caused
overlapping identical changes to
conflict. See issue #682. */
args[i++] = "-m";
args[i++] = "-L";
args[i++] = mine_label;
args[i++] = "-L";
args[i++] = older_label; /* note: this label is ignored if
using 2-part markers, which is the
case with "-E". */
args[i++] = "-L";
args[i++] = yours_label;
args[i++] = mine;
args[i++] = older;
args[i++] = yours;
I don't think our diff3 was designed to be super flexible with various
3rd party merging tools. Originally, svn *required* an external diff3,
and our function svn_io_run_diff3() was only written for that purpose.
After Sander wrote a homegrown libsvn_diff, using external diff/diff3
became optional.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org