(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
commit.)
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
path.)
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
woods.
* 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