Move tracking can clearly make ones head spin. :)
Brane: Could Julian and Stephan be asking about how to map between
arbitrary revisions thinking of tree merge scenarios?
That's what always gave me heart burn with the current Noderev behavior and
envisioning real moves in Subversion.
In thinking deep thoughts about this in the deep dark dark distant past I
came up with several interesting thoughts: (sadly none of these are
completely thought out answers, but they did seem like thoughts worth
pondering wrt Subversion if you haven't before)
* Have you considered having the noderev own the node's name instead of how
the parent directory currently owns it? This way it would be natural to
make the destination of the move a mutated noderev.
i.e. mv /trunk/A -> /trunk/B COULD do this in the DAG:
* make /trunk/A mutable by ONLY updating the TxnID of the Noderev.
* Edit the name field of the noderev from A ->B
More complicated example:
mv /trunk/A/B/C -> /trunk/A/D COULD do this to the DAG:
* make /trunk/A/B/C mutable by ONLY updating the TxnID of the Noderev.
* remove it as an entry from /trunk/A/B and add it as an entry to
/trunk/A
However... what do you do for this case: (C could have a zero copy_id here
I think)
mv /trunk/A/B/C -> /blah could do this to the DAG:
????
or this one: (presuming C has a non-zero copy_id before move)
mv /branch/A/B/C -> /blah2
????
or (same as the last one, but C was the destination of the "soft-copy")
???
The enumeration of the rest of the cases is left as an exercise for the
reader. :)
* The implementation of rename tracking should ensure you enable all
scenarios you desire for dealing with merging renamed items from branch A
to branch B. (the tree shape part of the merge of course)
That is, if you care, some systems don't/won't/did and then decided not
to/whatever. Merging renames leads to lousy complex edge case tree
conflicts that need usable (in the easy to use usability sense) resolution
UI to solve. .
* If moves are lazy, and you need to track moves differently from copies
then consider: What if you expanded a noderev with a new move_id part? :)
Some systems solve this problem by recording in the merge history the
(noderev, copyid) equivalents the merge history was recorded from. (Not
just when merge was invoked, but also initial merge history for the initial
copy.) That could also be a way of determining where /trunk/A/B/C/q.c is in
/branch after a number of arbitrary number of directory hierarchy changes
and file name alterations somewhere in /branch. These systems don't easily
support merge history elision concepts though. (As well as requiring
specialized merge history storage at the FS level for performance reasons.)
Of course, I would think merge history could benefit from specialized
storage anyway. :)
If you followed this approach the exact way the Noderev node_id/copy_id
changes might be less relevant.
Sorry for making your head hurt some more with these ancient nutty musings,
Bill
Received on 2013-09-28 12:07:48 CEST