[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: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2006-05-08 18:15:18 CEST

On Mon, 2006-05-08 at 08:58 -0700, Michael Brouwer wrote:
> In the proposal it states:
>
> >3. The path (known as PATHNAME in the grammar) used as the key to
> >determine which revision line to change is the subdirectory path being
> >merged from, relative to the repo root, with the repo url stripped from
> >it. The peg revision contained in the mergeinfo must always be
> >specified as part of pathname. It is not optional. It can always be
> >obtained from the information present about the urls being merged. The
> >peg revision *must be canonicalized to the last changed revision for
> >that directory/file's name*. I.E. if the merge specified
> >http://foo/bar@50, and the last time the name changed was in revision
> >43, the merge information should specify /bar@43 as the pathname +
> >pegrev. This is done because the information necessary to do it is
> >immediately available (copied_from), and without it, merging indirect
> >merge info is very difficult.
>
> 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.

> I was under the impression that svn's filesystems currently can't do
> forward tracking of changes.
This is true.

> So this implies that you can't really
> specify a revision range past the peg revision given, without making
> finding the node in that revision very expensive.
This is not true.

Peg revs simply specify the revision at which you wish to find the
object.
That is all.

>
> However if I read the above, the peg rev is supposed to be the last
> rev in which the path to a node changed.

Correct.

> Shouldn't it instead be the
> highest rev in which the path still points to the same node, and if it
> gets renamed, you can potentially move to the new node?
No. In fact, this would make the peg rev different for every merge
(unless we went back and fixed them all up), because the highest rev in
which a path still points to the same node changes with every commit
that doesn't change the path name.

I'm also not sure what you mean by "potentially move to the new node".
If you do a merge from the "new node", it should properly record it.

>
> Also wouldn't it make sense to allow the peg rev to be optional in
> that if it is not specified you use the highest rev in the list of
> revisions as the peg rev.

That seems like it would get a bit screwy in the face of renames without
manual editing.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 8 18:17:00 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.