I'd like to start mapping out the next few releases.
1.2 has been a big release. Locking was complex, and we also fixed a
ton of bugs -- some of which were scheduled for 1.2, others of which
were done on the fly. While everything worked out eventually (fingers
still crossed), 1.2 took a long time.
The proposal below continues the "one major new feature per release"
concept, but with features less disruptive than locking. Here I'll
talk mainly about new features; obviously each release will contain
bugfixes as well, but probably fewer than 1.2 contained, because these
new features should not take as long as locking took. The idea is to
get the minor releases out more quickly, roughly at 3 month instead of
6 month intervals.
The purpose of this post is to get a rough consensus that this is the
direction we want to go. Once the dust has settled, whatever our
conclusions are, I'll massage roadmap.html and the issue tracker in
the appropriate ways. Here we go:
1.3: Server->client configuration transmission.
User-visible features resulting therefrom:
* Log message templates (note: this is a CVS parity issue!)
* Improved (server-driven) mime-type assignments.
* Various other settings TBD.
This mechanism requires a design discussion, clearly, which
I'll start in a separate thread, assuming we do this.
I'm not listing 1.3 bugfixes here, because the current 1.3 and
unmilestoned issues need to be gone through, to avoid making
the release too big. There are already a lot of bugs assigned
to 1.3, and I think some of them will probably need to move
out to further releases. However, one that *won't* move out
is 2138 ("finish the new blame algorithm"), which almost made
it into 1.2, and which a lot of people are waiting for :-).
ETA for 1.3: Sep. 1 (assumes first soak starts June 15th or so)
1.4: Operation logging.
"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.)
ETA for 1.4: Jan. 1 (assumes first soak starts Nov 15th or so)
1.5: TBD, see below
I'm leaving 1.5 open for discussion -- well, 1.3 and 1.4 are
open for discussion too, of course! -- because there are
several plausible choices. I'd really like to see atomic
renames (issue #898 and possibly #895) tackled here, partly
because that seems a prerequisite for any merge-tracking
features (which is a whole other topic), and partly because
atomic renames are desirable in their own right.
Atomic renames will require some discussions, see issue #898
for the gory details. My guess is that it wouldn't force a
schema change, though, and therefore could be done before 2.0.
But maybe there are more important things our users are
clamoring for? Any thoughts?
ETA for 1.5: TBD (depends on what's in it)
Comments, suggestions, flames?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 22 23:17:09 2005