(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
> 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
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
> * /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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Nov 16 18:55:03 2005