[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: Untangling the peg revision knot (was: A preliminary study of non-contiguous transformations in the Hilbert space of Alexandrian solutions)

From: Martin Furter <mf_at_rola.ch>
Date: Sun, 30 Nov 2008 02:08:27 +0100 (CET)

On Fri, 28 Nov 2008, Julian Foad wrote:

> 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.

Neither of those...

The branch was created in r33643. So the object didn't exist in r33642 at
that URL, but it existed as /trunk .

Unfortunately r33642 was not in /trunk, so let's use 33641 for the
following example.

Today svn log shows the revision from trunk:

$ svn log -qr33641 http://svn.collab.net/repos/svn/branches/fsfs-pack
r33641 | kfogel | 2008-10-14 22:11:02 +0200 (Tue, 14 Oct 2008)

When the default for the peg-rev is changed to the operative revision it
will show an error.

I have two use cases where HEAD is the better default for the peg-rev:

1. When I work on a branch and find a suspicious line I run blame and then
svn log -r X.
2. Using svn log -r X:Y on a release branch to get the info for the

In my own repos I looked maybe 2 or 3 times at a deleted node, but I
pretty often do one of above use cases. So I prefer the default peg-rev as
it is now.


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-30 02:08:59 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.