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

Peg revisions inconsistent?

From: Tim Hill <tim_at_realmsys.com>
Date: 2005-06-08 22:01:34 CEST

I've been grinding through some svn tests with peg revisions, mostly to
get a clear handle on some of the subtleties of these. Unless I'm
missing something, there seem to be some significant inconsistensies in
how these are handled by the svn command-line tools.

First, I'm using SVN 1.2. Second, my understanding of a peg-rev is that,
in general, its used to specify a "starting rev#" for a particular URL
(before applying any -r constraints), and this is primarily used to
handle situations where the name of a file/folder has changed over time
(or been deleted).

My concern is that the "@REV" peg syntax seems to be inconsistently
applied in the various sub-commands in svn. So, for example, I can do
something like this:

    svn diff svn://server/repos/y_at_53 -r51:52

To diff revs 51/52 of file "y" pegged at rev 53 even if "y" was renamed
to "x" at rev 60. However, if I try this:

    svn log svn://server/repos/y_at_53

Then svn complains that "y@53" is not found. For the svn log command i
have to use the -r switch, not the peg-rev syntax. This concerns me for
two reasons:

1. Inconsistency. Why is a peg-rev accepted in some commands any not
others? This is confusing.
2. Parsing+future compatibility. Apparently, the svn log command doesn't
even parse the URL in the same way as (say) the svn diff command. svn
log seems to think that the filename is "y@53", not "y", which would
appear to be a bug.

Am I missing something here? Any comments welcome. While this is hardly
a show-stopper, it is kinda annoying.

--Tim

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 8 22:04:23 2005

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

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