Ingo Adler <dev@synacon.ch> wrote on 07/13/2005 06:04:04 PM:
> Mark Phippard wrote:
>
> >Ingo Adler <dev@synacon.ch> 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?
I imagine it is because it is a special case when a parent folder is
copied/moved. You would have to ask the Subversion devs why it is this
way. I think it is part of the O(1) algorithms behind copies.
> >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.
I am not able to parse this, especially the first sentence. Probably
doesn't matter though.
> >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
> Subversion API.
Not really. There is a better API available now, TSVN must not be using
it yet in this case. With the fix I added, this should not be a problem
in Subclipse anymore.
> 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.
I will just say that I respectfully disagree and think that you are
blowing this way out of proportion. These are not really bugs in
Subversion. A user of the command line would not likely run into any of
these problems. Simply because they have to think and type out a command.
They are rarely going to type out a URL and svn log and specify anything
more than the root URL, because they do not have to. In the GUI, we are
trying to infer information from the context and avoid asking you
questions. In some cases, the API's we needed were not available to us,
in others it was just oversight by the person that implemented the feature
in not knowing all of the scenarios that can come up. With JavaHL, we
have to wait for the API to be added and generally available before we can
use it. TortoiseSVN has an advantage here. Since it is written in C++ it
can access the entire API as it needs.
> Is it possible to make Subclipse a little more robust for these cases?
In the case of blame, we already have and it will be in the next release.
The last release was the first one where we had these API's available, but
we had to mostly focus on just getting a compatible release out which
contained support for the new features, like locking.
In the case of log, we added the concept of letting you tell us the root
URL. That makes it work reliably in all situations.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Jul 14 10:56:40 2005