On May 25, 2004, at 10:54 AM, Doug Way wrote:

> Sounds okay to me.  I've only used Monticello a bit, so I'd want to be 
> clear on what exactly this includes... (bear with me if some of my 
> understanding is incorrect)
>
> - Having a good alternative to changesets for tracking chunks of code 
> in a purely declarative way (including class extensions etc.) is 
> definitely good, although I guess we already have that with 
> PackageInfo.

Right.  It's PackageInfo's job to group a set of classes and methods 
into a unit.  This has nothing to do with versioning or saving or 
loading code, just with carving up the image.  Monticello is happy to 
use whatever image carving scheme you like, although PackageInfo is the 
only one in use right now; in the long run I'm sure we'll have 
something more sophisticated.

> - Being able to have version numbers associated with these chunks of 
> code is also a good thing.  I don't think we have that with 
> PackageInfo, but we would with Monticello?  For example, if we carve 
> out the ProcessBrowser in Basic as a PI package, the image could know 
> that in 3.8alpha-6124, the ProcessBrowser package is mc version 1.23.

Yes.

>   (Perhaps there is an overlap with the concept of SM versions.)

SM versions are at a much coarser granularity than MC versions.  Only a 
small subset of the MC versions for a package will end up as releases 
on SM.

>   But the useful thing would be that we could determine the diffs from 
> ProcessBrowser package 1.21 and 1.23 from the image, which we cannot 
> really do with changesets.

Yes.  The other useful thing is that if two people make independent 
sets of changes to 1.23 (1.23a and 1.23b), they can be intelligently 
and automatically merged to form 1.24.  This can happen even if there 
has been a long and complicated change history, with however many 
branches and merges, in the meantime.

> Would this require connecting to a server which has the entire 
> ProcessBrowser package history, or would this history be contained in 
> the image itself, as it is with changesets?  (At least the history 
> that actually came through the image via updates.)

Each independent version of the code contains a complete snapshot of 
the code as it was when the version was created.  It also contains a 
complete ancestry tree of the version ids from which it is descended.  
A diff requires only that you have the two package versions you are 
diffing.  A merge requires three versions: the two versions you are 
merging, and their closest common ancestor (in the example above, you'd 
need 1.23a, 1.23b, and 1.23).  You never need any of the intervening 
versions.

> - Having the Monticello client code in Basic seems useful, too... 
> being able to connect to something like SqueakSource easily.

Yes.

> - Does this also include Monticello server code?  Kind of like how the 
> SqueakMap package has both the SM client and SM server code.  Er, ok, 
> reading the Monticello description it looks like it does not, so 
> nevermind.  (It looks like SqueakSource is a special Monticello 
> repository server app.)

Correct - there is no canonical "Monticello server", and the Monticello 
package includes no server code.  SqueakSource is the most 
sophisticated server that Monticello can talk to right now, but a 
simple ftpd works fine too.

> You mention that things like Browser should be version-control 
> agnostic... I agree, I think we should be prevent inappropriate 
> dependencies like that.  Actually, Browser should not be dependent on 
> Changesets either, which is a similar concept (although I wouldn't be 
> surprised if there are some inappropriate dependencies there).

Now that the SystemChangeNotification code is in place, it should be 
possible to completely separate changesets from the other tools.  I'm 
not sure how much of this has been done, but it would be a nice 
benchmark to be able to unload ChangeSet completely and have everything 
else still work.