You can't forget the most fun torture case for generalized move support that involves non-cyclic but directory hierarchy rearranging moves: (without branches)
Files in directory tree: BranchRoot\A\B\C\d.txt BranchRoot\A\B\e.txt BranchRoot\A\g.txt BranchRoot\A\F\h.txt mv BranchRoot\A\B BranchRoot\B mv BranchRoot\A BranchRoot\B\A yields: BranchRoot\B\A\g.txt BranchRoot\B\A\F\h.txt BranchRoot\B\e.txt BranchRoot\B\C\d.txt The most fun one with branches is making a conflicting and nonconflicting rearrangement of a similar nature to a branch of BranchRoot, and then determining where things should land when you merge BranchRoot into that other branch. I have occasionally wondered whether git's way of dealing with renames of files only is the more usable (from a human factors conflict resolution perspective) and less complicated approach vs. having generalized move/rename support, Bill P.S. If you don't want completely generalized move support, I certainly understand. It still gives me headaches even now thinking about it. On Wed, Jun 3, 2015 at 5:24 PM, Julian Foad <julianf...@gmail.com> wrote: > Julian Foad wrote: > > On the 'move-tracking-2' branch, 'svnmover' now simulates a WC, [...] > > danielsh commented on IRC [1]: > > svnmover in-memory wc will allow playing with cyclic moves? (cf comment > above > > simple_moves_within_a_branch()) That may not be a major use-case but > certainly > > a good torture test for the interfaces > > Yes, absolutely! > > Simple case: swap the names of two directories 'A' and 'B': > > [[[ > $ svnmover --ui=paths -U file://$PWD/repo > svnmover> mkdir A mkdir A/A mkdir B mkdir B/B commit > A A > A A/A > A B > A B/B > Committed r1: > --- diff branch B0 at / > A A > A A/A > A B > A B/B > svnmover> mv A tmp mv B A mv tmp B > V tmp (from A) > V A (from B) > V B (from tmp) > svnmover> status > --- diff branch B0 at / > M r A (renamed from .../B) > M r B (renamed from .../A) > svnmover> commit > Committed r2: > --- diff branch B0 at / > M r A (renamed from .../B) > M r B (renamed from .../A) > svnmover> ls . > . > A > A/B > B > B/A > ]]] > > Now what shall we do with that cyclic-move commit? Merge it somewhere, > perhaps? > > [[[ > # First we'll make a branch of the initial state we had in rev 1 > svnmover> branch .@1 br1 commit > A+ br1 (branch B5) > Committed r3: > --- diff branch B0 at / > A br1 (branch B5) > --- added branch B5 at /br1 > svnmover> ls br1 > . > A > A/A > B > B/B > svnmover> ls . > . > A > A/B > B > B/A > br1 (branch B5) > > # Now we'll make some moves in branch br1 > svnmover> mkdir br1/D mv br1/A br1/D/A mv br1/B br1/D/B ls br1 commit > > # Now we'll merge that cyclic move committed in r2, onto the branch br1 > svnmover> merge .@2 br1 .@1 > merging into branch B5 > M/V e1 B > M/V e3 A > merging into branch B5 -- finished > > # Perfect! > svnmover> ls br1 > . > D > D/A > D/A/B > D/B > D/B/A > ]]] > > (In trying a recipe similar to the above, I discovered a missing > conflict detection, and fixed it in r1683425, so thanks for that!) > > > > Speaking of which, I wonder how the branch reacts to histories that > contain an > > instance of 'svnmucc -U... rm foo cp head foo foo'. (do the various APIs > see that > > as a move, for example) > > The move-tracking-2 branch does not (yet) support migrating history > from a non-move-tracking repository, and the answer to this will > depend on how we choose to do that. (FWIW, the 'svnmover cp' command > creates a new element, currently with no connection to the source > element.) > > Further thoughts, experimental results? > > - Julian > > > [1] > http://colabti.org/irclogger/irclogger_log/svn-dev?date=2015-06-03#l155 >
