[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.