peace_the_dreamer at yahoo.com
Sun Feb 24 06:01:51 UTC 2008
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
>> 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.
>> get you from snapshot to snapshot. The difference
>> between two snapshots is a change but not a
>> of change sets. The use case that point this out
>> 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.
>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
>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
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.
>> For an Andreas Raab take on this with the original
>Initially I misunderstood what Andreas meant by
>systems. He was right, though, to say that MC wasn't
>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
>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
>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
>3.9, the update stream included scripts that applied
change sets, but
>the 3.9 release team used scripts that loaded MC
>Neither MC nor change sets can properly migrate Point
>the update stream, being more general than either,
has no problem with
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
>Well, I'll be the first to admit that I don't fully
>stuff. I'm not sure what you mean by "blind spot"
though... is there
>something you find particularly frustrating about MC
or my comments
My frustration with MC is that commiting to it means
abandoning the given tools of change sets ( and
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
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
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
More information about the Squeak-dev