Ingo Adler <dev@synacon.ch> wrote on 07/13/2005 02:53:55 PM:
> >If you want the problems fixed, then provide clear and concise recipe's
> >that demonstrate the problem. Ideally, just use a public repository,
like
> >the one for Subclipse, to demonstrate problem scenarios.
> >
> >Mark
> >
> >
> I created a repository for you:
http://stormrider.homelinux.org/svn/myrepo
>
> Test 1:
> - Get the project /branches/TestProject-test with Subclipse.
> - Display annotations for ch.test.Application -> empty -> why?
Because until Subversion 1.2 was released, we did not have the new peg
revision syntax available to us. The file does not exist in the branch
yet and without the peg revision syntax, the API does not trace the file
history back to trunk. I just fixed this today by switching the JavaHL
method to the new method provided in 1.2. I just verified that the fix
resolves it for your example.
> - Look at the history -> points to version 5 -> why?
Because revision 5 is the Last Changed Revision for the file and the
revision of the file in your workspace.
> Test 2:
> - Get the project with something else.
> - Import the project into the workspace. There is no need to "Share
> Project" anymore - thank you very much. (Is this an Eclipse 3.1 feature?
It is a feature we added in Subclipse which only works in Eclipse 3.1.
> Didn't notice it in Rational Application Developer, which is Eclipse
3.0.)
> - Display history or annotations for ch.test.Application -> error
> "fetching affected paths" -> why?
The autoshare feature has no way to auto-enter a correct repository root,
so we fall back to the only other URL we know which is the URL of the file
you selected. We then run the equivalent of this command, which fails:
svn log -r5
http://stormrider.homelinux.org/svn/myrepo/branches/TestProject-test/src/ch/test/Application.java
It fails because the URL specified did not exist at r5. This is sort of a
Subversion bug. svn log does not support the peg revision syntax. If it
did, then we could say based on the above URL @ HEAD, show me the revision
5. This would then trace back through history and show the file. As a
workaround, if you enter a repository root, we will use it, instead of the
file, in the request. So the command becomes this, which works:
svn log -r5 http://stormrider.homelinux.org/svn/myrepo
> - Look at the history -> points to version 5 -> why?
Same reason as the other example.
> Please tell me when you could try the tests, so I can shut down the
> repository.
You can shut it down. Thanks for taking the time to set it up in the
first place.
Mark
PS - I can recreate some of these problems in TortoiseSVN, showing that
when it is forced to use the same Subversion API's, that it has the same
problem.
1) Navigate in your WC to the Application.java file and choose Show Log.
It will only show revision 6 if you have the Stop on Copy box checked.
Uncheck the box and choose Next 100. This now gives an error for the same
reason we get one.
2) On the same file, take the Blame option. On the subsequent dialog,
change to To Revision from HEAD to 5, which is the way that we are
providing it to the API. Click OK and notice that you get an error.
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Jul 14 05:21:02 2005