{"action":"opened","issue":{"url":"https://api.github.com/repos/subclipse/archive/issues/243","repository_url":"https://api.github.com/repos/subclipse/archive","labels_url":"https://api.github.com/repos/subclipse/archive/issues/243/labels{/name}","comments_url":"https://api.github.com/repos/subclipse/archive/issues/243/comments","events_url":"https://api.github.com/repos/subclipse/archive/issues/243/events","html_url":"https://github.com/subclipse/archive/issues/243","id":177213546,"number":243,"title":"Can't view History for paths that have been replaced [Tigris #1356]","user":{"login":"markphip","id":933108,"avatar_url":"https://avatars.githubusercontent.com/u/933108?v=3","gravatar_id":"","url":"https://api.github.com/users/markphip","html_url":"https://github.com/markphip","followers_url":"https://api.github.com/users/markphip/followers","following_url":"https://api.github.com/users/markphip/following{/other_user}","gists_url":"https://api.github.com/users/markphip/gists{/gist_id}","starred_url":"https://api.github.com/users/markphip/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/markphip/subscriptions","organizations_url":"https://api.github.com/users/markphip/orgs","repos_url":"https://api.github.com/users/markphip/repos","events_url":"https://api.github.com/users/markphip/events{/privacy}","received_events_url":"https://api.github.com/users/markphip/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/subclipse/archive/labels/bug","name":"bug","color":"ee0701"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-09-15T15:45:22Z","updated_at":"2016-09-15T15:45:22Z","closed_at":null,"body":"## Description\n\n    1. In a project, commit a new file, creating revision X1.\n    2. Delete the file, and commit, creating revision X2.\n    3. Create a new file with the same name, and commit it, creating revision X3.\n    4. Choose Show History on the project, and click revision X1.\n    5. In Affected Paths, right-click the filename and choose Show History.\n    \n    You get an error message:\n    org.apache.subversion.javahl.ClientException: Two versioned resources are unrelated\n    svn: Unable to find repository location for '/repository/path/file' in revision X3\n    \n    It should be doing something like \"svn log /repository/path/file@X1.\n    \n    Using Subclipse 1.8.4.\n\n## Metadata Imported from Tigris (Issue 1356)\n\n  * **Creation Date**: 2011-12-15 11:09:10\n  * **Reporter**: jacobweber\n  * **Subcomponent**: core\n  * **Version**: 1.8.x\n  * **Milestone**: not determined\n  * **Keywords**: \n  * **Cc**: \n\n## Comments\n\n### 2011-12-15 16:52:04 by selsemore\n\n    The problem isn't that it is not doing something like \"svn log /repository/path/file@X1\".\n     It is doing that.  The problem arises from the revision range that it is asking for.\n     On the first call (to get, by default, the first 25 entries), it does something like\n    this:\n    \n    svn log -r HEAD:0 /repository/path/file@X1 --limit 25\n    \n    This results in the error.\n    \n    I'm not sure what the appropriate fix is.  Instead of specifying HEAD:0 on the first call,\n    it could specify X1:0.  This would avoid the error, but the downside would be that now\n    you would not see history after X1.  In your example, this isn't a factor, but suppose\n    there were changes to the file in revisions X1a, X1b, X1c, before the X2 deletion was\n    done.  Or, in a simpler scenario that does not even involve a deletion, showing history\n    for a selected Affected Path would not show history after the currently selected revision.\n    \n    I suppose we could monitor for the specific errors (resource missing or unrelated), and\n    then try again using X1 instead of HEAD for the start revision?\n    \n\n### 2011-12-15 18:15:52 by jacobweber\n\n    I see. Unfortunately, the two-tries thing still wouldn't show you X1a, X1b, or X1c. You'd have to keep \n    decrementing the revision until you find a valid one.\n    \n    My vote would be to just use X1:0, and maybe show some indication in the History window that this is \n    file@X1. Since you're already starting from a past revision, this seems justifiable. And I suppose it would be \n    unfair to ask Subclipse to do something that Subversion can't.\n\n### 2011-12-16 00:35:45 by jcorvel\n\n    The full solution depends on this issue in Subversion, I think:\n    \n    http://subversion.tigris.org/issues/show_bug.cgi?id=3830 (improve svn log with\n    \"forward\" revision range)\n    \n    A patch was submitted just before the 1.7 release, but it didn't make it (I'm\n    not sure what the current status is).\n\n### 2011-12-16 07:03:01 by selsemore\n\n    You're right, this does seem to be the issue.\n    \n    Jacob, I'm not in favor of always using the selected revision as the starting revision\n    when showing history for an affected path because this would change some behavior that\n    I like.  For example, suppose file was changed in revisions X1, X2 and X3.  Now suppose\n    I show history on the project, then select revision X1, then show history for the file\n    in the Affected Paths section.  With the current behavior (assuming the file has not been\n    deleted since the selected revision), I will see X1 and earlier, X2 and X3.  With the\n    proposed workaround (starting with X1), I would see only X1 and earlier.  I prefer the\n    current behavior because often I will show history for the project, interested at first\n    in the log messages as I look for a particular commit.  Once I find it, I often want to\n    see all history for one of the files, including changes that were made after the selected\n    revision.  Does that make sense?  That's why I suggested making a second try (using the\n    selected revision as the starting revision) only after the first try fails (i.e., file\n    has been deleted since the selected revision).  Kind of hacky, though, and would mean\n    inconsistent behavior (if file has been changed several times since the selected revision,\n    and then deleted, you would only see the selected revision and earlier, not the changes;\n    but if the file has not been deleted since the selected revision, then you would see all\n    the subsequent changes).\n    \n\n### 2011-12-16 13:11:39 by jacobweber\n\n    If you do the two-tries approach, I'd still suggest showing some indication when you have to fall back on \n    the second try. That way people will be aware that some revisions may not be shown.\n    \n    The same problem happens if you check out version X1 of the project and choose Show History on the file \n    — you'll immediately get an error. So whatever approach you settle on, you should probably use it there \n    too.\n\n### 2011-12-19 17:02:15 by selsemore\n\n    Jacob,\n    For now, I've just implemented the two-tries approach, without notification.  This will\n    have the same effect as your original suggestion.  It's kind of tricky to introduce notification\n    when this happens, for several reasons.  First of all, as I dug into this, I found that,\n    in certain scenarios, we were already using the two-tries approach, but we were only checking\n    for the specific error code that is returned when the resource is not found at the specified\n    revision, and not for the alternate error code that means it was found but is unrelated\n    (I've fixed it to check for this error code as well).  Secondly, the history view spins\n    off jobs to retrieve the logs, making interaction with the UI a little tricky.  I'm not\n    prepared to tackle that right now, considering that there is an open SVN bug that, when\n    fixed, would make all of this dead code anyway.  I'll leave this issue open, though, until\n    it is 100% fixed either by a further Subclipse fix or a Subversion fix.\n    Steve\n    \n\n\n\n"}}
{"actor":{"display_login":"markphip"}}