Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "MoveDev/MoveDev" page has been changed by JulianFoad: https://wiki.apache.org/subversion/MoveDev/MoveDev?action=diff&rev1=6&rev2=7 === Reporter === Needs no changes. (The reporter does not report changes, it just reports a base state.) + === H3 { margin-bottom: 0.21cm; }H3.western { font-family: "Nimbus Sans L",sans-serif; }H3.cjk { font-family: "DejaVu Sans"; }H3.ctl { font-family: "FreeSans"; }H4 { margin-bottom: 0.21cm; }H4.western { }H4.ctl { font-family: "FreeSans"; }P { margin-bottom: 0.21cm; }P.western { }A:link { } === - === Delta-Editor === + === Tree Editor === - Options: + For a move-aware editor, svn_editor_t (“Ev2”) is the goal. It was designed to support moves, and to have several other advantages over the old editor. - * Transmit moves transparently over the old svn_delta_editor_t. A move-aware producer will drive the existing editor interface in a way that is (more or less) backward compatible with existing consumers. + I have some difficulties with the description of move support in it, which we need to resolve. - * Use Ev2. Supposed to have support for moves. Untested and unknown. + There is also a possibility of transparently sending move information over the old svn_delta_editor_t. This can be a useful short-term tool for getting some client and server components upgraded before tackling the protocols and intermediate APIs. - It may be better to start by adding support to a well known editor first, if that is possible (which it seems to be). Then see if there are any functionality or efficiency issues that could be improved by use of Ev2 (or something like it). + ==== Moves in svn_editor_t ==== + ... - '''gstein sez''': It '''does''' have support for moves. Not "supposed to". It is better tested/known then any hack you may want to add into {{{svn_delta_editor_t}}}. Note that the delta editor structure is bare to the world. You cannot really extend that vtable. The Ev2 editor solves that problem. To put it blunkly/frankly, you're talking about reinventing the wheel that has already been done in Ev2. It is nothing short of ridiculous to start over again. Not to mention a ton of completed work on converting pieces of the codebase over to Ev2. I would turn it around: show why Ev2 isn't sufficient, rather than starting over again from the delta editor. We also have working shims for converting between delta_editor and Ev2, to help with the transition. This pseudo-move-delta has zero support, zero testing, zero review. The Ev2 design was crafted with the understanding of problems with the delta_editor interface. It solves them, and moves the codebase away from that crap. Piling more onto delta_editor makes it worse. + === Ways to Transmit Moves over Ev1 and similar === + Here are some notes on ways to transparently send move information over the old svn_delta_editor_t, or into a similar API such as the FS vtable. - '''brane notes''': We're kind of aware of all that. The problem right now is that the only two people who actually know anything about EV2 aren't very active on the project. I'm hoping this will change (hint hint!), in which case I don't think we'd be considering hacking the delta editor at all. + Using these methods, a move-aware producer will drive the existing editor interface in a way that is (more or less) backward compatible with existing consumers. ==== Add a 'move' operation and negotiate the use of it ==== Introduce a 'move' method in the vtable.
