A reminder of the bug:
Given a repos directory A and child node A/foo:
- copy A/foo A/foo2; commit
- copy A A2; commit
- vi A2/foo A2/foo2; commit
The bug manifests itself in an error about two nodes trying to
acquire the same new node revision ID. The root cause, though, is
that filesystem is trying to treat A2/foo and A2/foo2 as being on
the same branch, despite the fact that they are not. 'A/foo' and
'A/foo2' were on different branches, then we branched their parent
directory 'A', so 'A2/foo' and 'A2/foo2' should also be on
different branches.
After chatting with Bitt Tutt about this bug, I've set out to code the
solution:
Instead of copied subtree nodes blindly assuming the Copy Id of
their parents, some determination about whether or not that node is
on the same branch as the parent must happen. If the child is on
the same branch as the parent, it assumes the parent's Copy Id;
else, a new Copy Id is generated for it.
An implementation question lingers:
In generating this new Copy Id for the branched branched child
node, should that Copy Id look like a first-class COPY or not.
That is, should the question svn_fs_copied_from () on that node
reply that yes, that node was copied though no svn_fs_copy()
operation actually occured as part of that revision? Or, should we
populate the new row in the `copies' table with some magic that
means "This wasn't a real copy, just a new ID handed out to a
branch of a branch"?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 2 23:04:55 2002