On Fri, Apr 27, 2012 at 15:07, Philip Martin <philip.mar...@wandisco.com> wrote: > Greg Stein <gst...@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@1, and B/f would be recorded as a >> (possibly-replacing) copy of A/f@2. >> >> It seems that for a true move, we'd move A@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@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@1"). Problem is: when you commit, B/f might be present, contrary to >> what the working copy looked like. A/f@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@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@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@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
