> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: woensdag 20 juli 2011 11:55
> To: Greg Stein
> Cc: Hyrum K Wright; Subversion Development
> Subject: Re: Editor v2: What's The Plan?
>
> On Tue, Jul 19, 2011 at 11:43:06PM -0400, Greg Stein wrote:
> > On Tue, Jul 19, 2011 at 21:27, Hyrum K Wright <hyrum_at_hyrumwright.org>
> wrote:
> > > And for the record, what are the benefits expected from all this work?
> >
> > Atomicity, cleaner memory/pool handling, better debug support, much
> > more understandable, more clear and clean, etc. Read
> > notes/editor-v2.txt... that has some data that may help to understand
> > what/why. One simple effect: it gets rid of the cancellation editor,
> > the debug editor, another commit debug editor, and the default editor.
> > All gone. All built-in.
>
> Besides those, I am expecting better support for handling moves.
>
> Here's a possible high-level roadmap which includes editorv2:
>
> For 1.8 I am planning to focus on improving local move support.
> The goals of this effort are described here:
> http://svn.apache.org/repos/asf/subversion/trunk/notes/moves
>
> We also need to convert the commit editor to editor v2 so the client
> can send a move operation to the server instead of sending two separate
> and apparently unrelated copy and delete operations.
It might be useful to use editor v2 for sending over file moves, but this is
not a requirement for handling file moves.
We overloaded the entry props feature a few times before and there is no
reason why we can't get file moves working properly on just the old editor.
Editor v2 is a huge task and we have only looked at a few problems we try to
solve with it.
We haven't even looked at the reporting, how to map the compatibility with
editorv1 and on possible security concerns.
> Then we will have to find a way to store this information on the server.
> I am thinking we'll have some sort of copy-to information cache.
> This has already been implemented for the BDB backend on a branch:
> http://svn.apache.org/repos/asf/subversion/branches/fs-successor-
> ids/BRANCH-README
> We still need an implementation for FSFS.
>
> Once we have that, we can convert update and merge to editorv2 so that
> the server can send move information back to the client, based on the
> copy-to information stored, and maybe even heuristics for cases where
> the information is not available (i.e. for revisions committed before
> copy-to info was stored).
>
> At that point, we can look at improving tree conflict handling to
> handle a lot more cases automatically. We could use trumerge's algorithms
> (http://trumerge.open.collab.net/) and the use case definitions developed
> for trumerge as a model for desired behaviour.
We don't need a new editor for improving automatic tree conflict handling.
Tree conflicts and editor limitations are different problems which can be
solved independently as well.
The project of adding editorv2 is large enough by itself without tying all
other issues to it.
Bert
> It should be possible to implement some of the above steps in parallel.
> E.g. converting commit to editorv2 does not need to wait until local
> move support is complete. Likewise, storing copy-to information in FSFS
> can be developed in parallel -- a design for BDB already exists which
> can be built upon. I don't know much we can achieve for 1.8 but getting
> those three off the table would be a huge jump and allow for the
> remaining items to be addressed for 1.9.
Received on 2011-07-20 12:40:49 CEST