[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

track editor

From: Ben Collins-Sussman <sussman_at_newton.ch.collab.net>
Date: 2001-03-11 16:59:12 CET

(Note: this is a message meant for kfogel and cmpilato, but I'm
sending it to the dev list anyway, because it's good to have an
archived record that explains the rationale behind an upcoming

OK, guys, I *know* you're sick of talking about the tracking editor.
But I've now spent 24 restless hours subconsciously trying to figure
out why my spidey sense has been tingling ever since our 6pm phone
call on Friday. But now I think I have a handle on the problem!

Please read this carefully.

Let me recap for you ("I was born in 1973...")

Mike and I were originally trying to define 3 distinct code paths
within svn_client_commit():

  A. Commit to XML, no revision given.

      This has no effect on wc revision numbers at all; it just
      generates a patch file of your local mods.

  B. Commit to XML, revision given.

      Bump revision numbers when done. (This is our existing code

  C. Commit to some RA commit-editor.

      We don't know which RA vtable we'll get, but that's fine. All
      that matters is that every RA module inherently knows how to
      call svn_wc_set_target_revision on each committed target.

In case (C), ra_dav already knows how to track targets for bumping (I
think the DAV server is tracking targets autmatically or something.)
But ra_local needs to track targets somehow: thus we wrote the
tracking editor.

Then, we agreed on a reasonable axiom from Karl: since ra_local needs
to track targets to bump, and since case (B) requires that targets be
tracked too -- svn_client_commit and ra_local should therefore share
the track editor!

When we last left off, we said "great, so then let's move the track
editor into libsvn_ra as a general purpose thing."

NOW, *here* are the problems I discovered when trying to *do* this.

  1. The track editor is currently designed to store targets within a
      baton that is specific to ra_local. In the process of trying to
      generalize the baton, it got *very* messy, what with batons
      being generated to pass to svn_fs_get_commit_editor and ones
      being generated to pass to ra->get_commit_editor. It became a
      spaghetti mess of batons. Ick.

  2. More importantly: we forgot a very fundamental difference
      between cases (B) and (C) above. In case (B), we have the
      new_rev *before* the commit begins, and in case (C) we don't
      have the new_rev until *after* the commit is over, after all the
      editors have been built and used. So there's no easy
      combination of input params to get_track_editor() that can deal
      with this -- I tried, and it turned into an intractable design
      problem. It just doesn't work.

But fear not. I think I've finally found a *simple* path through the
  * svn_client_commit, in case (B) _doesn't need_ to use a tracking
    editor at all! No, it doesn't! It already gets all the commited
    targets back from crawl_local_mods, and it has the new_rev from
    the get-go. It can simply loop over the targets itself and call
    svn_wc_set_revision. It's a tiny bit of code, a real no-brainer.

  * This means that the tracking editor remains a special helper to
    ra_local. Nobody need know it exist; it's just an implementation
    detail that brings ra_local up to spec with svn_ra.h. Leave the
    tracking editor untouched, just where it is.

This should explain my forthcoming commit. :)
Received on Sat Oct 21 14:36:25 2006

This is an archived mail posted to the Subversion Dev mailing list.