svn diff refuses to pass no arguments to external diff program

Bug #862750 reported by Edward Schwartz
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
subversion (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I like to use meld as an external diff program which svn diff.

For instance, I used to be able to run
    svn diff --diff-cmd meld
and everything would just work.

Now I get the following error:

ed@ed-Ubu64:~/f11/trunk$ svn diff --diff-cmd meld
Index: ocaml/traces.ml
===================================================================
Xlib: extension "RANDR" missing on display ":0.0".
Usage:
  meld Start with an empty window
  meld <file|dir> Start a version control comparison
  meld <file> <file> [<file>] Start a 2- or 3-way file comparison
  meld <dir> <dir> [<dir>] Start a 2- or 3-way directory comparison
  meld <file> <dir> Start a comparison between file and dir/file

meld: error: no such option: -u
svn: 'meld' returned 2

svn is passing -u to meld. That's okay, this is documented. From svn help:

  -x [--extensions] ARG : Default: '-u'. When Subversion is invoking an
                             external diff program, ARG is simply passed along
                             to the program. But when Subversion is using its
                             default internal diff implementation, or when
                             Subversion is displaying blame annotations, ARG
                             could be any of the following:

So, if I run svn diff --diff-cmd meld -x "" it should not pass -u to meld. Let's try it:

Index: ocaml/traces.ml
===================================================================
Xlib: extension "RANDR" missing on display ":0.0".
Usage:
  meld Start with an empty window
  meld <file|dir> Start a version control comparison
  meld <file> <file> [<file>] Start a 2- or 3-way file comparison
  meld <dir> <dir> [<dir>] Start a 2- or 3-way directory comparison
  meld <file> <dir> Start a comparison between file and dir/file

meld: error: no such option: -u
svn: 'meld' returned 2

Nope, still passes -u. Using a non-empty string works:
    svn diff -x "-L hello" --diff-cmd meld

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: subversion 1.6.12dfsg-4ubuntu2.1
ProcVersionSignature: Ubuntu 2.6.38-11.50-generic 2.6.38.8
Uname: Linux 2.6.38-11-generic x86_64
NonfreeKernelModules: nvidia wl
Architecture: amd64
Date: Thu Sep 29 16:30:04 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: subversion
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Edward Schwartz (moo-launchpad-z-edmcman) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in subversion (Ubuntu):
status: New → Confirmed
Revision history for this message
Martin Weis (martin-weis-newsadress) wrote :

If you use echo as command you see the commandline:

$ svn -r1 diff --diff-cmd echo README.txt
Index: README.txt
===================================================================
-u -L README.txt (revision 1) -L README.txt (working copy) .svn/tmp/tempfile.tmp README.txt

and as I aready stumbled upon this problem recently on a Macintosh, a look into the svn book reveals, that always GNU diff options are used:
http://svnbook.red-bean.com/en/1.5/svn.advanced.externaldifftools.html

Although I dont know, why this worked until now. Maybe meld changed its behaviour?

A wrapper script as in the link can help. This script works for me here, save meldsvn.py in $PATH

Revision history for this message
Christian Dornhege (c-dornhege) wrote :

I can confirm the bug on my natty/amd64, too.
I've taken the liberty to change the meldsvn.py script, so that it keeps all other parameters as e.g. the labels.

Revision history for this message
Ben Page (benpage26) wrote :

'svn diff -x \"\" --diff-cmd meld' , works as a workaround so I think the original issue was that the shell was eating the quotemarks.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.