As part of the work on atomic renames, I'm looking at reving the
editor interface. We need the ability to express move operations, and
due to our backwards compatibility constraints it appears we can't do
that without reving the whole interface.
I'm thinking we might also want to consider making the structure
opaque, similar to what was done with the RA layer API, with the
addition of some accessor functions for manipulating the underlying
callbacks.
I've got a few questions though, before I go in and start messing
around with this...
First, does anyone object to making the new editor object opaque?
It'll make code that creates editors a bit more verbose, but I don't
personally think that's a huge problem...
Perhaps more important, how should move operations actually be
expressed? Basically, it appears that we're going to need both FROM
and TO callbacks (due to the fact that we might only see part of the
operation in any given editor drive), so a move will actually involve
a call for the source (I'm moving from HERE to THERE), and the
destination (I'm showing up HERE and I was renamed from THERE). The
destination part is similar to what we already do with adds + history,
but there needs to be some way to indicate that this was a rename, so
either the add callbacks need to grow "is a rename" parameters, or new
callbacks are needed. On the other end it's very similar to what we
currently have for delete entry, but with the addition of the
destination info. That could be implemented by reving the
delete_entry function, adding some parameters, or via a separate
callback that is only used for renames.
The current half-done impl I've got on the fs-atomic-renames branch
uses new callbacks for the move stuff, but I'm personally leaning
towards at least reving delete, and potentially doing the same for
add, since it won't even result in ugly svn_foo_bar2 type function
names since if we go with an opaque editor we'll need new helper
functions to do the actual calling, which can have new names
obviously, and keeping the total number of functions down seems
useful, since we have so damn many of them now...
Any thoughts?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 4 00:07:40 2006