Svn as a changeset engine.

First of all, I'm writing this mail mostly to clarify to myself the concepts
of a true changeset engine. I'm attempting to do this in terms subversion.

1) User scenario.
This provides the basis for how I think a changeset engine would work for the
user.

I'm imagining a GUI client, which when instructed to perform an update would
show a dialog listing all of the revisions between CURRENT and HEAD, along
with their log messages.

All independent changes are enabled, those dependent on other changes are not
selectable. (Where independent is an arbitrary definition, either semantic,
or syntactic depending on how fancy the cset engine wants to be). As the user
selects some changes, the ones dependent on them become enabled.

The user selects all changes they are interested in the clicks OK. Those
changes, and ONLY them are applied to their working copy (but not as local
mods). At some point later, they would have to be able to go back and pick up
other changes.

2) How this fits with subversion.
a) First of all, notice that the term revision is not used in the above
scenario. That is because the fundamental working unit becomes not a
revision (which is part of an ordered set), but a change (which is part of an
un-ordered set albeit perhaps with dependencies).

b) Note that I think all of this is possible in subversion although not
necessarily at the highest level of performance. See below.

3) How would this be implemented in terms of subversion.
a) It might be advantageous for performance reason, although not strictly
necessary to change the revision field of an entry to a list of revisions
applied. The same thing could be accomplished with a property I think.

b) When performing the transformations to the working copy, we would need to
retrieve the text base immediately before a change, and the change itself, so
that we could perform patching in a more flexible manner, since the user need
not ever have a working copy that looks identical to any given revision.

c) We would need some kind of variance adjusted patching, to allow for a
blanket "svn update" which would grab all changes not currently included in
the users working copy.

The end.

Does this jive with what other people think of as a changeset engine? Would
implementing some of these ideas post-1.0? Does this enable a lot that is not
supported by private developer branches (assuming variance-adjusted-patching),
where the user can selectively merge changes into their branch?

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~