If we passed the current URL with the old revision as the Peg, it
would fail. That is what I was alluding to earlier.
Mark
On 6/5/07, Johan Compagner <jcompagner@gmail.com> wrote:
> i tried to do it through different paths
>
> Team-> Show History
> Team -> Show Annotation
> Compare With -> Revision
>
> none of those works all come with the same kind of error.
> I already guessed that it had to do something that you first want to access
> head for it
> Isn't it possible to always do it with the revision number of the file i
> select?
>
> johan
>
>
> On 6/5/07, Mark Phippard < markphip@gmail.com> wrote:
> > 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
> >
> >
>
>
--
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 16:03:01 2007