On Fri, Apr 27, 2012 at 15:07, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Greg Stein <gstein_at_gmail.com> writes:
>...
>> 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.
>
> That's not correct. Rows that are not-present at op-depth > 0 shows up
> as 'D' in status and causes commit to send a delete if required.
Oh, right. That is effectively a delete operation. 'not-present' at
op_depth==0 is what I'm thinking of.
Can we introduce a similar concept for moved nodes? "I'm not sure of
the status of this relpath in the repository. We have no local
information." Basically, a new form of absent.
>> 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.
>
> One of the big problems with mixed-rev copies is that the committing the
> delete half is tricky since parts of the deleted tree are out of date.
Doesn't seem too tricky. Couldn't you do a depth-first deletion of the
source side? At each step, delete PATH_at_REV. That will ensure the
source tree still exists, unmodified, for all the various revisions.
This deletion process can be optimized by deleting subtrees where
rev_of(node) != rev_of(parent(node)). Whack whole subtrees that
consist of the same revision. As you move up, eventually you get to
OP_ROOT_at_REV and delete it.
It seems that would produce all the correct out-of-date checks. For a
single-rev source, it would devolve to a single delete(OP_ROOT_at_REV).
> There is a similar problem with single-rev moves when the source is
> out-of-date. This means that move isn't very useful until it supports
> update as that allows the out-of-date sorce to be brought up-to-date.
Not sure here. This just seems like a standard "incoming-edit vs
local-delete", like what we have in 1.7. The user can resolve to
delete (move) the edited file, too, or cancel the move and incorporate
the edits.
This seems to be a bit orthogonal to the representation issues which
started this thread, however.
> Running update also makes mixed-rev source into single-rev so I'd be
> happy not to support mixed-rev move, except that update a single-rev
> tree from one rev to another goes through mixed-rev.
Yup, but I think we "have to" support mixed-rev moves; otherwise, it
looks like a regression.
Cheers,
-g
Received on 2012-04-27 21:51:10 CEST