Johan Corveleyn <jcorvel_at_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
Received on 2015-11-13 12:31:15 CET