| Re: [subversive-dev] Some more bugs with "compare with branch" |
|
25.02.2016 15:34, Florent Angebault
пишет:
While it is true, that there are no actual differences between the files, it is also true that it is due to two separate changes. And the status is reported by SVN 1.8 API call for both: SVN Kit and JavaHL. So, can't say it is definitely wrong and it seems to be a "reference" behaviour.Hi, starting with subversive 3.0.4, we encountered a few bugs and glitches that seem to come from the fix for bug [484929] (Weird behavior of the "Compare with branch" feature). Even though each of these problems should be declared as separate bug reports I guess it would be interesting to have them all described here since they will probably be fixed all at once. The attached file svnrepo.tar.gz is a sample svn repository that I use to describe some of the use cases below. All the tests were made with Eclipse Mars, SVNKit connector 1.8, under linux (and sometimes under Windows when specified). 1. compare with branch lists files with no actual differences This is already described in bug [326694]. To reproduce this, checkout the trunk from the attached svnrepo and use compare with branch -> 'mybranch'. You'll see the file Main.java listed and when you double-click on it, no differences are shown. I wrote a dirty patch for subversive-2.0.4 (see attached file remove-false-diffs-from-compare-view.patch). While comparision between repository URLs ignores ancestry and gives a clean diff between revisions content, comparison between working copy seems to be checking ancestry and finds a difference produced by conflicting commits. What is a little strange in this case is that the status returned is not CONFLICTED, but MODIFIED one. I'll note one thing though, the behaviour is actually the same, as the one emulated by SVN 1.7 based comparison version. The SVN 1.8 API distinguish new files as not versioned, so they didn't get reported. In order to cover this point local changes still must be gathered manually (the same way SVN 1.7-based version does):2. new local files are not listed Before 3.0.4, comparing with a branch would list new local files in compare editor. This is not true anymore. To reproduce this, create a new file, for instance src/Foo.java. Then compare with branch "mybranch" once again and you won't see the new file listed in compare editor. Adding the new file to version control solves the problem and is actually the behavior of the svn command line client (which I consider as a reference). But I'm afraid users will consider this is a regression however. * New files and folders aren't displayed in compare with URL/Revision/Branch/Tag when 1.8 compatible connector is used (bug 492534) https://bugs.eclipse.org/bugs/show_bug.cgi?id=492534 The code I made was too simplified, so it didn't distinguish between the cases when there are actually no file in the working copy (and never was) and the change is strictly incoming one, and when the file is actually present in the working copy but is not modified:3. changes with wrong direction As said in a previous discussion ([msg00269] and [msg00273]) the patch is not perfect because we loose the information concerning the "direction" of changes. Is there a way to improve this? I think it really needs to be fixed because it can be really confusing. * Wrong change direction in compare with URL/Revision/Branch/Tag with 1.8 compatible connectors (bug 492535) https://bugs.eclipse.org/bugs/show_bug.cgi?id=492535
SVN 1.8 API actually calculates changes relatively to the working
copy. So, an incoming addition will be represented as a deletion and
an incoming deletion - as addition, and that is why the statuses
should be reversed in code:* Incoming addition and deletion statuses are reversed in compare with URL/Revision/Branch/Tag when 1.8 compatible connector is used (bug 492536) https://bugs.eclipse.org/bugs/show_bug.cgi?id=492536 I hope SVN Kit guys will fix the issue, tough I don't know when. On another note - it is possible for me to take the patch and apply it to the SVN Kit library version that is distributed with Subversive. What do you think, should I do so?5. NPE on windows This is the bug already reported as [SVNKIT-646]. I recently attached a patch to the bug report (I forgot to create an account before posting therefore my comment was posted as user Guest). P.S. All the changes currently present in trunk (4.0 version). So, you may convert them to patches and try applying them to the version you're working on now. Best regards, Alexander Gurov. I'm happy to help on these topics. Actually I already created some patches for our customers using subversive 2.0.4 as you can see. But I'm not 100% confident on these patches because Eclipse is a big piece of software and I'm still new to plugin development. [326694]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=326694 [484929]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=484929 [msg00269]: http://dev.eclipse.org/mhonarc/lists/subversive-dev/msg00269.html [msg00273]: http://dev.eclipse.org/mhonarc/lists/subversive-dev/msg00273.html [SVNKIT-646]: https://issues.tmatesoft.com/issue/SVNKIT-646 -- Best regards, Alexander Gurov, Subversive Team. |