I think the MC2 strategy would be to add Deltas as one of the ways it
can do it's work.  But I had planned on exploring making something on
top of Deltas. :)

On 10/3/07, stephane ducasse <stephane.ducasse at free.fr> wrote:
> 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
> >
> >
> >
>
>
>