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
