Branko Čibej <br...@wandisco.com> writes: > That said, I still do not understand why a different ID would be needed > before the copy-on-write happens. Is it because the client doesn't have > the full history available? If that's the case, I suggest we explore > this on a case-by-case basis, including determining how the initial > state of a working copy for each case can actually occur.
Is the FS going only able to provide the moves that apply between two consecutive revisions? Or is it able to provide the combined moves between arbitrary revisions? One way to provide the moves between arbitrary revisions is to iterate through the intervening revisions accumulating and combining the moves. That has the potential to be slow. Another way to provide the moves between arbitrary revisions is to have an id to path map per revision which allows the FS to find the path associated with a given id. However with lazy-copy this map is harder to implement. There is another aspect to the lazy-copy which is when does the new copy-id get assigned to the lazy children. If we commit move A/f A/g then move does not allocate a new copy-id and A/f has the same copy-id as A/g. I think we intend this to be true if the commit combines a move and a modification to the node. Now commit: copy A B here B gets a new copy-id and lazily copied children of B still have the old copy-id. Now what about this commit: move B/g B/h Does move preserve the copy-id so that B/h is still a reference to A/g? If the commit was a combined move/modification then B/h would have to get a new copy-id. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
