Johan Corveleyn <jcor...@gmail.com> writes: > I'm still very much wondering how this will fit in with the general > direction of Subversion ... but as you say, that's something we need > to work out together. That, for me, is currently the biggest part of > the puzzle.
Julian and I talked about this yesterday, I'll try and explain a few things. What we now call editor v1 has 'copyfrom' fields. These fields were never really used but there was a vague assumption that they might be useful. It turns out that 'copyfrom' isn't enough to do useful move tracking. We also have Ev2 which provides more move information. This is also not fully implemented and while it looks as if will be sufficient in simple cases it is still not clear that it works in general. A typical problem is an update combining several revisions that have moves. Given the dead-ends that we have encountered in move tracking we want a new approach. We want a working system of move tracking that allows us to prototype the information transfer to see what works. The prototype system gives IDs to files and directories that are stored on server and visible to the client. The client and server transfer these IDs across the wire to describe moves. We want to show that the client can transfer an arbitrarily complicated set of moves to the server and that the server can store it. We want to show that the server can transfer those complicated moves back to the client in a way that is useful. We want to show this works for multiple revisions, between branches, on subtrees, etc. The protype currently has bits that are 'fake' in that they exist only to allow the other bits to work. The backend repository storage of IDs is 'fake': there is an implementation but it bears no relationship to any final version. Any release will need a 'real' implementation but the prototype is not concerned about how IDs are stored. We want to work out what move tracking will require of the storage before implementing the storage. The network protocols are 'fake' and will remain that way for some time. There is a 'working copy' in svnmover and it is obviously 'fake' as it is memory-based. However it the working copy is intended to show that the moves received from the server can be used. The bits that are not 'fake' are the branching state and branching transaction stuff as well as the merging and conflict stuff. These are the bits that show how moves can be described, transferred and combined in a way that allows the repository to store them and the client to use them. -- Philip Martin WANdisco
