Milestone 1 user-interface

Here are some thoughts on the client user-interface for Milestone 1.

to resemble cvs as much as possible; it should be obvious to any cvs
user how to use the `svn' binary.

However, for Milestone 1, the client and server will be communicating
through XML files rather than through a network. This means we have
to add some new switches to the command-line relating to reading and
writing XML files.

There are two independent questions to consider here:

      1. Are we sending or receiving changes?

          Specifically, the client can either "commit" a tree-delta
          and create an XML file, or it can "update" (or "checkout") a
          tree-delta from an existing XML file.

      2. Are the changes "official", or are they "under the table"?

          Let's define these terms: By "official", we mean that the
          commit or update is documented in the working copy
          administrative files. "Under the table" means that the
          commit or update took place, but nothing was recorded about
          it.

These questions can give us a cute little chi-square of permutations,
describing all the possible behaviors of the client:

* Sending "officially"

  The client commits a tree-delta into an XML file. The relevant
  entries in admin files are updated to a single version number.

      --> Note that in normal circumstances, the repository would
          return the new version number to the client. In the case of
          XML files, it will be necessary for the user to manually
          specify a new version number on the command line.

* Sending "under the table"

  The client commits a tree-delta into an XML file. No admin files
  change at all. As far as the working copy is concerned, nothing
  ever happened.

      --> This is a method for generating an XML "patch" that you
          might want to give to someone else. Actually, it's an
          extension of the whole patch concept: it not only contains
          file diffs, but tree changes as well.

* Receiving "officially"

  The client updates (or checks-out) a working copy from an XML file.
  All administrative files record this event.

      --> Nothing special about this, just an ordinary update.

* Receiving "under the table"

  The client updates a working copy from an XML file, but no
  administrative records are made.

      --> Again, this is the other side of our "extended patch" idea.
          Just as people apply patches to CVS working copies to test
          somebody's contribution (before committing it), Subversion
          users can patch *whole trees* in an SVN working copy and
          test behaviors as well.

We need a good name for an "extended patch" object, and right now
we're thinking about calling it a "delta". Instead of posting patches
to mailing lists, developers can trade "deltas" informally in the same
way. (Is this a good name?)

Ideas for command line switches that deal with XML files:

* Sending "officially"

    svn commit -o file.xml -v 38

    (The -v flag defines an imaginary version number that would
    normally returned by the repository upon a successful commit.
    This new version number is recorded in administrative files.)

* Sending "under the table"

    svn commit -o file.xml

    (Without a -v flag, the admin files aren't changed at all; this
    command does nothing but generate a delta.)

* Receiving "officially"

    svn update -o file.xml
    svn checkout -o file.xml

    (A normal working copy update or checkout.)

* Receiving "under the table"

    svn update -o file.xml -p

    (? Perhaps the -p means "patch only, don't actually record an update.")

So there's a first draft, a blueprint for the bike-shed.

Thoughts? :)
Received on Sat Oct 21 14:36:10 2006