On 6/5/07, Johan Compagner <jcompagner@gmail.com> wrote:
> i see this in the log:
>
> blame -r 2054
> C:/workspace/wicket-calendar2/src/main/java/wicket/calendar/markup/html/form/dhtmlgoodies_calendar.js@HEAD
> HTTP Path Not Found
> svn: REPORT request failed on
> '/svnroot/wicket-stuff/!svn/bc/2326/trunk/wicket-calendar/src/main/java/wicket/calendar/markup/html/form/dhtmlgoodies_calendar.js'
> svn:
> '/svnroot/wicket-stuff/!svn/bc/2326/trunk/wicket-calendar/src/main/java/wicket/calendar/markup/html/form/dhtmlgoodies_calendar.js'
> path not found
>
>
> That is sort of true. That dir is moved the HEAD revision doesn't have that
> directory anymore
> but i just want to revision of that file or the annotations of that file
> that are in SVN. That the dir where the file is in is already removed
> shouldn't matter.
When you run an SVN command against a URL there is an implicit peg
revision of HEAD. The peg revision is what Subversion uses to "peg"
its history tracing in terms of finding something across moves.
In this case, the peg revision probably needs to be 2054. We made the
decision not to expose peg revisions in the UI as it just complicates
things. There was also a time where a lot of the API's did not expose
this parameter to us. That could even still be the case here. I
think you should file an issue so that if we are running blame against
a specific revision that we should default the peg revision to be the
same.
What context in our UI did you take this option? One of the reasons
we default to HEAD is the assumption is that you are working at or
near HEAD. So if you Show History on an item, the option you took is
likely on a location that currently exists. If you select an older
revision, the assumption is that the URL we pass through is going to
be the current one -- in which case HEAD is the right choice.
The only place this starts to fall over is if you are in an out of
date working copy and the item has been moved in the repos. At that
point, it becomes difficult to do the right thing without exposing the
option.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Tue Jun 5 14:14:25 2007