I wrote a long reply. It contains some relevant information
about what DeltaStreams currently has to offer for your
proposal, and what I'm working on.

On Sat, Feb 16, 2008 at 02:49:57PM +0100, Jason Johnson wrote:
> The features of the system I'm planning will be:
> 
> *) Based on change sets (well, actually the more robust Delta stream
> implementation) instead of snapshotting.  A consequence of this is
> that one is no longer required to use *categories to associate your
> changes into a package, but rather something a bit more sophisticated
> then the current change sorter can be used to manage them.

I have a pretty sophisticated UI for DeltaStreams, but it is
missing a lot of commands. You can read about it and see an old
screenshot at http://wiki.squeak.org/squeak/6014

> *) "Cherry picking" of changes.  Smalltalk, with its simple syntax and
> keyword arguments, is the best language I know of for writing self
> documenting code.  But what is still missing is the *why* and *how did
> we get here*.  Intelligent use of change sets can go further to answer
> those questions.  When one makes a series of changes to fix multiple
> bugs, they can after-the-fact move the changes into a separate set for
> each bug so that later maintainers of the software have more
> information to determine if the existing code is still relevant, etc.

DeltaStreams can do this, but I haven't made the UI yet to be
able to copy changes between deltas.

> *) Labeling.  In big companies using sophisticated revisions systems
> (i.e. not obsolete stuff like SVN), people are branching, merging and
> conflicting all the time.  Then when it comes time to release their
> software they apply a "label".  This tags the latest version of all
> data managed by the system so that in an audit, they can conclusively
> prove what the state of the software was for any version.  This also
> gives benefits to the system by allowing it to ignore everything
> previous to the latest label (since the current state of the system is
> simply: the latest label and all changes after that).

DeltaStreams does not do this.

> *) Fully distributed.  Anyone can make a copy of a given repository at
> any time.  They can make changes that stay only in their own copy, or
> push them up if they wish.  To make a branch, just make another copy
> of the repository.  The repositories are updated strictly through the
> mechanism of applying patches so your totally free to "cherry pick"
> changes out of someone else's repository (and the patches don't have
> to be applied in order) or sync up if you wish.

DeltaStreams as yet currently has no concept of remote streams
or repositories. Since DeltaStreams is alpha software, it has
known missing features. This is one of them. 

Currently, I'm bootstrapping this by hooking onto the existing
update stream supported by Squeak (See class Utilities, category
updates, for how it works). The file format I'm currently
writing interleaves a binary tree serializer with a normal
change set. http://www.squeaksource.com/InterleavedChangeSet .
In this way, you could build a delta with all the metadata
available and file it out. The receiver would make use of all
that metadata if DeltaStreams is loaded; otherwise it sees a
regular change set.

It is still alpha stage; the writer is about 70% complete, and
the reader hasn't been started yet. DeltaStreams doesn't yet
know how to use it either.

> *) Multiple ways of managing changes.  Since the system will live in
> the normal Squeak system, it has access to all the subsystems in the
> image and can leverage them to apply or forward patches.  One example
> of this is darcs cool feature of letting a remote user make a change
> and use one command to have darcs package up the change in the correct
> diff format and forward it to the package maintainer for peer review.

No idea what you're talking about here

> *) Compatible with other systems.  Of course no new revision system is
> going to have a chance if it can't deal with packages from all the
> other existing systems.  It may even be interesting to generate
> packages from these other systems.

This is the feature I'm working on next in DeltaStreams.
Specifically, I want to be able to convert Installer scripts
into deltas. Installer is a great way to specify what goes into
a certain release and what does not. I think so, at least. Maybe
you have a better idea with your darcs knowledge.

> Well, that's the list off the top of my head.  I know MC2, and even
> MC1 can do much of this (or probably all in the case of MC2), but MC1
> is based on snapshotting which I disagree with and I think MC2 tries
> to do too much.  

I don't see how "doing too much" can be a very serious problem.
Colin has great ideas about MC2, and I'm curious to see if MC2
and DeltaStreams will work together independently, if one will
kill the other, or if there will be a need to merge them.
Impossible to say right now.

> I believe the "theory of patches" underlying darcs
> that any system is simply the sum of applying all it's patches, and
> therefor I don't think anything more then this is needed.

Goran wanted deltas to work just like darcs patches when he came
up with the idea. However, I don't know anything about darcs,
and I've written most of the DeltaStreams code so far, so I have
no idea if what I am building lines up with that original goal
or not.

Also, Goran has since discovered Bazaar revision control, and (I
believe) found it superior to darcs. I know nothing about
either; just mentioning it for completeness.

My current goal is to get delta streams working well enough to
be of assistance while I try to merge the separate versions of
Morphic in the various forks, and assist Edgar with Ladrillos:
http://www.squeaksource.com/Ladrillos

How I plan to use it is as a shared log that could reliably
replay a set of changes made to a between a set of packages.
Monticello has issues when moving classes between packages,
which I envision needing to do a lot in dividing up Morphic. So,
I want to use deltas to keep track of what I do while moving
things around, since that is the most reliable order of making
the changes. Eventually, Morphic should be divided sanely enough
to use plain Monticello.

The features I will need for this to work are:
- a reliable file-out format, in progress
- Integration with Monticello, so that package saves and loads
  are correctly stored in the log

So, this is all I'll be working on before I stop work for a
while and concentrate on the release process.

I haven't made a script that will install the latest version of
DeltaStreams, so it requires a bit of work to install. If you
want to discuss revision control systems, install DeltaStreams,
or get help understanding the code, sign on to #squeak and we
can discuss it. If you have an idea of which parts should be
written first.

If there is any interest in seeing DeltaStreams in the basic,
not-really-usable state that it is in, I can make an Installer
script for your squeak version. Also, I would definitely
appreciate any help coding this thing, or understanding what
DeltaStreams should be. I'll be happy to help you with it.

-- 
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808