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

Re: Merge tracking proposal, rev 2

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2006-05-17 22:17:58 CEST

Daniel Berlin wrote:
> On Mon, 2006-05-08 at 08:58 -0700, Michael Brouwer wrote:
>>
>>I like the idea of specifing a peg rev in the merge source. However
>>just what exactly what would /trunk@123:1-4691 mean?
>
> revisions 1-4691 of the object known as /trunk in revision 123.

Think about this question: What is the meaning of "/trunk" in that line with
respect to the "1-4691", and what is the meaning of "@123"?

"/trunk" is a path. "/trunk@123" looks up that path in a particular revision,
thus locating an "object" (file or dir). We can then trace that object's
history back to an earlier "working revision", but we can't reliably trace an
object from r123 forward to r124...r4691. (We might declare that a line
mentioning revisions later than the peg will only be written if the path hasn't
changed since the peg, but then the peg becomes redundant.)

It looks to me like you don't want a separate peg revision to be specified here
("/trunk:1-4691"). Instead, each revision in the list is implicitly the peg
revision in which the path is looked up (/trunk@1, /trunk@100, ...,
/trunk@4691), and so the line might refer to a series of different objects that
all existed at the same path at different times. I don't know if that's what
you want, but there's not necessarily a problem with it.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 17 22:18:39 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.