On Fri, Apr 27, 2012 at 12:59, Philip Martin <philip.mar...@wandisco.com> wrote: > Greg Stein <gst...@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@2 and X@1. >> >> Hm? I would expect the A/f@2 to be in the op_depth==1 line, and B/f at >> op_depth==2 to continue to refer to X@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@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. 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
