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 <julianfoad_at_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 ._at_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 ._at_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
>
Received on 2015-06-06 09:04:43 CEST