Göran Krampe wrote:
> Still, this is not what you may be asking about - I presume you see all
> the above - I presume you wonder about the "streams" part.

Well, no, not exactly. What I'm wondering about is how DS address the 
issues that I'd like to see addressed when looking at both Monticello 
and change sets. Because what I'm hoping DS will do is to integrate the 
best of change sets (flexibility, size, speed, cross-package changes) 
with the best of Monticello (versioning, compare, diff, merge). The 
reason why I want these together is that although I loathe Monticello 
for all its shortcomings I pick it in every new project over using 
change sets. Because by the end of the day, being able to say what is 
version X of package Y is more important than all the great properties 
of change sets (at least that is true for my work).

So what I'm wondering is, how can DS be used such that they overcome the 
problems with Monticello and how would one apply them to such uses. The 
main area that I see relates to "versions of packages". By far the 
biggest shortcoming of change sets is that they have no idea of versions 
and packages and because of that the use of change sets is currently 
mutually exclusive with the use of Monticello (don't get me started 
about this Frankenstream that is currently used to deal with MCZs as 
updates).

I think a version really is the entire set of transformations (Deltas) 
applied to bring the package to a particular state. In other words, a 
possible version of a package maintained with Deltas could just be a zip 
file with all the deltas included. However, in order to to be able to 
stream these changes we'd still need that information somehow inside the 
delta.

The best way I can think of dealing with it is if a delta could include 
information of the "from/to" versions of packages it applies to. In 
other words, it would include enough information to say: This delta 
started from package version Foo-bar.1, added method Foo>>bar and the 
result was package version Foo-bar.2.

This information allows two very important things: First, subscribers to 
the stream know which version their working version is based on (it 
doesn't guarantee that it is the exact version but similar to Monticello 
one could simply mark the package as dirty and require a full diff to 
find out whether it has actually changed) which solves the update stream 
problems we have today. With the "before state" that deltas have for 
individual changes it seems like a perfect match as one could easily 
reason about whether an incoming change conflicts with a local 
modification etc.

But secondly it should be possible to have multiple versions described 
that way for has cross-package changes. The reason why this is important 
is that obviously, when you need an atomic update of package Foo and Bar 
together they both need to be at the "right" version (e.g., the version 
that was described in the delta) and having that information allows you 
to update Foo, and when you hit the update in Foo that applies to both 
Foo and Bar, you can update Bar up to the point required by the delta 
and then apply it.

So it seems that having "some" version information in the deltas 
themselves is pretty important. It allows a number of operations that 
are otherwise hard or impossible to achieve and would integrate well 
with a "Monticello point of view" of maintaining sets of packages while 
at the same time having all the nice properties of change sets.

Thoughts?

Cheers,
   - Andreas