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?
I was under the impression that svn's filesystems currently can't do
forward tracking of changes. 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.
However if I read the above, the peg rev is supposed to be the last
rev in which the path to a node changed. 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?
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.
Michael
On 5/6/06, solo turn <soloturn@gmail.com> wrote:
> as the only possibility to solve that problem up to now was svk, and i
> guess many people know svk: what is the difference between svk and
> your proposal?
>
> -solo.
>
>
> On 5/6/06, Daniel Berlin <dberlin@dberlin.org> wrote:
> > This is revision 2 of the proposal.
> > I have removed revision properties, added some examples, tightened up
> > the semantics, addressed some of the questions various people raised
> > about how things work in practice,
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Received on Mon May 8 17:59:24 2006