GNOME Bugzilla – Bug 483451
Meld does not inspect svn locked files for changes.
Last modified: 2010-09-30 21:48:05 UTC
Please describe the problem: When a file is locked via subversion via the "svn lock" command (which was added in Subversion ver. 1.2.0), meld does not notice changes to the file. Steps to reproduce: 1. Modify a file in a subversion checkout. 2. Run "meld ." in that folder. 3. Notice that the file appears as modified (red). 4. Exit meld. 5. Lock that file with the command "svn lock filename" 6. Run "meld ." in that folder. 7. Notice that the file does not appear as modified (not red). Actual results: Expected results: File should be modified. Does this happen every time? Yes. Other information: If you "svn unlock" the file, it will appear as modified. My quick guess is that it has something to do with the fact that a "K" appears in the 6th column of the svn tags when running "svn status". For example: M K include/connection.h This probably confuses a regular expression or something.
P.S. I'm running Meld 1.1.5.1 on Gentoo.
Ping?
Hi Philippe, an old version of meld used regexes, but the new one is much simpler. Perhaps you have an old .pyc or old svn.py in an import path? If not, can you send me a small repro?
Created attachment 102898 [details] [review] Ignores svn Repository lock token indicator in svn status command results. Adds a single extra '.' so there are 6 dots total (including the reported one) to the regular expression handling the results of svn status command. The use of this sixth column was added in 1.2: http://subversion.tigris.org/svn_1.2_releasenotes.html
> Hi Philippe, an old version of meld used regexes, but the new one > is much simpler. Perhaps you have an old .pyc or old svn.py in an > import path? The latest version I could download (1.1.5) still uses a regular expression in it's svn.py. I made a patch and uploaded it which hopefully will make your life easier. ... Whoops. Just realized there's a 1.1.5.1 (which is the version I'm actually using), but I just verified that svn.py is identical in both 1.1.5 and 1.1.5.1 so it shouldn't really matter.
Hi Philippe, I've been looking at the unreleased svn version which split based on columns instead of using a regex. It doesn't seem to have this bug.
Hey Stephen, I forgot about this until just now when it bit me again. I looked at the latest version of vc/svn.py in "master" and don't see the columns implementation you mentioned, so this still seems to exist in 1.3.0 at least. So I'm going to "reopen" this and supply a patch.
Created attachment 142429 [details] [review] Change SVN status regep to ignore extra columns. This is my first git patch, so you'll have to forgive me if it's not in the expected format; it's just in the standard format, presumably some e-mail format.... Basically, Subversion 1.6.4 accounts for 7 columns from an "svn status" command. You care about the first, and before the patch required all the others to be empty. This just sticks a ".{6}" before you space checking since none of those columns seem like they would matter to meld. I figured this change could get thrown in "master" in case the column parsing code doesn't make it into 1.3.1.
Ping: it's been over a month since the last post. Just trying not to fall through the cracks.
Note: I've been using this patch without problems for 2 months now.
Ping: it's been almost 5 months since I've heard anything about this.
Looking at the patch, I'm guessing that this would break compatibility with all versions of SVN prior to 1.6, since they only have 6 columns? While a simple version that solves the problem in a backwards compatible manner would also be great, can you have a look at the patch in bug 597631, which switches Meld to parse SVN's XML output instead. Could you test with that and see if it solves your problem?
On the contrary. The oldest version of Subversion I can get my hands on around here is 1.1.4 (from Oct 2005) it has 8 character-columns before the filename begins. Modification character + .{6} + a white-space separator before the filename. The --xml flag wasn't added until 1.3 according to the 1.3 release notes: <http://subversion.apache.org/docs/release-notes/1.3.html>. Therefore the regex is more backwards compatible than the XML. I did try attachment 164592 [details] [review] (--xml patch) from bug #597631 against my Subversion 1.6.9, and it works fine.
I've pushed the patch from bug 597631 to HEAD, so this should now be fixed. Thanks for the bug report.