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