The perfect revision control system

goran at krampe.se goran at krampe.se
Mon Feb 18 09:07:30 UTC 2008


Hi Colin and all!

Colin Putney <cputney at wiresong.ca> wrote:
> On 16-Feb-08, at 6:46 PM, Igor Stasenko wrote:
> > Guys, wouldn't it better for you and rest of us all to join efforts,  
> > and make
> > DS + MC2 ?
> > It's really pain to see, that you both duplicating work in multiple  
> > areas.
> 
> I don't really think that would be possible. The two systems are two  
> different to be combined into a single system. They might be  
> complimentary, though we won't know how that works out in practice for  
> a while.

That would also be my guess.

> > Hoping you will not consider my 2 cents as offensive act :)
> 
> Not at all.

No, we take no offense!

> I can understand the community being frustrated with me. I  

Nah, there is no such frustration - at least not from me. :) Sometimes
we have time, and at other times we do not - it is the way of life.

> got MC2 to alpha-quality, made all sort of promises, then let it stall  
> for 2 years, while I put my effort into my day job. Göran and Matthew  
> got tired of waiting for something better than MC1 and set out to do  
> it themselves.

Mmmm, that was actually not how it went - the reason I started DS was
not because I wanted something "better" than MC1 - in my mind DS is a
different beast for altogether different use cases and the word "better"
doesn't cut it.

> I've also resumed work on MC2 and now we've got two, apparently competing projects.

Personally I don't think they compete. :)

> But actually, I think this is a good thing. MC2 is much better than  
> MC1, but it won't be the last word in versioning systems. DeltaStreams  
> and Jason's new project pursue a completely different philosophy on  
> versioning, and I'll be interested to see what they come up with.
> 
> In the meantime, I'll keep doing what I'm doing.

I sure hope so! I want BOTH MC2 and DS in the end - and using lots of
common code like for example the brilliant SE base (SystemEditor) which
we hopefully have fixed quite a few things in while working on DS.

As a final word, this is how I see it:

- MC1 is great for team work and for maintaining packages over time even
if you are a single dev.

- MC2 will presumably be MC1 ++, I mean, that is what I expect. Smarter
and better in most respects.

DS is mainly aimed at being flexible tool for moving changes between
*radically different* branches with no common history - or in other
words - between different Squeak "distros" like say Croquet, Sophie,
Squeak vanilla, Squeakland etc.

It tries to enable this by recording MORE state about the actual changes
instead of relying on advanced history analysis (like the MC-family
does).

So a Delta is a ChangeSet on steroids or a patch or whatever you like to
call it. While both fixing lots of deficiencies with the original
ChangeSet implementation - it also is much more "detailed" in its
recordings.

So a few use cases DS tries to address:

- Bug fixes. Instead of ChangeSets we want to use Deltas. They should be
just as simple to use - but much more reliable and useful.

- Update streams. Like the original stream that feeds an image, but with
the ability to have multiple streams.

- The changelog. Eventually we should be able to use Deltas as a base
for a new .changes system.

A few use cases DS does not try to address *primarily*:

- Team development. We expect Deltas to be able to form a nice *base*
for this, but it is likely MC will be able to make much more educated
merges than Deltas will be able to do, well, it depends on how much
history analysis you put on top of it.

- Package maintainance. Similar argument.


Three really important features with Deltas are:

- The ability to apply/unapply! Excellent undo which enables stuff like
patch queues etc.

- Fully reified. This means a Delta is a self contained object when
loaded into the image. Then you *apply* it or *unapply* it. A changeset
in comparison is NOT self contained, it only refers to the methods it
changes without containing the actual code itself (highly confusing).

- More info! A modified method does not only contain the NEW source but
also the OLD source it replaces. This simple scheme with keeping "before
state" makes applying them in "forreign images" very easy to do - and
still be able to warn the user about possible conflicts.


And above all - they are still very easy to reason about and manipulate.
The model is trivial - just an ordered sequence of low level change
objects. If something goes wrong you will always be able to figure it
out.

Darcs was mentioned in another post as a "source of inspiration" and
yes, that is true. Darcs is remarkable in its "smartness", BUT... lots
of people feel the downside is that when stuff goes wrong you are more
or less toast in trying to understand why.

So DS tries to give us some of these features WITHOUT going overboard on
the complexity side. Without actually knowing what I am talking about
this MAY be a plus for DS compared to MC2. :)

regards, Göran



More information about the Squeak-dev mailing list