On Tue, Jul 19, 2011 at 11:43:06PM -0400, Greg Stein wrote: > On Tue, Jul 19, 2011 at 21:27, Hyrum K Wright <hy...@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.
