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

[PROPOSAL 2]: Medium-term roadmap: 1.3, 1.4, 1.5.

From: <kfogel_at_collab.net>
Date: 2005-04-30 20:02:52 CEST

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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.