Greg Hudson wrote:
> On Mon, 2010-03-29 at 12:07 -0400, Julian Foad wrote:
>> Some possible interpretations are
>> * Find the repository URL of './some/deep/file.c', and [...]
> I'll mention a related interpretation, which is to use the repository
> URL of the parent directory and append file.c to it.
> This is a little weird, and probably only makes sense as a fallback if
> the file doesn't have a URL (e.g. because it doesn't exist in the
> working copy), but it would let you do things like "svn cp
> deleted-file_at_1000 ."
> I may have filed an issue about this somewhere, possibly in the days
> before peg-revs.
I was about to post that one place where there might be a lack of
documentation is not so much in understanding what the peg revision means,
but in understanding the "working copy path" -> "peg path" translation. The
peg path algorithm works in repository path/rev space only. So any time a
working copy path needs to be fed into that algorithm, it must be translated
into a repository path (which on the client side comes in the form of a
repository URL). To make that transformation, Subversion will resolve any
working copy target path into its URL *as recorded in the working copy*,
then use that as the path portion of the (path, peg-rev) input to the peg
And yes, as Greg points out, when a working copy object has no URL (because
it is new and scheduled for addition), then the URL is probably constructed
by tacking the object's basename onto the parent's URL.
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-03-29 18:36:42 CEST