After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 141538 - CVS diff broken for :ext: or local repository
CVS diff broken for :ext: or local repository
Status: VERIFIED NOTABUG
Product: meld
Classification: Other
Component: version
0.9.x
Other Linux
: Normal major
: ---
Assigned To: Stephen Kennedy
Stephen Kennedy
Depends on:
Blocks:
 
 
Reported: 2004-05-01 01:35 UTC by Stephen P Williams
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot of cvs diff problem with local repository (199.88 KB, image/png)
2004-05-04 14:21 UTC, Stephen P Williams
Details

Description Stephen P Williams 2004-05-01 01:35:59 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
Comment 1 Stephen Kennedy 2004-05-04 09:59:57 UTC
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.
Comment 2 Stephen P Williams 2004-05-04 14:21:26 UTC
Created attachment 27363 [details]
Screenshot of cvs diff problem with local repository
Comment 3 Stephen Kennedy 2004-05-04 14:28:34 UTC
In the cvs view click the bar that looks like |>-------------
You can see the cvs command output there.
Comment 4 Stephen P Williams 2004-05-04 14:39:25 UTC
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)
 
Comment 5 Stephen Kennedy 2004-05-04 15:09:24 UTC
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.
Comment 6 Stephen P Williams 2004-05-04 15:18:29 UTC
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).
Comment 7 Stephen P Williams 2004-05-04 18:27:36 UTC
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)
Comment 8 Stephen Kennedy 2004-05-05 10:54:16 UTC
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.
Comment 9 Stephen Kennedy 2004-05-05 12:15:04 UTC
[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.
Comment 10 Stephen Kennedy 2005-01-21 18:04:41 UTC
Closing old bugs.