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

Re: [Issue 4100] 'svnrdump dump' should honor the peg revision syntax

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 11 Jan 2013 14:52:12 -0500

On 01/11/2013 02:21 PM, Neels Hofmeyr wrote:
> OTOH, the user already supplied two revisions (-rN:M). I guess your
> suggestion is more correct ... but to me peg vs. operational revs have
> always felt overly complicated and unintuitive. Can't it, like, imply a
> peg revision of N, instead of HEAD? So to get the (more complex) case
> of HEAD's path node at where it was in revs N and M, I'd have to say
> -rN:M path_at_HEAD. That would break with the other svn client UI, right?

From time to time, folks have strugged with the peg revision algorithm's
application, so you aren't the first. But the current defaults are the ones
that make the most sense, IMO, and yes -- any change here will break the
patterns used for the better part of a decade here.

> Hmm, what does svnrdump actually do upon reaching a copy-here? Does it
> continue dumping revisions of a different path? Does the normal peg-rev
> thang even apply to svnrdump like it does to 'svn log'?

Hrm. You know, the 'svnrdump dump' usage itself is just plain broken. It
appears to mean "dump the history of URL, perhaps for only a revision
range", but it really doesn't. It means "dump the history of the
repository, perhaps for only a revision range, but filtering out any changes
outside of the subtree whose path is the portion of URL relative to the
repository root URL." We should have never allowed the tool to give the
impression that it is tracing the history of a single resource (and its
path-wise children). With that in mind, I'm convinced that adding support
for the peg revision syntax in svnrdump would only make matters worse.

> On the same thought, I'd love to be able to do
> $ svn rm ^/path
> Committed revision 7
> $ svn log ^/path
> and be told that ^/path was removed in revision seven, instead of that
> ^/path does not exist. I *know* that it exists, *somewhere* in
> history! Just, svn makes it awfully hard to find out where.
> I've been wondering for a while: what *is* the best way to find out in
> which revisions a given fixed path has existed and in which not?

We have an RA API which attempts to answer this question:
svn_ra_deleted_rev(). I can't opine regarding its value/quality.

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2013-01-11 20:52:46 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.