Hi Stefan. Thanks for this set of feedback.
On 7 April 2015 at 21:59, Stefan Fuhrmann wrote:
[...]
> The only major problem IMO, is that "branchify" is currently
> too destructive: Applied within an existing branch, it seems
> to make merges from & to the respective sub-tree impossible
Yes, indeed, the current 'branchify' is quite destructive.
> I think I have a solution to that and will sketch that in a
> separate post.
That will be interesting to discuss.
> * nice to have: svnmover should have a history in interactive mode
OK, done in r1672066, by importing and using the 'linenoise' project.
> * Local paths don't get resolved as expect:
> svnmover> put ~/develop/svnmover/mail.txt trunk/sub/mail.txt
> svnmover: warning: apr_err=ENOENT
> svnmover: warning: W000002: Can't open file '~/develop/svnmover/mail.txt':
> No such file or directory
> svnmover> put /home/stefan/develop/svnmover/mail.txt trunk/sub/mail.txt
> svnmover: warning: apr_err=SVN_ERR_INCORRECT_PARAMS
> svnmover: warning: W200004: Argument
> '/home/stefan/develop/svnmover/mail.txt' is not a relative path or a URL
Fixed in r1672070. The 'put' command is the only command that accesses
a local path. An absolute path is now allowed here. ('~' is still not
recognized as a special symbol.)
> * Trying to branch from a non-branch-root segfaults:
> svnmover> branch trunk branches/maint
> Segmentation fault (core dumped)
(Where 'trunk' is not a branch-root, in this example.)
Fixed in r1672086.
> * Are element IDs arbitrary? From the output it seems that they use
> distinct ranges for each branch. I assume a "proper" implementation
> would have a two-dimensional ID space such as "e1.1" instead of "e101".
Each branch family has its own set of element ids that is in a
different 'name space' ('number space' if you like) from each other
family.
The element ids within a family are completely arbitrary. Currently
they are generated by a counter, so are sequential, but this is not
necessary. I made the counter in each family start from (100 *
family-number) for ease of reference by us humans. See '#define
PRETTY_IDS' in branch.c near line 162; undefining this makes them
start from 0 in each family.
The ids are already in a two-dimensional id space: (family-id, element-id).
> * Bogus error message when trying to create a sub-branch from a
> non-branch-root:
> svnmover> branch trunk/sub trunk/B
> svnmover: warning: W123456: source and destination must be within same
> outer branch; source is b10 inside b0, destination is in b10
> svnmover> ls .
> e0 .
> e1 branches
> e3 tags
> e6 trunk (branch ^.6)
> e7 branches/maint (branch ^.7)
> svnmover> ls trunk
> e100 .
> e101 sub
> e102 sub/mail.txt
This is by design. (I've made the error message a bit clearer in r1672086.)
In the current model, branching a subtree (of an existing branch)
means making a new branch, and the new branch must be *alongside* the
existing branch not *inside* it. The new branch is indeed a branch of
the selected subtree, but this operation does not convert the subtree
into a *subbranch*.
A subbranch is a member of a separate branch family. Branching a
subtree of an existing branch, on the other hand, creates another
branch in the same family.
> * Currently, branchify cannot "heal" or "undo" a dissolve operation.
> Can that limitation be lifted for any copy source / target pair?
> Can that limitation be lifted for undoing a 'dissolve' when no
> other commits were done to that (former) branch in the meantime?
Let's discuss 'branchify' in a separate thread.
> * Trying to rename a sub-branch root:
> svnmover> mv trunk/sub trunk/A
> mv: moving by copy-and-delete
> svnmover: warning: apr_err=SVN_ERR_ASSERTION_FAIL
> svnmover: warning: W235000: In file 'subversion/libsvn_delta/editor3e.c'
> line 293: assertion failed (eid != branch->sibling_defn->root_eid)
OK, there's a bug. This move should just work, no need for
'copy-and-delete'. What's happening is a confusion over whether the
move source is identified as 'the root element of branch <trunk/sub>'
or as 'the element named <sub> in branch <trunk>'.
I'm working on it.
[...]
> * The following sequence works, though (ommitting outputs):
> svnmover> branch trunk/sub trunk/B
> svnmover> branch trunk/sub trunk/A
> svnmover> rm trunk/sub
>
> Interesting state of branches/maint/sub vs. trunk/A & trunk/B:
> svnmover> ls-br-r
> [[[
[...]
> family 1 (BSIDs 10:12, EIDs 100:106)
> branch ^.6 bsid=10 root=e100 /trunk
> e100 .
> e104 B (branch ^.6.104)
> e105 A (branch ^.6.105)
> branch ^.7 bsid=11 root=e100 /branches/maint
> e100 .
> e101 sub
> e102 sub/mail.txt
> family 2 (BSIDs 20:23, EIDs 200:202)
> branch ^.6.104 bsid=21 root=e200 /trunk/B
> e200 .
> e201 mail.txt
> branch ^.6.105 bsid=22 root=e200 /trunk/A
> e200 .
> e201 mail.txt
> ]]]
When you say 'interesting state' I suppose you are remarking on the
fact that trunk/A and trunk/B are subbranches (in family 2) whereas
branches/maint/sub is not.
The 'branchify' command replaced the original subtree at 'trunk/sub'
with a subbranch also at path 'trunk/sub'. By design, it did not
replace the corresponding subtree at 'branches/maint/sub'...
> * Trying to merge a recent change:
> svnmover> merge branches/maint trunk trunk@6
> ! e102 <conflict>
> svnmover: warning: W123456: Merge failed: conflict(s) occurred
[...]
> * Merging into the opposite direction fails as well:
[...]
> How would that kind of conflict be permanently resolved?
... and so we get conflicts like this (which are of the kind "modified
versus disappeared"). Let's take this discussion to a new thread about
'branchify'.
- Julian
