The perfect revision control system

goran at krampe.se goran at krampe.se
Mon Feb 18 09:28:31 UTC 2008


Hi all!

Matthew Fulmer <tapplek at gmail.com> wrote:
> > *) "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.

Yes, the model with Deltas is very similar to ChangeSets in this respect
and the only thing missing is good UIs on top.

> > *) 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.

Right, the concept of tags is... hard to see how it would work in DS
given its model.
I haven't thought much about honestly.

> > *) 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. 

Given the approach I would say DS is distributed. But it is hard to
compare - the "commands" you mention that are "standard" in tools like
Darcs/BazaarNG/Mercurial etc don't really have a counterpart in DS yet
since we haven't attacked the S-part (streams of Deltas) yet.

We have been developing bottom-up and thus we will first have a full
ChangeSet replacement before attacking the concept of streams of Deltas.
So the field is open but again, DS does not really *aim* to give the
same work model as Darcs/BazaarNG/Mercurial etc. That doesn't mean it is
not possibly though, we just haven't been thinking about it like that.

> 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.

Which is bloody genius. :) Sorry, I haven't been able to code on DS for
a long while, but it is great to see Matthew pushing it forward!

> 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

I understand it I think. The "mail bomb" thingy that Darcs had early on
and that the oher tools have added. I would say this particular feature
is *inherent* in DS - since a Delta is a self contained thingy and yes,
feel free to send it through different means of communication.

Other areas of integration can be discussed - for example, if Deltas can
replace ChangeSet fully - should MC1/2 use Deltas (when doing the final
apply-operation) instead of ChangeSets in the future? And so on.

> > *) 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.

I am unsure what Matthew means when he says "convert" - would it be
simply "recording" all changes being done into a single Delta or?

Otherwise I would say that DS is the "tool" in this area that has most
chances of co-existance given its very trivial model and design. It is
something we really aim for.

> > 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.

Right. My bet is that MC2 will (if it gets to that state) eventually
replace MC1. If we bring DS to its full potential I hope it will replace
ChangeSets with all that comes with that - and also work as "glue" in
the world of Squeak code sharing.

I want people to feel that, "ok, hmmm, let me just file this out as a
Delta and ftp it up there/email it to you/drag and drop it to that other
image" or whatever. I want them to feel that when all else fails Deltas
are there to work as a very nice fallback mechanism.

And I also hope the apply/unapply feature will open up new ways of
working.
 
> > 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.

Let me just note that while being *impressed* with Darcs I feel that
route is simply too complicated. I am inspired by Darcs, but I don't
want to copy it. I want to enable some similar feel of cherry picking -
but the idea was to make DS handle say 80% of the cases but using a MUCH
simpler trick (recording more state) than using highly advanced
algorithms that only 2-3 people even understand.
 
> 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.

"Superior" only in the sense that it seems to do much the same but using
simpler means. And having tons of other features and a lot of developer
momentum.

Darcs still probably has the most advanced cherry picking out there -
but since the others are very good too - it doesn't outweigh the other
stuff.

> 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

Good, real usage is a great way to see if it holds.

> 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.

Very interesting use case.

> 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.

Sounds great.

Hopefully I will be able to at least catch up a bit. :)

regards, Göran



More information about the Squeak-dev mailing list