You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Christian Stork <cs...@ics.uci.edu> on 2005/11/13 21:45:11 UTC
Proposal for referencing related paths
This proposal is a simplification of the previous proposals on easy
comparision of trunk, branches, tags, etc.
The problem that I want to solve (very inprecise but concise) is:
"Given a repo path p1 and a branch +b find the corresponding
path p2 on the branch +b requiring minimal annotations to the
repository."
We have two properties:
- 'svn:treeroot' contains the path of a related tree, usually the trunk.
- 'svn:projectroot' might be empty or contain a mapping of branch
nicknames to subdirectories (as discussed in another thread).
The following algorithm makes use of the idea of a node's refpath
("refence path"). Every repo node's path is its own refpath unless one
of it's parents is a treeroot, i.e., a directory with the svn:treeroot
property set. In that case its refpath is the concatenation of the
treeroot's refpath and its relative path to the treeroot. For example,
the root of a branch would have a svn:treeroot property that points to
the corresponding path on the trunk.
Using refpaths has the advantage that comparisons among branches are
reduced to comparisons of their refpaths. The following "algorithm"
should make this clearer.
1. Determine reference path:
Starting at p1 walk up the repo dir tree until we hit a treeroot. (This
will always happen if we assume that / is a treeroot.)
p1's-refpath = treeroot's-refpath / p1's-path-relative-to-treeroot
2. Locate branch:
Starting from treeroot's-refpath on upward look for projectroots. If a
projectroot's subdir or nickname is equal to +b we found our branch.
(There could be several projectroots, which would solve Juilian's
problem posed in the another thread.)
3. Determine corresponding path:
p2 = +b's-path / p1's-refpath-relative-to-projectroot
Which properties need to be set to make this algorithm work for our
standard repository layout?
repo root "/":
svn:treeroot = "", svn:projectroot = ""
branch /branches/experimental corresponding to /trunk/some/sub/dir/X:
svn:treeroot = "/trunk/some/sub/dir/X"
This provides branch identification of the form +branches/experimental.
For a shorter branch description, such as +b-exp one needs a projectroot with
content "b-exp branches/experimental" in the repo root.
Another standard setting for root's svn:projectroot might be (in some
syntax):
* /branches/*
* /tags/*
which would allow +experimental.
Well, that got a little long and I didn't even consider nested
treeroots ;-),
Chris
--
Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for referencing related paths
Posted by Christian Stork <cs...@ics.uci.edu>.
On Wed, Nov 16, 2005 at 05:54:04PM +0000, Julian Foad wrote:
> (This reply of mine probably isn't very useful except maybe for Christian
> if he wants to refine the proposal and write it out in a more definite
> form.)
Thanks for the reply, Julian. Indeed I already thought about clarifying
the proposal since it was admittedly hard to understand. I'll post an
updated version later. For now I just comment on your comments.
> Christian Stork wrote:
> >This proposal is a simplification of the previous proposals on easy
> >comparision of trunk, branches, tags, etc.
> >The problem that I want to solve (very inprecise but concise) is:
> > "Given a repo path p1 and a branch +b find the corresponding
> > path p2 on the branch +b requiring minimal annotations to the
> > repository."
> >We have two properties:
> >- 'svn:treeroot' contains the path of a related tree, usually the trunk.
> We need a better name. "treeroot" is confusing, as every directory is the
> root of a tree.
I agree and I wanted to change it to svn:refpath (and svn:projectroot to
svn:parallel) but refrained from it since I thought the old names would
make their relationship to the previous discussion clearer.
> What tree does this point to? - can we be a bit more
> specific than "a related tree"? Is it normally the tree from which this
> one was last copied?
Normally yes, but it doesn't have to be. Imagine a project that wants
to keep many similar trees in a subdirectory of trunk, e.g., similar
configurations for different platforms or the like. I don't know if
this is a relevant use case but it seems plausible to maintain these
trees as parallel trees.
> If so, the source of the copy is already known in the
> repository so we shouldn't have to give this property a value.
Maybe. I didn't want to make tree copying a requirement for the proposal
to work, but it certainly would cover the basic use case. It has the
advantage that it magically works. OTOH, given multiple tree moves or
copies it might become a bit hard to understand what's happening.
For example, how would we deal with a copy of a branch? Is that a
branch of the branch as the copy history would suggest or should we
maintain the reference to trunk?
> >- 'svn:projectroot' might be empty or contain a mapping of branch
> > nicknames to subdirectories (as discussed in another thread).
> Clarification: "svn:projectroot" is to be set on the root of each project,
> and indicates that the word used after "+" on the command-line ("branches",
> "trunk" etc.) can be found in this directory (on which this property is
> set). The property value should be empty unless nicknames are wanted.
Thanks, I'll use that in version 2 of the proposal. :-)
> >The following algorithm makes use of the idea of a node's refpath
> >("refence path"). Every repo node's path is its own refpath unless one
> >of it's parents is a treeroot, i.e., a directory with the svn:treeroot
> >property set. In that case its refpath is the concatenation of the
> >treeroot's refpath and its relative path to the treeroot. For example,
> Clarification: by "the treeroot's refpath" you mean the value of the
> property, not the path on which that property is set.
Correct.
> >the root of a branch would have a svn:treeroot property that points to
> >the corresponding path on the trunk.
> OK, so we have to choose one line of development as the canonical tree that
> all the other ones will point to. Normally this will be "trunk", but the
> project administrator could choose to use any other line (a branch or a
> tag) instead (e.g. if they have a branches-only set-up with no trunk) and
> it should still work just the same.
Right.
> >Using refpaths has the advantage that comparisons among branches are
> >reduced to comparisons of their refpaths.
> I don't really get that sentence, but never mind.
What I meant is that two branches can refer to eachother (i.e., use of
+b2 while in b1) even though they don't contain any information about
eachother, e.g., no property saying "b1 is parallel to b2". They
can refer to eachother because their refpaths share a prefix, which
most often will be a the trunk.
> > The following "algorithm" should make this clearer.
> >1. Determine reference path:
> >Starting at p1 walk up the repo dir tree until we hit a treeroot. (This
> >will always happen if we assume that / is a treeroot.)
> > p1's-refpath = treeroot's-refpath / p1's-path-relative-to-treeroot
> That's basically always going to be
> "the-trunk/p1's-path-relative-to-treeroot" regardless whether we start from
> a branch or the trunk.
Yes.
> >2. Locate branch:
> >Starting from treeroot's-refpath on upward look for projectroots. If a
> >projectroot's subdir or nickname is equal to +b we found our branch.
> (Complexity note: we probably need to do a peg-revision thing here to make
> sure we can still find the corresponding object even if it has been moved
> since the branch was made. This applies to all the proposals of this
> nature.)
Probably. I did not really think this through yet.
...
> So, in the realistic example of the Subversion project's source repository,
> that would mean that each of
> /branches/1.0.x
> /branches/1.1.x
> ...
> /tags/1.0.0
> /tags/1.0.1
> ...
> would have "svn:treeroot=/trunk". In order to make this happen
> automatically, we would like to set that property on "/trunk" itself so
> that it is copied to each branch and tag. Is that OK?
Sure, that's a good idea, but note that this does not automagically do
the right thing for branches or tags of subdirectories of /trunk.
> >This provides branch identification of the form +branches/experimental.
> >For a shorter branch description, such as +b-exp one needs a projectroot
> >with
> >content "b-exp branches/experimental" in the repo root.
> >Another standard setting for root's svn:projectroot might be (in some
> >syntax):
> >* /branches/*
> >* /tags/*
> >which would allow +experimental.
> Yes. I don't know whether that would be best or not.
Me neither. :-)
> >Well, that got a little long and I didn't even consider nested
> >treeroots ;-),
> That's not long for what it is. I think only the people who have been
> following the related threads closely will be able to understand it.
Sorry for that. I'll try to make time to enhance my presentation.
Thanks,
--
Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for referencing related paths
Posted by Julian Foad <ju...@btopenworld.com>.
(This reply of mine probably isn't very useful except maybe for Christian if he
wants to refine the proposal and write it out in a more definite form.)
Christian Stork wrote:
> This proposal is a simplification of the previous proposals on easy
> comparision of trunk, branches, tags, etc.
>
> The problem that I want to solve (very inprecise but concise) is:
>
> "Given a repo path p1 and a branch +b find the corresponding
> path p2 on the branch +b requiring minimal annotations to the
> repository."
>
> We have two properties:
>
> - 'svn:treeroot' contains the path of a related tree, usually the trunk.
We need a better name. "treeroot" is confusing, as every directory is the root
of a tree. What tree does this point to? - can we be a bit more specific than
"a related tree"? Is it normally the tree from which this one was last copied?
If so, the source of the copy is already known in the repository so we
shouldn't have to give this property a value.
> - 'svn:projectroot' might be empty or contain a mapping of branch
> nicknames to subdirectories (as discussed in another thread).
Clarification: "svn:projectroot" is to be set on the root of each project, and
indicates that the word used after "+" on the command-line ("branches", "trunk"
etc.) can be found in this directory (on which this property is set). The
property value should be empty unless nicknames are wanted.
> The following algorithm makes use of the idea of a node's refpath
> ("refence path"). Every repo node's path is its own refpath unless one
> of it's parents is a treeroot, i.e., a directory with the svn:treeroot
> property set. In that case its refpath is the concatenation of the
> treeroot's refpath and its relative path to the treeroot. For example,
Clarification: by "the treeroot's refpath" you mean the value of the property,
not the path on which that property is set.
> the root of a branch would have a svn:treeroot property that points to
> the corresponding path on the trunk.
OK, so we have to choose one line of development as the canonical tree that all
the other ones will point to. Normally this will be "trunk", but the project
administrator could choose to use any other line (a branch or a tag) instead
(e.g. if they have a branches-only set-up with no trunk) and it should still
work just the same.
> Using refpaths has the advantage that comparisons among branches are
> reduced to comparisons of their refpaths.
I don't really get that sentence, but never mind.
> The following "algorithm" should make this clearer.
>
> 1. Determine reference path:
> Starting at p1 walk up the repo dir tree until we hit a treeroot. (This
> will always happen if we assume that / is a treeroot.)
>
> p1's-refpath = treeroot's-refpath / p1's-path-relative-to-treeroot
That's basically always going to be "the-trunk/p1's-path-relative-to-treeroot"
regardless whether we start from a branch or the trunk.
> 2. Locate branch:
> Starting from treeroot's-refpath on upward look for projectroots. If a
> projectroot's subdir or nickname is equal to +b we found our branch.
(Complexity note: we probably need to do a peg-revision thing here to make sure
we can still find the corresponding object even if it has been moved since the
branch was made. This applies to all the proposals of this nature.)
> (There could be several projectroots, which would solve Juilian's
> problem posed in the another thread.)
>
> 3. Determine corresponding path:
>
> p2 = +b's-path / p1's-refpath-relative-to-projectroot
>
>
> Which properties need to be set to make this algorithm work for our
> standard repository layout?
>
> repo root "/":
> svn:treeroot = "", svn:projectroot = ""
>
> branch /branches/experimental corresponding to /trunk/some/sub/dir/X:
> svn:treeroot = "/trunk/some/sub/dir/X"
So, in the realistic example of the Subversion project's source repository,
that would mean that each of
/branches/1.0.x
/branches/1.1.x
...
/tags/1.0.0
/tags/1.0.1
...
would have "svn:treeroot=/trunk". In order to make this happen automatically,
we would like to set that property on "/trunk" itself so that it is copied to
each branch and tag. Is that OK?
> This provides branch identification of the form +branches/experimental.
> For a shorter branch description, such as +b-exp one needs a projectroot with
> content "b-exp branches/experimental" in the repo root.
> Another standard setting for root's svn:projectroot might be (in some
> syntax):
>
> * /branches/*
> * /tags/*
>
> which would allow +experimental.
Yes. I don't know whether that would be best or not.
> Well, that got a little long and I didn't even consider nested
> treeroots ;-),
That's not long for what it is. I think only the people who have been
following the related threads closely will be able to understand it.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org