Mark Phippard wrote:
>Ingo Adler <email@example.com> wrote on 07/13/2005 02:53:55 PM
>>- 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.
That's not obvious. Why is there a log entry when nothing has changed?
And the "wrong" log entry (6) works better than the "right" (5) one.
>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.
That's the difference. TortoiseSVN doesn't handle more complicated cases
or call it the "second click". But the first click gives a result
without cryptical error messages. When I uncheck the "Stop on Copy box"
I even get the whole history without any problems. Sadly enough it can't
handle the "Next 100" which shows some big problems too.
>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.
That's the little difference again. When I click on the file and
"Blame" - in TortoiseSVN it works in Subclipse it doesn't work. The more
complex case fails in TortoiseSVN too.
But again, it shows some inconsistencies or deficiencies in the
Off topic: Subversion claims to have better rename and move support than
CVS. I think, it's actually worse. In CVS you know what you get and you
can depend on it. In Subversion there are so many minor or major bugs
around this feature. You'll never know what you'll get.
Is it possible to make Subclipse a little more robust for these cases? I
think, it would be much better when I won't get an error message when I
click an entry from the main menu with standard settings. In many cases
I wouldn't need the next dialog - just "standard" log and "standard" blame.
Thanks for your patience.
Received on Thu Jul 14 08:04:04 2005