Hi!

Andreas Raab wrote:
> Göran Krampe wrote:
>>> One thing that's not quite clear in this picture is where the 
>>> "canonical" source for patches would be and how it would be 
>>
>> Not sure I understand what you mean here.
> 
> Simply the question of where/how DS are stored. Monticello has 
> repositories that store full source for a package. As a consequence 
> packages are large, but they allow you to see what's different in your 
> image, what a patch does, tracking history etc. You can agree on a place 
> and say "this is THE repository for package X" etc. I'm wondering where 
> DS stand with regards to these issues.

Since the Stream part is not yet started I am all ears. But apart from 
the obvious fact that Deltas can serve the same roles as Changesets can 
(only better), I was envisioning chronological "streams" (as in 
continuous flows) of Deltas associated with individual developers, 
forks, packages and branches of packages etc.

For example, I would gladly suck up all Deltas people produce that touch 
any of my packages. :) Thus, if people would submit their Deltas to some 
huge searchable archive - or if we had at least some simple "upstream" 
hooked to packages so that when people make fixes they can easily just 
shoot them "upstream" at me, it would be great.

>>> produced. In most of what you wrote you've concentrated more on the 
>>> harvesting aspect (i.e., being able to cherry-pick contributions from 
>>> elsewhere) but how does an actual development flow look like?
>>
>> Well, I can't really say although I have some ideas, let me again 
>> mention some things Deltas should make possible and then we could try 
>> to think together what that means for the "flow":
>>
>> - Deltas can be loaded into an image "en masse" because loading a 
>> Delta simply deserializes it into a fully self contained object. This 
>> means we can read, edit and analyse them without affecting the image.
>>
>> - Deltas can be applied and unapplied.
>>
>> - Deltas can "reason" about how well they can be applied. This is 
>> because each change within the Delta has information about the state 
>> "before" the change. For example, a ModifyMethodChange has both new 
>> and old source (and stamps etc).
> 
> That's *very* useful. One of my favorite features when using MC is that 
> it can tell us if there is a conflict in a merge and that this method 
> requires special attention. If DS can do something similar by telling us 
> that the base version of a method is different from when the DS was 
> created this will be hugely helpful.

This is in fact the *core idea*. The idea came about after watching 
Linus thoughts on git and to think about how MC and most SCMs work. They 
all get their "merge magic" from extensive knowledge of history to a 
common base. But that is something we don't have between forks.

Thus, could we get 80% of magic using simpler tricks? The trick is to 
let the Changeset contain more info - especially info about the "before" 
state. This of course both enables unapply, but more essentially it 
enables much smarter apply-logic.

A "perfectly clean" Delta is one that sees the exact same "before" state 
as it captured when it was created in the source image. A "dirty" Delta 
is one that can be applied (classes are not missing etc) but it will 
overwrite for example methods that look different than expected.

Also, a Delta can do other smart things since it has captured class 
definition changes in more detail - say you add an ivar "c" and when it 
checks the destination image it finds other additional ivars but no "c" 
- then it can merge by just adding "c". Nice eh? :)

>> Some things we already know:
>>
>> - Deltas in fact implement a more advanced changelog. It could be used 
>> to replace the .changes file.
>>
>> - Since they can be applied/unapplied Deltas can easily be used to 
>> build a "Quilt"-like system.
> 
> I don't know what that is. Any references?

Well, Mercurial queues are similar, see:

http://mercurial.selenic.com/wiki/MqExtension#Introduction


>> - Deltas are "rich" in state and can be analysed/manipulated in a lot 
>> of different ways.
>>
>> So... post is getting long. :) I am all ears for observations/ideas at 
>> this point. And yes, I will try to get DS into such a shape that we 
>> can actually start playing more seriously with them.
>>
>> Fully replacing Changesets would be a great start IMHO. To do that we 
>> need fileformat and UI. And a few other odd bits, but not much.
> 
> Keep me in the loop if you need help. I probably won't be touching the 
> domain model and stuff but if you need help on the surface and for 
> workflows I might be able to help out.

I will get back as soon as I have something to show.

regards, Göran