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
Received on Thu Nov 17 01:29:39 2005