GNOME Bugzilla – Bug 141538
CVS diff broken for :ext: or local repository
Last modified: 2009-08-15 18:40:50 UTC
Please see the Debian bug #243599. I have had no reply from the Debian maintainer in two weeks, but the bug is also present in the latest meld-0.9.2.1.tar.gz from the gnome.org site. I've only tested this on Debian Linux machines running basically up-to-date 'testing' releases. Here's a link to the Debian bug (which contains a sample CVS repository to replicate the problem). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=243599
This is strange. I followed the instructions, but it worked without fault. Maybe you can see whats going on from the console output. I think this could be related to another bug however - if the last line does not end with a newline, the diffs for that line may not be correct. Theres an option to add missing newline. Try settings->misc->add missing newline at eof.
Created attachment 27363 [details] Screenshot of cvs diff problem with local repository
In the cvs view click the bar that looks like |>------------- You can see the cvs command output there.
Stephen, On my machines, I don't see any console output -- is there some "secret decoder ring" I need to pass to get some generated? I have added a screenshot that shows the behavior I see. In the top two windows, the left window shows the CVS top-level view of the test repository, the right window shows the "cvs diff" view. Notice that both panes are showing the locally modified version of "somefile" and that there are no differences highligted. In the bottom two windows, I have done the same thing, but with a copy of the Slim Devices source code (The meld web page doesn't list the CVS repository ;-): cvs -d :pserver:anonymous@cvs.slimdevices.com:/cvsroot login (password is blank) cvs -d :pserver:anonymous@cvs.slimdevices.com:/cvsroot checkout slim cd slim echo "# modified" >> makerelease.pl meld . Notice this time that the "cvs diff" window correctly shows the local change. I have used strace to see that meld runs "cvs diff -u $file", and I think this may be the source of my trouble. On my machines, the output of CVS diff has a slightly different header for a local repository than for a :pserver: stevew@grommit:test$ cvs diff -u somefile Index: somefile =================================================================== RCS file: /home/stevew/testRepository/test/somefile,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 somefile --- a/somefile 13 Apr 2004 23:02:29 -0000 1.1.1.1 +++ b/somefile 13 Apr 2004 23:05:26 -0000 @@ -1 +1,2 @@ Test file +// locally modified stevew@grommit:slim$ cvs diff -u makerelease.pl Index: makerelease.pl =================================================================== RCS file: /cvsroot/slim/makerelease.pl,v retrieving revision 1.29 diff -u -r1.29 makerelease.pl --- makerelease.pl 22 Apr 2004 21:23:19 -0000 1.29 +++ makerelease.pl 4 May 2004 14:22:44 -0000 @@ -331,3 +331,4 @@ sub showUsage { print "makerelease.pl [--checkout] [--update] [--snapshot] [--version VERSION]\n"; } +# modified I don't know what the "a/" and "b/" are supposed to be, but they may be tripping up the interpretation of the differences. What version of CVS are you using? I have: stevew@grommit:test$ cvs -v Concurrent Versions System (CVS) 1.12.5 (client/server)
I'm using 1.12.1 and do not see the bug because there is no leading a/ nor b/ in the diff Index: somefile =================================================================== RCS file: /home/stephen/c/testRepository/test/somefile,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 somefile --- somefile 13 Apr 2004 23:02:29 -0000 1.1.1.1 +++ somefile 4 May 2004 15:04:12 -0000 @@ -1 +1,2 @@ Test file +// locally modified Looks like cvs is broken. Do you get the same phantom directories with the :ext: method? cvsview.py:show_patch needs to check for this behaviour. BTW, see previous comment #3 about cvs console output.
Yes, I do. I don't have a :pserver: setup anywhere that is running cvs 1.12.5 on the server side, but probably the reason I don't see the problem when I use a :pserver: repository is that the *server* is running an older version of cvs. Looking around, I see a report about this cvs 1.12.5 behavior here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=232931 I hope that helps. Thanks for this tool (and the Python/GTK programmin lessons it teaches).
Apparently the 'a/' and 'b/' are fooling 'patch'. The following patch works for me, but is probably not robust enough if you actually have directories names 'a' and 'b' at the top-level of your CVS working directory. Doubtless you'll find something more robust. Just a quick question -- why does meld request the "cvs diff -u" and then reverse-patch the file? The tkdiff and pcl-cvs tools simply retrieve the version to be compared directly with something like: "cvs update -r <version> -p > file.<version>" And don't need to patch, they simply diff the two files with whatever "diff" flavor they like to use. I presume that the though here is that the "cvs diff -u" output will be shorter, but if you think about it, "cvs diff -u" will have to fetch the full revision file from the server anyway, since the changed file exists only locally. Therefore the diff must be done locally, and now that I think about it, I don't understand why this "feature" of cvs 1.12.5 exists only for local and :ext: repositories. Anyway, here's the patch that gets me past this problem for the time being: diff -u meld-0.9.2.1/cvsview.py meld-local/cvsview.py --- meld-0.9.2.1/cvsview.py 2004-02-20 01:34:45.000000000 -0800 +++ meld-local/cvsview.py 2004-05-04 11:26:49.000000000 -0700 @@ -599,6 +599,10 @@ def show_patch(self, prefix, patch): if not patch: return + # spw(2004/05/04): get rid of funky 'a/' and 'b/' prefixes + # generated by cvs version 1.12.5 + patch = re.sub('\n(---|[+][+][+]) [ab]/','^\1 ',patch) + tmpdir = tempfile.mktemp("-meld") self.tempfiles.append(tmpdir) os.mkdir(tmpdir)
The original idea was that when diffing many files, or directories recursively that only the changed files would show up in the patch output. The patch method is also *much* faster for several files if you are running through an ssh tunnel. I'm not too familiar with cvs protocol, but if the several files are unchanged (timestamp-wise) then I hope cvs diff <files> skips them immediately.
[posted to cvs-bugs@gnome.org] >It seems 1.12.5 changed the format of "cvs diff" by introducing leading >a/ and b/ directories. > >This leads to difficulty with programs which integrate with cvs. > >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=232931 >http://bugzilla.gnome.org/show_bug.cgi?id=141538 No, it didn't. At least, not in the upstream version. Sorry, I added a patch from a Debian user without thinking through the consequences properly. It'll be backed out again shortly. -- Steve McIntyre, Cambridge, UK. steve@einval.com I'm not going to try to work around a bug which exists only in a soon to be replaced debian version. Marking as NOTABUG.
Closing old bugs.