subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "MoveDev/MoveDev" by JulianFoad
Date Thu, 20 Jun 2013 21:14:27 GMT
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.

Mime
View raw message