On Fri, Nov 13, 2015 at 11:30:59AM +0000, Philip Martin wrote:
> 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.
This makes a lot of sense. But it doesn't explain why this code
needs to be merged to trunk. The investigation could just as well
continue on a branch, could it not?
Because it doesn't sound like what's holding us back is the branch.
Is encouraging more collaboration on this project the only reason
for merging to trunk? If so, why do you expect more collaboration
because of this merge? If someone is genuinely interested, the cost
of checking out and building another branch is not very high.
Received on 2015-11-13 12:51:17 CET