GNOME Bugzilla – Bug 709249
SVN 1.6 repository not recognised
Last modified: 2013-10-18 08:06:42 UTC
In 1.8.1, SVN 1.6 repositories are not recognised. The VCS drop down shows none and SVN 1.7 greyed out (invalid repository). In 1.8.0 the repositories are recognised.
Unfortunately, I can't actually see how this could occur. I don't suppose it's possible to attach an archive of a tree that exhibits this problem? If you need to get a minimal reproduction, just the folder hierarchy with the .svn folders (and maybe their format and entries files) should do it.
Created attachment 256352 [details] Example 1.6 SVN sandbox Attached very simple SVN 1.6 sandbox that exhibits the issue. With 1.8.1 this isn't detected as a valid SVN sandbox. With 1.8.0 it IS detected as an SVN sandbox.
You said in comment 1 that the drop down shows "None" and "Subversion 1.7 (Invalid repository)"... I understood this to mean that it didn't show "Subversion", but this works for me on your example repository. (The repository is still marked invalid, but that's because my SVN too new for that repo.) On your local machine, is this repository nested inside another or something similar? How are you invoking Meld on that repo?
I'm invoking meld directly from an extracted tarball. The repository is not nested. Stuff/meld-1.8.1/ Stuff/test/ cd Stuff/test/ ../meld-1.8.1/bin/meld Then select version control option and browse to the test folder. For reference, the version of svn installed: svn, version 1.6.17 (r1128011) Not sure if relevant but there is also meld 1.5.3 installed in /usr/bin.
Okay thanks for that. Can you clarify what you're actually seeing in the drop down? When I do what you describe, I see "None", "Subversion" and "Subversion 1.7" in the drop down, with both Subversion options greyed out (which is correct behaviour here).
I see "None" and "Subversion 1.7 (invalid repository)".
Unfortunately it took me until this morning to realise that the reason I couldn't reproduce was that this only occurs when the svn plugin happens to get loaded before the svn_17 one... which depended entirely on filesystem ordering. So on my local system svn_17 was loaded first and the test case was *always* fine. On your system it's loaded second and always breaks. Yay. Anyway, I've pushed a fix to the meld-1-8 branch of Meld git. I'd really appreciate it if you could test that this fixes the problem for you. I'm not going to make another release until this has had some testing, since I'm now paranoid about this.
Tested origin/meld-1-8 which works successfully.
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.