Move tracking -- creating a commit editor & Ev1 conversion shims

[Julian Foad <ju...@btopenworld.com>]

On the 'move-tracking-2' branch I have checked in an API sketch for a move-tracking commit editor API. (It contains two alternative designs in one, side by side, in fact.) 

I've called it "svn_editor3_t" (Ev3 for short) for the time being, not wanting to rip out or change the current "Ev2" just yet; but once we get this one a bit more definite, we can rename it to "svn_editor_t" (Ev2) replacing the current Ev2.

Based on recent discussions, the kind of editor we're looking at here is one that works with a per-node concept of branching -- without the idea of a designating certain nodes as "branch root" nodes, nor the idea of "elements" belonging to a branch family. Those ideas of constraining sets of nodes to be branched all together would be part of a higher layer of design.


Why refer to it as a "commit editor"? Because there are certain requirements that differ between a commit editor, an update/switch editor, and an editor used to drive a diff into the client-side merge code. I just want to concentrate on one of them, since that's quite enough to think about, before moving on to the others.

The most important thing to do next, and what I am doing now, is to write


  Ev3-to-Ev1 and Ev1-to-Ev3 converters

I think that will enable us/me to understand better how the old and new concepts fit together, and also enable us to build working code on top of existing code.
- Julian

Re: Move tracking -- creating a commit editor & Ev1 conversion shims

[Julian Foad <ju...@btopenworld.com>]

Branko Čibej wrote:

> Whilst node-specific addressing is acceptable on the server side,
    and perhaps even in the RA layer (perhaps with node IDs wrapperd in
    entry props and therefore stored in the wc.db), I'd really not want
    to expose node IDs to the client API, or make them visible to users.


Ack. I'm not currently suggesting we expose them to users.

- Julian

Re: Move tracking -- creating a commit editor & Ev1 conversion shims

[Branko Čibej <br...@wandisco.com>]

On 03.07.2014 19:34, Julian Foad wrote:
> On the 'move-tracking-2' branch I have checked in an API sketch for a move-tracking commit editor API. (It contains two alternative designs in one, side by side, in fact.) 
>
> I've called it "svn_editor3_t" (Ev3 for short) for the time being, not wanting to rip out or change the current "Ev2" just yet; but once we get this one a bit more definite, we can rename it to "svn_editor_t" (Ev2) replacing the current Ev2.
>
> Based on recent discussions, the kind of editor we're looking at here is one that works with a per-node concept of branching -- without the idea of a designating certain nodes as "branch root" nodes, nor the idea of "elements" belonging to a branch family. Those ideas of constraining sets of nodes to be branched all together would be part of a higher layer of design.

Whilst node-specific addressing is acceptable on the server side, and
perhaps even in the RA layer (perhaps with node IDs wrapperd in entry
props and therefore stored in the wc.db), I'd really not want to expose
node IDs to the client API, or make them visible to users.

-- Bane



-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com