Login | Register
My pages Projects Community openCollabNet

Discussions > issues > [Issue 1356] New - Can't view History for paths that have been replaced

subclipse
Discussion topic

There will be a brief maintenance window every Friday at 17:00 Pacific.
For further details, see CollabNet's maintenance and upgrade policy.

Hide all messages in topic

All messages in topic

[Issue 1356] Can't view History for paths that have been replaced

Author selsemore
Full name Stephen Elsemore
Date 2011-12-19 17:02:16 PST
Message http://subclipse.tig​ris.org/issues/show_​bug.cgi?id=1356






------- Additional comments from selsemore at tigris dot org Mon Dec 19 17:02:15 -0800 2011 -------
Jacob,
For now, I've just implemented the two-tries approach, without notification. This will
have the same effect as your original suggestion. It's kind of tricky to introduce notification
when this happens, for several reasons. First of all, as I dug into this, I found that,
in certain scenarios, we were already using the two-tries approach, but we were only checking
for the specific error code that is returned when the resource is not found at the specified
revision, and not for the alternate error code that means it was found but is unrelated
(I've fixed it to check for this error code as well). Secondly, the history view spins
off jobs to retrieve the logs, making interaction with the UI a little tricky. I'm not
prepared to tackle that right now, considering that there is an open SVN bug that, when
fixed, would make all of this dead code anyway. I'll leave this issue open, though, until
it is 100% fixed either by a further Subclipse fix or a Subversion fix.
Steve

[Issue 1356] Can't view History for paths that have been replaced

Author jacobweber
Full name Jacob Weber
Date 2011-12-16 13:11:39 PST
Message http://subclipse.tig​ris.org/issues/show_​bug.cgi?id=1356






------- Additional comments from jacobweber at tigris dot org Fri Dec 16 13:11:39 -0800 2011 -------
If you do the two-tries approach, I'd still suggest showing some indication when you have to fall back on
the second try. That way people will be aware that some revisions may not be shown.

The same problem happens if you check out version X1 of the project and choose Show History on the file
— you'll immediately get an error. So whatever approach you settle on, you should probably use it there
too.

[Issue 1356] Can't view History for paths that have been replaced

Author selsemore
Full name Stephen Elsemore
Date 2011-12-16 07:03:02 PST
Message http://subclipse.tig​ris.org/issues/show_​bug.cgi?id=1356






------- Additional comments from selsemore at tigris dot org Fri Dec 16 07:03:01 -0800 2011 -------
You're right, this does seem to be the issue.

Jacob, I'm not in favor of always using the selected revision as the starting revision
when showing history for an affected path because this would change some behavior that
I like. For example, suppose file was changed in revisions X1, X2 and X3. Now suppose
I show history on the project, then select revision X1, then show history for the file
in the Affected Paths section. With the current behavior (assuming the file has not been
deleted since the selected revision), I will see X1 and earlier, X2 and X3. With the
proposed workaround (starting with X1), I would see only X1 and earlier. I prefer the
current behavior because often I will show history for the project, interested at first
in the log messages as I look for a particular commit. Once I find it, I often want to
see all history for one of the files, including changes that were made after the selected
revision. Does that make sense? That's why I suggested making a second try (using the
selected revision as the starting revision) only after the first try fails (i.e., file
has been deleted since the selected revision). Kind of hacky, though, and would mean
inconsistent behavior (if file has been changed several times since the selected revision,
and then deleted, you would only see the selected revision and earlier, not the changes;
but if the file has not been deleted since the selected revision, then you would see all
the subsequent changes).

[Issue 1356] Can't view History for paths that have been replaced

Author jcorvel
Full name Johan Corveleyn
Date 2011-12-16 00:35:45 PST
Message http://subclipse.tig​ris.org/issues/show_​bug.cgi?id=1356






------- Additional comments from jcorvel at tigris dot org Fri Dec 16 00:35:45 -0800 2011 -------
The full solution depends on this issue in Subversion, I think:

http://subversion.ti​gris.org/issues/show​_bug.cgi?id=3830 (improve svn log with
"forward" revision range)

A patch was submitted just before the 1.7 release, but it didn't make it (I'm
not sure what the current status is).

[Issue 1356] Can't view History for paths that have been replaced

Author jacobweber
Full name Jacob Weber
Date 2011-12-15 18:15:52 PST
Message http://subclipse.tig​ris.org/issues/show_​bug.cgi?id=1356






------- Additional comments from jacobweber at tigris dot org Thu Dec 15 18:15:52 -0800 2011 -------
I see. Unfortunately, the two-tries thing still wouldn't show you X1a, X1b, or X1c. You'd have to keep
decrementing the revision until you find a valid one.

My vote would be to just use X1:0, and maybe show some indication in the History window that this is
file@X1. Since you're already starting from a past revision, this seems justifiable. And I suppose it would be
unfair to ask Subclipse to do something that Subversion can't.

[Issue 1356] Can't view History for paths that have been replaced

Author selsemore
Full name Stephen Elsemore
Date 2011-12-15 16:52:05 PST
Message http://subclipse.tig​ris.org/issues/show_​bug.cgi?id=1356






------- Additional comments from selsemore at tigris dot org Thu Dec 15 16:52:04 -0800 2011 -------
The problem isn't that it is not doing something like "svn log /repository/path/file@X1".
 It is doing that. The problem arises from the revision range that it is asking for.
 On the first call (to get, by default, the first 25 entries), it does something like
this:

svn log -r HEAD:0 /repository/path/file@X1 --limit 25

This results in the error.

I'm not sure what the appropriate fix is. Instead of specifying HEAD:0 on the first call,
it could specify X1:0. This would avoid the error, but the downside would be that now
you would not see history after X1. In your example, this isn't a factor, but suppose
there were changes to the file in revisions X1a, X1b, X1c, before the X2 deletion was
done. Or, in a simpler scenario that does not even involve a deletion, showing history
for a selected Affected Path would not show history after the currently selected revision.

I suppose we could monitor for the specific errors (resource missing or unrelated), and
then try again using X1 instead of HEAD for the start revision?

[Issue 1356] New - Can't view History for paths that have been replaced

Author jacobweber
Full name Jacob Weber
Date 2011-12-15 11:09:11 PST
Message http://subclipse.tig​ris.org/issues/show_​bug.cgi?id=1356
                 Issue #|1356
                 Summary|Can't view History for paths that have been replaced
               Component|subclipse
                 Version|1.8.x
                Platform|All
              OS/Version|Mac OS X
                     URL|
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P3
            Subcomponent|core
             Assigned to|issues@subclipse
             Reported by|jacobweber






------- Additional comments from jacobweber at tigris dot org Thu Dec 15 11:09:10 -0800 2011 -------
1. In a project, commit a new file, creating revision X1.
2. Delete the file, and commit, creating revision X2.
3. Create a new file with the same name, and commit it, creating revision X3.
4. Choose Show History on the project, and click revision X1.
5. In Affected Paths, right-click the filename and choose Show History.

You get an error message:
org.apache.subversio​n.javahl.ClientExcep​tion: Two versioned resources are unrelated
svn: Unable to find repository location for '/repository/path/file' in revision X3

It should be doing something like "svn log /repository/path/file@X1.

Using Subclipse 1.8.4.
Messages per page: