I would like to see the "obliterate" feature that is currently marked as
issue #516 put on the schedule.
1.3 would be great for me :)
kfogel@collab.net wrote:
>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
>
>
>
>
>
--
Stephen P Rufle
srufle@salmonllc.com
H:480-802-7173
Yahoo IM: stephen_rufle
AOL IM: stephen0rufle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 30 01:25:05 2005