Julian Foad <[email protected]> writes:
>> As you pointed out when a copy replaces a mv-away it is still necessary
>> to alter-dir two different nodes at the same path:
>>
>> 1. alter-dir A (children={...})
>> 2. mv-away A (id=...)
>> 3. copy A (src=...)
>> 4. alter-dir A (children={...})
>
> Well, that depends. There may be no need to issue the alter-dir on
> the original 'A' at this stage, we could wait until it arrives at its
> final path (move-here B (id="original A"), then alter-dir B).
I was initially thinking that we could require alter-dir to happen
before mv-away, then the alter-dir path would always be a path in the
original tree. However that doesn't work for copies where alter-dir has
to happen after the copy, or for moves from copies where, even if
alter-dir happens before the move, the path is still not a path in the
original tree.
So we have to allow
copy A B
alter-dir B (children={...})
which means there is little reason to require
alter-dir X (children={...})
mv-away X (id="original X")
mv-here Y (id="original X")
and prohibit
mv-away X (id="original X")
mv-here Y (id="original X")
alter-dir Y (children={...})
Another issue, there can be mv-aways inside copies and that allows
multiple mv-away at the same path:
svn cp X A
svn mv A/B/C C1
svn rm A/B
svn cp Y A/B
svn mv A/B/C C2
Here we have two mv-aways for A/B/C, one for the C copied from X/B/C and
one for the C copied from Y/C.
alter-dir / (children={..., C1, C2})
copy X A
mv-away A/B/C (id="something")
mv-here C1 (id="something")
copy Y A/B (replaces=...)
mv-away A/B/C (id="something else")
mv-here C2 (id="something else")
We can't use the source of the copy to make things unique either as that
could be copied more than once.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
