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

Re: description of Peg Revision Algorithm is incomplete

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Mon, 29 Mar 2010 12:36:11 -0400

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

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