Stefan Fuhrmann wrote in the "[RFC] An element-based 'svn merge'" thread:
> A while ago I've been thinking about how to store the EID assignments
> in FSFS and FSX. Adding (root, branchID, EID) -> (noderev, parent)
> and (root, path) -> EID mappings should be easy enough. My guess
> is that it would take 1 week to do code + another one to get functional.
> And then X amount of time to test & stabilize.
>
> Is repo-side support for branches and EIDs even useful at this point?
> Do we know enough of what their semantics would be? If so, I'd be
> happy to post a design sketch.
Before we consider storing branch and element ids in the repo, we need
to consider how branches are to be represented in the repo. The new
'merge' command (proposed in that other thread) has the luxury of
being able to assume that each of its three input trees is the whole
or part of a single branch. That's not the case for a whole revision
tree, at least not in the current Subversion.
If we are going to retain the idea that Subversion maps each branch to
a path, then we have a couple of plausible options, something like
these:
* non-nested branches, plus a new top-level index that maps each
branch to a path (default: 'trunk', 'branches/*', 'tags/*'), where a
branch path is analogous to a branch name (so '/branches' itself would
not be a 'real' directory that could be checked out and merged to,
etc.);
* a nesting scheme, such as svnmover implements, which tries to
retain the flavour of Subversion's current arbitrarily nestable
branching;
May I invite you to explore how svnmover does nested branching. Try this:
$ svnmover -U $REPO
svnmover> mkbranch trunk commit
A trunk (branch B0.-2)
Committed r1:
--- diff branch B0:e0 at /
A e1 0/trunk (branch B0.1)
--- added branch B0.1:e2 at /trunk
svnmover> ls .
eid parent-eid/name
--- ----------/----
e0 .
e1 0/trunk (branch B0.1)
svnmover> ls trunk
eid parent-eid/name
--- ----------/----
e2 .
svnmover> info trunk
Element Id: 1
Base Revision: 1
Base Branch: B0
[...]
Element Id: 2 (branch root)
Base Revision: 1
Base Branch: B0.1
[...]
Notice how the repository-root-relative path '/trunk' maps to two
elements: (B0 e1) and (B0.1 e2). In fact, the path maps to the
parent-eid & name (we might say "the top half") of element (B0 e1),
and the payload ("bottom half") of element (B0.1 e2). That's because
when we modify the payload (i.e. properties) of a branch root dir, we
want that to be treated as a change within the inner branch, that we
can merge to another branch, whereas trunk's parent-and-name belongs
to the outer branch, if any ("trunk was renamed to branch1" isn't a
change that needs to be merged back from branch1 to trunk).
If you're game for handling a bit more complexity, you might also want
to look at how svnmover currently maps branches to repo paths:
$ svn log -r1 -vq $REPO
[...]
Changed paths:
A /top0
A /top0/trunk
svnmover is currently set up to permit experimenting both with
hierarchies of nested branches, and with non-nested branches. I have
inserted the 'top0' prefix path in front of the user-visible paths as
a location for storing the content of hierarchy 0. The 'tbranch'
('top-level branch') command makes other top-level branches at '/top1'
etc. (except it's currently broken and crashes). If we decide to go
with nesting only, in the end, then we would only need one hierarchy
and could lose the 'top0/' prefix again. If we decide to go with only
non-nested branches, in the end, then again we won't use '/top<N>'
prefixes, probably.
- Julian
