Hi Stefan. You mentioned you have an idea about making 'branchify'
less 'destructive' -- that is, making it possible to start developing
in a subtree and then later treat that subtree as a sub-branch without
breaking its history.
Currently the 'svnmover branchify' command creates a completely new
branch (a member of a different family that is nested inside the
original branch), copies the *content* of the designated subtree into
the new branch, and deletes the original subtree, and renames the new
subbranch-root element back to the name of the original subtree. That
is destructive, in the sense that although the history of the old
subtree is still present in the repository there is no modelling
mechanism to link the old history seamlessly to the new history.
I have gradually been re-evaluating my ideas about branch families.
Recently I changed the implementation to have only one family at each
level of nesting: the repo root and '/branches' dir are still in
family 0 as before, but all normal first-level branches are in family
1 even if they belong to different projects. And all second-level
subbranches in level 2, and so on. Compared with creating a new branch
family for each independent set of branches (each project, for
example), this has the advantage that the branches can later be
combined, while preserving their history, into a single bigger branch.
The svnmover test 'restructure repo: projects/ttb to ttb/projects'
demonstrates this (currently XFail due to no suitable UI being
available; I'll fix that soonish).
I still have a lingering compulsion to ensure that a subbranch is in a
different family from its outer branch, and that the nesting order of
branch families is fixed for all time. It seemed like if the subbranch
elements are in the same family, then there would be nothing to
distinguish it as a subbranch. And I wanted to prevent inversion --
where subbranch B is initially inside branch A but then after a series
of changes A might end up inside B.
However, I am not sure there is any reason for that. What is necessary
is that the subbranch must be distinguished as a subbranch -- but
perhaps it is OK if the subbranch is actually a branch of the same
family. And perhaps it is OK if the subbranch is a branch of any
family, even one that is or was also nested the other way around.
If it's true that we can allow a subbranch to be of any family, then
the algorithm for 'branchifying' would go like this:
* start with existing branch B of family F, with its root element e0
(currently at path 'trunk', let's say)
* we're going to turn the subtree at element eX (at path
'trunk/sub', say) into a subbranch S
1. create a new branch S in the same family F, but with its root
element designated as eX, its content being branched from the subtree
found at eX in the old branch; this new branch is not yet anchored at
a path
2. delete element eX from the outer branch P
3. create a new element eY in P, of kind 'subbranch-root', pointing
to S, and instantiate it at the same path where eX was
The result is that at path 'trunk/sub' there is now a 'place-holder'
element eY of type 'subbranch-root: branch S', and that subbranch is a
*branch* of the content that was there before. Thus its history flows
seamlessly across the that moment in time.
And then there is no more need for separate branch families.
I wonder if these thoughts are in line with yours?
- Julian
Received on 2015-04-09 14:58:19 CEST