goran just a question
could MC2 be based on DeltaStreams in terms of how to load/save  
packages?

Stef

On 3 oct. 07, at 09:38, Göran Krampe wrote:

> Hi!
>
>> On 02/10/2007, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
>>> Just because MC2 exists doesn't mean there is no room for  
>>> competition.
>>>  Personally I am quite interested in the Change set replacement part
>>> of deltas.  I started down this road myself but Göran got further
>>> faster.
>>
>> Sure, but I don't really see the point of developing two similar
>> systems to manage changes (at least from the high level view). That
>> said I prefer to see manpower employed for parallel tracks rather  
>> than
>> for arguing which track is best :)
>
> AFAIK they are quite different. From the highest level I would  
> guess MC2
> is an "SCM for team work on packages" very much like MC1 is - I  
> mean, it
> mainly covers the same usage area. It uses complete history to perform
> very precise merging (again, similar to MC1, right?) and I would also
> guess it uses some mechanism to "stake out" a package (PI?) and take
> snapshots of it at given times. Those snapshots I presume are either
> loaded-and-applied or not-loaded-at-all. Yes, MC1 has the "browse"  
> feature
> - but it is AFAIK mainly used to "take a peek".
>
> Please correct me if I am wrong above - I have not yet read an  
> explanation
> of MC2 that gives me a good picture (and that is probably more due  
> to *me*
> than due to the explanations).
>
> Deltas (and streams of them) on the other hand are ChangeSets "done  
> right"
> :). A Delta can be loaded into the image but not applied. It is then a
> fully self contained object graph and is not affected by changes  
> (unlike a
> ChangeSet which only refers to methods and do not actually contain the
> versions of them) in the image. Then you can apply it to the image  
> and you
> can also revert it.
>
> Now, without going into other smarts in Deltas the above opens up
> interesting options - like having a whole set of Deltas you can  
> apply in
> series and revert in series too. A simple scenario is maintaing a  
> local
> "patch series" on top of upstream packages. When upstream releases  
> a new
> version you "lift" your local patches (revert them), upgrade the  
> package
> (using say MC1/2), then reapply your local patches on top. Since the
> Deltas are made to be able to do "the reasonable thing" WITHOUT  
> history
> analysis, this sounds to me like an interesting use case.
>
> In short: I think the two code bases are quite different and aim for
> different goals. But we touch upon "cooperative ground" like  
> SystemEditor
> and SystemChangeNotifier etc - both of which we have improved in  
> our work
> on Deltas - so cooperation and mutual understanding is *important*  
> but I
> do not think the two systems are that much overlapping in the end.  
> I can
> always be proved wrong. :)
>
> regards, Göran
>
>
>