On Fri, Apr 27, 2012 at 12:59, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Greg Stein <gstein_at_gmail.com> writes:
>...
>> Wouldn't the B/f line at op_depth==1 have not-present to indicate that
>> it was deleted?
>
> No. Before delete:
>
> op-depth local-relpath presence
> 1 B normal
> 1 B/f normal
>
> Delete B/f:
>
> op-depth local-relpath presence
> 1 B normal
> 1 B/f normal
> 2 B/f base-deleted
>
> Replace B/f
>
> op-depth local-relpath presence
> 1 B normal
> 1 B/f normal
> 2 B/f normal
Ah, right. Thanks for the correction.
>
>>> +
>>> + Now update A and go through the mixed-revision base tree: we can't represent the mixed-revision copy since that would require B/f at op-depth=2 to record both A/f_at_2 and X_at_1.
>>
>> Hm? I would expect the A/f_at_2 to be in the op_depth==1 line, and B/f at
>> op_depth==2 to continue to refer to X_at_1.
>
> No. When we have mixed-rev A and A/f and A gets moved to B the result
> is:
>
> op-depth local-relpath presence revision
> 0 A normal 1
> 0 A/f normal 2
> 1 B normal 1
> 1 B/f not-present
> 2 B/f normal 2
>
> and that's a problem if op-depth=2 B/f is already used for somethin
> else.
Hmm. It seems there would be lots of problems with an 'svn move' of a
mixed-revision working copy, once we record it as a true move.
Stepping back, in 1.7, 'svn move' of a mixed-rev working copy is
actually just a set of copies (followed by a big delete). Each time a
revision differs from its parent, it performs another copy operation.
Thus, B is a copy of A_at_1, and B/f would be recorded as a
(possibly-replacing) copy of A/f_at_2.
It seems that for a true move, we'd move A_at_1 to its new location. Any
children at different revisions would then become *copies*. In your
above example, pre-move, A/f might not even exist @1. (thus the
not-present for B/f) ... so the 'svn move A B' operation would also
do: 'svn copy A/f_at_2 B/f'.
If you now delete B/f, then it is effectively reverting the copy that
occurred (still leaving B/f as not-present, aka "dunno if it is in
A_at_1"). Problem is: when you commit, B/f might be present, contrary to
what the working copy looked like. A/f_at_1 might have been present, and
it now shows up as B/f post-commit.
In short, I think the schema is still fine. The trick is that children
of a mixed-rev move become copies. I don't see any other way to
represent the metadata in a mixed-rev move.
Cheers,
-g
Received on 2012-04-27 20:21:17 CEST