Ralph, thanks for the response.

Let me start by defining just what I mean by "Change Sets", to be as clear 
as I can.

I am talking from the point of view of how I use the darcs system, which is 
by far the best general revision system I have ever used.

In darcs, when you make changes to your repository (files, directories, what 
ever) and then try to commit you have the option at that point to specify 
what literal changes (in darcs terminology: "chunks") are part of this 
commit (what I'm calling a "change set").  After a "darcs change set" is 
made, those "chunks" are now effectively bound to that "change set" and are 
treated as one unit.  If you wish to break a "chunk" out you would have to 
undo the creation of the "change set" and redo it.

The rest of the system does things based on this "change set" unit.  When I 
commit to another repository (e.g. the main repo), I can specify which of 
the new "change sets" I wish to commit (this makes it easy when you have a 
batch of "change sets" where some are emergency fixes that must go to prod, 
but need to be in dev as well, and you also have dev-only patches) to bring 
the repo in sync.

Please see below for individual responses:

>From: "Ralph Johnson" <johnson at cs.uiuc.edu>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: "The general-purpose Squeak developers 
>list"<squeak-dev at lists.squeakfoundation.org>
>Subject: Re: Monticello 2 - request for information
>Date: Fri, 18 May 2007 09:06:45 -0500
>
>The problem is not that there are bugs with change sets.  Change sets
>are mature, well tested technology.  I have been using them for 20
>years and understand them very well.  The problem with change sets is
>that they are fundamentally a bad idea.  Change sets are programs
>which, when run, modify objects.  The objects that they modify are
>classes, i.e. programs.

At the end of the day, that's what MC does as well, no? :)

>  The purpose of MC is to provide a package
>system and to make program definition more declarative, to make it
>safer to merge versions, to see the difference between versions, and
>so on.  MC is relatively immature and is full of bugs, but it is the
>right way to go in the long run.

The darcs model I mention above is, afaik, the best system around for safe 
merges.  The whole system is based on a thesis of a "theory of patches". :)

>This was a mistake.  You are supposed to complain loudly on the 3.10
>mailing list.  This is probably a bug, and the whole purpose of
>releasing early and often is to find bugs.  But if people don't
>complain about them, the process doesn't work.  We shouldn't provide
>workarounds for bugs, we should fix them!

Yea, ok, but the way my time is divided at the moment, I can 
send/read/manage email or I can write code.  That day I chose to patch and 
move on. :)

But anyway, that was just an illustration of the fact that sometimes we will 
need local patches (at least temporarily) that have to have some way of not 
being considered part of the changes that are to be published.

>One of the problems with MC is that it doesn't have an explicit
>representation of what goes in to a package, but instead relies on
>names.  The name of a class's cateogry determins which package the
>class it is in, and if a method is going to belong to a package other
>than the package of its class, it must be in a protocol whose name is
>'*' followed by the name of the package.  This was an expedient hack,
>but it causes lots of trouble in the long run.  A package should just
>be a list of classes and methods.  Perhaps the default is for all the
>classes in one particular cateogry to be in the same package, but that
>shouldn't be the rule.

That is one way to look at it, and indeed workable, if the system could just 
make it's choices and then give us a way to go back and make authoritative 
manual corrections later.

But another way to look at it is: a module is the sum of the changes it 
makes to the system.  If the working unit is (at least what I am calling) a 
change set, then when you created a new "project" you could specify what 
change sets apply to this package (and the system could take a cut 
automatically using rules much like MC's to build a best guess).

I feel this would aid in documentation, as "when and why was this changed?" 
is easier to answer when we have the full history of methods.  One problem I 
see in MC is the disconnect to my method history and MC's.

If a method gets changed 20 times in my image and then published, when I 
download it in a new image I only get the diff in MC, not those 20 
iterations right?  It may be that you want this behavior sometimes but in MC 
it is the only option, no?

>Perhaps this is what you are calling a change set, but to me, a change
>set is a file format that is a program that modifies classes.  MC
>reprensents a package with a data structure that it can manipulate
>safely.

Well, I am not thinking about a file format, but any change system is, at 
the end of the day, going to modify the system.  The difference in the 
Smalltalk system and what general change management systems have to deal 
with is:  in general systems (e.g. darcs) the smallest unit of change can be 
as little as a byte (maybe even a bit), while in Smalltalk it is a method.  
There isn't much point in recording that one letter changed in some string 
since the whole method has to be recompiled anyway.

But as I understand it from what I have looked at in the classes and read on 
the wiki, Squeak change sets *do* keep data about what was changed, etc.  I 
think you can apply this as safely as anything else.

For example, a revision system that used change sets as a base unit would be 
responsible for tracking dependencies, since the change sets themselves 
wouldn't know what other change sets they depend on.  An individual change 
set could also be though of as a transaction.  If any part of it would fail 
application, none of the change set is applied.

I fail to see how this is more or less dangerous then what MC is doing, 
though it could be that we just have a terminology mismatch.  I am talking 
about objects in the Squeak image that represent changes, not some file 
format.

>We need to fix MC to do the things we need it to do, not go
>back to change sets.
>
>-Ralph Johnson

"Go back" does not (always) equal "regress".  After all, some of us are 
"going back" to Smalltalk and I would consider that a huge step forward.  :)

_________________________________________________________________
PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows 
Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507