change-sets-vs-snapshots

Hi Colin,

Thanks for your reply.
Warning to the brave this has gotten longish.

***
>Colin Putney cputney at wiresong.ca 
>Sun Feb 17 04:24:59 UTC 2008 
>
>
>On 16-Feb-08, at 4:19 PM, Jerome Peace wrote:
>
>>> The perfect revision control system thread
>>> Colin Putney cputney at wiresong.ca
>>> Sat Feb 16 21:00:08 UTC 2008  wrote:
>>>
>>> If you look at discussion of versioning system
around
>> the net, you'll
>>> run across bitter arguments about
>> change-sets-vs-snapshots. As far as
>>> I can tell, the two are information-equivalent. I
>> think it boils down
>>> to how you prefer to think about the problem.
>>>
>> ***
>>
>> This would be about arguing income statements vs.
>> balance sheets.
>>
>> The info is complementary not the same. 
Change-sets
>> get you from snapshot to snapshot. The difference
>> between two snapshots is a change but not a
sequence
>> of change sets.  The use case that point this out
is a
>> move or a swap
>>
>
>> the change needed for a swap is:
>> temp := a .
>> a := b .
>> b := temp .
>
>If you look closely, you'll see that I claimed that
the information is  
>equivalent, not the same. In the transition from a
starting state to a  
>end state, you can represent the intermediate states
with snapshots or  
>deltas. In your example above you've got 3 changes.
There are  
>corresponding snapshots as well:
>
>Imagine that we have a starting state like this:
>
>a -> $a, b -> $b, temp -> nil
>
>Then your sequence of changes corresponds to the
following snapshots:
>
>a -> $a, b -> $b, temp -> $a
>a -> $b, b -> $b, temp -> $a
>a -> $b, b ->$a, temp -> $a
>

This was kind of a tame example. And you are correct,
the 4 snapshots contain the equivalent information.

The problem I have is that I am concerned about image
maintainence and repair.  And this raises issue beyond
the scope of maintaining a single package. The 3.9
decision to do everything by loading .mcz files and
abandoning update streams severely and negatively
impacted the ability to do that easily and with
minimal effort.

I know this is not your fault. It was a mistake on the
part of the 3.9 team. Even at that time you claimed MC
was meant for a limited purpose. It helps maintain
reasonably well defined packages across systems.

>> See:
>>
>http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-February/101071.
>html
>> For an Andreas Raab take on this with the original
MC.
>
>Initially I misunderstood what Andreas meant by
maintaining live  
>systems. He was right, though, to say that MC wasn't
designed for  
>that. MC solves a different problem - that of
integrating changes by  
>different developers. I think that, practically, it's
not possible to  
>maintain a live system in an automated way.  As a
simple example,  
>consider converting a Point from cartesian
coordinates to polar. The  
>only way to do it is to write a little script -
change sets won't do it.
>
>The update stream would have no problems with a Point
conversion  
>script, of course. People tend to think of changes
sets and the update  
>stream as the same thing, but that's not the case. Up
until Squeak  
>3.9, the update stream included scripts that applied
change sets, but  
>the 3.9 release team used scripts that loaded MC
packages instead.  
>Neither MC nor change sets can properly migrate Point
instances, but  
>the update stream, being more general than either,
has no problem with  
>it.
>
Yes. Good point about the difference. Part of my
appreciation of change sets is that they allow
preambles and postambles which can contain the doits. 

>> My curiosity is, if you are thinking what you said
>> above, do you still have a blind spot for time and
>> sequence?
>
>Well, I'll be the first to admit that I don't fully
understand this  
>stuff. I'm not sure what you mean by "blind spot"
though... is there  
>something you find particularly frustrating about MC
or my comments  
>about versioning?

My frustration with MC is that commiting to it means
abandoning the given tools of change sets ( and
therefore projects). 

MC and changeset don't interoperate. Because change
sets have one set of assumptions about catagories and
MC has another. To changesets method catagories are
unimportant. In particular if a method is added to a
catagory the entire class catagory structure is filed
out w/ the set. And when filed in reorganizes all the
catagories of that class. Undoing any catagories
changed in between. In MC the method catagories are
critical and determine whether code is saved in a
package or not.  These assumptions are in conflict. 

MC came second so IMO MC broke changesets.

The more devastating frustration, And this is where
sequence comes in, MC requires me as a coder to
consider the method catagory of my code FIRST. If I
decide later to change it, that requires me to
backtrack and change several packages. In this sense,
for me, it is an out of sequence tool in the
Christopher Alexander sense*. And not suitable for my
purposes.

I would like not to end this on such a negative note,
however the other things I have to say would start a
new topic and this post is long enough without that.

I know MC developed in response to a need which it
helps solve. The context in which I am struggling with
it is beyond the scope of its design.

Again, Thanks for your reply.  Please pardon any
harshness in the tone of these posts. Frustration and
a tough cold can affect my writing and in the case of
the first post my judgement. 


Yours in curiosity and frustration, --Jeorme Peace

* see: 
http://www.patternlanguage.com/leveltwo/recipesframe.htm?/sequencetheory/sequenceopener.htm
and also:
http://en.wikipedia.org/wiki/Sequence_theory



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping