Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [subversive-dev] Some more bugs with "compare with branch"

25.02.2016 15:34, Florent Angebault пишет:

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 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
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.
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.

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/
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.
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):
* New files and folders aren't displayed in compare with URL/Revision/Branch/Tag when 1.8 compatible connector is used (bug 492534)

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.
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:
* Wrong change direction in compare with URL/Revision/Branch/Tag with 1.8 compatible connectors (bug 492535)

4. a file existing in branch but not in trunk

A file existing in branch but not in trunk is listed as outgoing deletion.
Then double-clicking it throws popup with this message:
    Get content for '' failed.
    svn: E200005: '/tmp/eclipse/ws/fakeproject/src/' is not
under version control
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)

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).
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?

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.


subversive-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Best regards,
Alexander Gurov,
Subversive Team.

Back to the top