change-sets-vs-snapshots

change-sets-vs-snapshots


***
> in
> 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 .

See:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-February/101071.html
For an Andreas Raab take on this with the original MC.

My curiosity is, if you are thinking what you said
above, do you still have a blind spot for time and
sequence?

As a bug tracker I find it helps to follow the beast
every step of the way. The culprit sometimes covers
his tracks and it is best to catch him in the act.

Yours in curiosity and service, --Jerome Peace



      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

On 16-Feb-08, at 4:19 PM, Jerome Peace wrote:

> 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

> 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.

> 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?

> As a bug tracker I find it helps to follow the beast
> every step of the way. The culprit sometimes covers
> his tracks and it is best to catch him in the act.

Huh? I'm afraid I don't understand the metaphor.

Colin