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-f...@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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
