On Thu, 2008-11-27 at 22:00 +0100, Branko Èibej wrote:
> Martin Furter wrote:
> > The first thing I thought is "me too". But that really only happens
> > with deleted nodes.
> >
> > But after thinking about what happens if -r sets both, revision and
> > peg-rev, I tried a few commands on a branch:
> >
> > $ svn log -r 33642 ._at_33642
> > svn: REPORT request failed on
> > '/repos/svn/!svn/bc/33642/branches/fsfs-pack'
> > svn: '/repos/svn/!svn/bc/33642/branches/fsfs-pack' path not found
> > $ svn ls -r 33642 ._at_33642
> > svn: URL 'http://svn.collab.net/repos/svn/branches/fsfs-pack'
> > non-existent in that revision
> >
> > I hope I used the right syntax here to simulate the
> > peg-defaults-to-rev behaviour. If I did I guess we would end up with a
> > more annoying default.
>
> This is a very good point. Thanks for bringing it up; food for thought.
But what WAS Martin's point? I see two interpretations:
1) He wanted svn to display a log or listing of a nonexistent object,
and got an error message. That is what I would expect. (The error
message for "log" is a bit unfriendly and inconsistent. We should fix
that anyway.)
Or
2) He wanted svn to display a log or listing of the object that used to
exist in r33642 in the line of history of local directory ".". If that
is the desired semantics, then the expected result is to show the
corresponding path in "trunk", and the diagnosis of the failure is that
svn interprets "WC_PATH_at_REV" syntax wrongly.
Neither of these indicates any problem with the proposal to make the
peg-rev default to the specified operative-rev, as far as I can see.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-28 18:47:42 CET