Looking over the responses to the roadmap proposal, I think they can
mostly be summarized as: "Do atomic renames sooner!" :-)
I feel strongly that trying to put "atomic renames" all in one
milestone would be a mistake. As even the preliminary discussions
have shown, it is not a trivial problem.
The key (ironically enough, I guess) is to break atomic renames up
into discrete subtasks as much as we can. Fortunately, there's an
obvious place to start: implement atomic renames in the repository.
We wouldn't worry about the working copy at first. It would still
receive renames as it currently does, and the only gateway to the new
functionality would be 'svn mv URL1 URL2'. But it would be an
important first step and -- obviously, IMHO -- a prerequisite for
further atomic rename functionality.
(This is essentially what issue #898 is now, I think, although #898
did not start out that way.)
So below is a new proposal, similar to the previous one, but starting
the renames work much sooner -- the first piece would happen in 1.3.
1.3: Server->client configuration transmission.
Just repository side of atomic renames.
ETA for 1.3: Sep. 1 (assumes first soak starts June 15th or so)
User-visible features resulting from config transmission:
* Log message templates (note: this is a CVS parity issue!)
* Improved (server-driven) mime-type assignments.
* Various other settings TBD.
User-visible features resulting from repos-side atomic renames:
TBD. This may turn out be mainly infrastructure work,
though possibly the output of 'svn log -v' (for example)
could show renames more definitively, if the rename was done
with 'svn mv URL1 URL2'.
1.4: Operation logging.
ETA for 1.4: Jan. 1 (assumes first soak starts Nov 15th or so)
"What's operation logging?" I hear you ask.
This is also a CVS parity issue. There is currently not even
any configuration option to get Subversion to consistently
record read-only operations, similar to the CVSROOT/history
file used by the 'cvs history' command. Even Apache w/
mod_dav_svn, the httpd logs do not enable us to distinguish
between checkout/update/switch/blame/log/diff/merge. You can
never be sure what you're looking at. And that's the RA layer
with the most thorough recording! :-)
We need a consistent logging system that all RA layers can
use, that will collect information from a Subversion point of
view, not an "HTTP GET" point of view. This also requires a
design discussion, but probably not a huge one. We just need
to decide what we want to record, and the format in which we
want to record it. No rocket science here. (Correction: Ben
just informed me that it *is* rocket science, because there's
a debate about whether or not to involve the native OS logging
system. Fine. We'll cross that bridge when we come to it.)
Part of the goal of this milestone is to be Not Too Hard.
Operation logging is not a new feature on the scale of
server->client configurations, or even repos-side atomic
renames. But that's okay! In fact, it might be nice to do
some bugfix-only releases from time to time. We don't have to
add a new feature with every release. Operation logging is
sort of a halfway step between those two strategies.
1.5: TBD, see below
ETA for 1.5: TBD (depends on what's in it)
1.5 open for discussion, but I imagine that we'd want to
continue with renames, including the working copy side.
Thoughts on this new proposal?
I'm trying to not get into design details in this thread. It should
be about high-level overview.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 30 20:34:55 2005