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.
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.
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 11:56:25 CEST