subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <>
Subject [Subversion Wiki] Update of "MoveDev/MoveDev" by GregStein
Date Thu, 13 Jun 2013 23:43:58 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 GregStein:

talk about Ev2, particularly in response to the ill-fated "extend delta_editor" concept

  === Client ↔ RA ↔ Repos ===
  The only Client → Repos op affected is Commit.  (There are also simple commit actions,
of which 'move URL URL' is probably the only relevant one.)  Commit will use a move-aware
delta-editor.  We already have local moves in the WC, so we just need to describe those to
the editor as moves.
+ '''gstein sez''': RA_local's Ev2 interface (see `svn_ra__get_commit_ev2`) will transfer
a move from the RA editor all the way to the FS API. See `libsvn_fs/editor.c:move_cb()`. When
the FS grows an API, then RA_local will drive it.
  The Repos → Client ops affected are Diff, Update, Switch, Status.  These all work in a
very similar way.  Each one sends a Report and receives a delta-edit.  They will use a move-aware
  ==== Commit ====
  WC descibes each move from the WC DB to the move-aware editor.
  When not using a move-aware editor, WC describes each move from the WC DB as copy &
delete in the old way.
+ '''gstein sez''': why would you ever have a non-move-aware editor? See the `ev2-export`
branch for a commit process that drives an Ev2 editor (meaning: a move-aware editor)
  ==== Update/Switch/Status/Diff ====
  WC receives each move from the move-aware editor.
@@ -50, +54 @@

  === Repos ↔ FS ↔ FSFS ===
+ '''gstein sez''': Repos has an Ev2 commit editor, which `ra_local` can use. This drives
the FS Ev2 commit editor. Currently, the moves are transformed into copy/delete, but that
can be fixed "trivially" by adding an FS API (which does copy/delete under the covers) and
converting `fs/editor.c:move_cb()` over to using it. Then the move issue is completely within
  === Within FSFS ===
  Introduce 'move' as a new, distinct operation.  Add move-tracking APIs.
@@ -83, +89 @@

  Moves will be transmitted 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
   * What about Ev2?  Supposed to have support for        moves.  Untested and unknown.  Seems
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).
+ '''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.
  ==== Adding a 'move' operation (and negotiate the use of it) ====
  Introduce a 'move' method in the vtable.

View raw message