[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Medium-term roadmap: 1.3, 1.4, 1.5.

From: <kfogel_at_collab.net>
Date: 2005-04-22 22:46:58 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.