DeltaStreams and MC2
Locked
 
|
Hi,
Giovanni asked me to contact the DeltaStreams team. I just wanted to inform you that I wrote some documentation about MC2: http://wiki.squeak.org/squeak/5624. MC2 is able to manage ChangeSets as well as PackageInfo. So, I'm unsure if DeltaStreams are really useful. I also published some notes on the Summer of Squeak blog. Ask me questions if you want. -- Damien Cassou |
|
|
Hi!
> Hi, > > Giovanni asked me to contact the DeltaStreams team. That would be Matthew Fulmer and me currently. :) > I just wanted to > inform you that I wrote some documentation about MC2: > http://wiki.squeak.org/squeak/5624. > > MC2 is able to manage ChangeSets as well as PackageInfo. So, I'm > unsure if DeltaStreams are really useful. I also published some notes > on the Summer of Squeak blog. I am not sure what you mean with "manage ChangeSets" but the gist of Deltas (the streams of deltas aspect is actually the "next step" of it) are IMHO: - Class ChangeSet and friends implemented much more correctly. - Are standalone objects (not just pointing at stuff like a ChangeSet does) that can be loaded into the image and then "applied" and also "reverted"! - Works similarly to ChangeSet as a "recording tape" of system change events. This means a Delta can also be used as a "true log" much like the changes file is. Now, there are more aspects to the above - for example, since they collect enough information to be able to revert themselves they can also do "smart things" when being applied/merged etc, that other systems may have a hard time to do. An example: if you change a class comment the Delta actually records both the old comment and the new. Then later, when being applied in some totally different image the delta can check that the comment being replaced is actually the same as the old one, or alert the user if it is not. Yes, a trivial example - but the interesting part is to be able to help with merging etc without extensive historical analysis - which should make Deltas useful when moving code between radically different images - like from Croquet into vanilla Squeak for example. > Ask me questions if you want. I know too little of MC2 to ask any good questions. :) IMHO Deltas are intended to: - Fully replace ChangeSet and friends fully covering all functionality but simply much better and robust. Great for bug fixes, patches etc. - Give us a useful "smarter" option for moving code between radically different code bases. - Give us new ways to deal with change logging in general. - Give us the base for "Quilt"-like mechanisms. Also see Mercurial patch queues, the same concept. This is very interesting and should be trivial to do since Deltas can do full revert. - Give us the basis for a new kind of "update stream", the idea of tracking libraries and projects using Deltas instead of "MC snapshot loading". It is not meant to be an MC replacement and will not be an option for "team based SCM" as MC and MC2 aims at since it doesn't do advanced history and thus will never be able to do as sophisticated merging. BUT... that is by design. Also, it uses SystemEditor just like MC2 does (right?) and we have made several fixes in SE while building DeltaStreams. regards, Göran |
|
|
On 10/2/07, Göran Krampe <[hidden email]> wrote:
> Also, it uses SystemEditor just like MC2 does (right?) and we have made > several fixes in SE while building DeltaStreams. If both of you are making changes to SystemEditor, you need to synchronize. Don't end up with two versions of it! You need to do more than share your changes, you need to talk about them. That will make it more likely that everybody else will adapt it. -Ralph |
|
|
In reply to this post by Damien Cassou-3
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. On 10/2/07, Damien Cassou <[hidden email]> wrote: > Hi, > > Giovanni asked me to contact the DeltaStreams team. I just wanted to > inform you that I wrote some documentation about MC2: > http://wiki.squeak.org/squeak/5624. > > MC2 is able to manage ChangeSets as well as PackageInfo. So, I'm > unsure if DeltaStreams are really useful. I also published some notes > on the Summer of Squeak blog. > > Ask me questions if you want. > > -- > Damien Cassou > > |
|
|
On 02/10/2007, Jason Johnson <[hidden email]> 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 :) > On 10/2/07, Damien Cassou <[hidden email]> wrote: > > Hi, > > > > Giovanni asked me to contact the DeltaStreams team. I just wanted to > > inform you that I wrote some documentation about MC2: > > http://wiki.squeak.org/squeak/5624. > > > > MC2 is able to manage ChangeSets as well as PackageInfo. So, I'm > > unsure if DeltaStreams are really useful. I also published some notes > > on the Summer of Squeak blog. > > > > Ask me questions if you want. > > > > -- > > Damien Cassou > > > > > > -- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org |
|
|
Hi!
> On 02/10/2007, Jason Johnson <[hidden email]> 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 |
|
|
2007/10/3, Göran Krampe <[hidden email]>:
> 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. :) You might want to have a look at the smalltalk model classes in MC2 (one class from Class, one class for inst vars...) -- Damien Cassou |
|
|
In reply to this post by Ralph Johnson
Hi!
> On 10/2/07, Göran Krampe <[hidden email]> wrote: > >> Also, it uses SystemEditor just like MC2 does (right?) and we have made >> several fixes in SE while building DeltaStreams. > > If both of you are making changes to SystemEditor, you need to > synchronize. Don't end up with two versions of it! You need to do > more than share your changes, you need to talk about them. That will > make it more likely that everybody else will adapt it. > > -Ralph We have communicated with Colin and he told us to just put any improved snapshots into his repo - which we did. The latest snapshots that Matthew have done are in our DeltaStreams SS repo though - but I think the idea was to copy them over to Colin's. Also, I think our "changes" are mainly of the "fix" nature - at least my few were. regards, Göran |
|
|
In reply to this post by Göran Krampe
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 <[hidden email]> 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 > > > |
|
|
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 <[hidden email]> 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 <[hidden email]> 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 > > > > > > > > > |
|
|
In reply to this post by Göran Krampe
On Wed, Oct 03, 2007 at 10:17:59AM +0200, G?ran Krampe wrote:
> We have communicated with Colin and he told us to just put any improved > snapshots into his repo - which we did. The latest snapshots that Matthew > have done are in our DeltaStreams SS repo though - but I think the idea > was to copy them over to Colin's. Also, I think our "changes" are mainly > of the "fix" nature - at least my few were. I am putting fixes in Colin's repo as well, but I have intentionally kept the recent versions, where I added Categorization support, out of colin's repo, since they violate a lot of encapsulation which SystemEditor had previously enforced (like not being able to access a MethodEditor from a ClassEditor class) -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 |
|
|
In reply to this post by stephane ducasse
On Wed, Oct 03, 2007 at 02:51:18PM +0200, stephane ducasse wrote:
> goran just a question > could MC2 be based on DeltaStreams in terms of how to load/save > packages? It could, but I don't think it would really be a good idea. A delta is both an old and new version combined into one object, providing stand-alone applying, reverting, and validation, without dependence on historical analysis. A Monticello snapshot (in both Monticello 1 and 2) is just the new version, and uses historical analysis for loading, validation, merging, and, to some extent, reverting. A monticello package is tied to it's historical information, allows it to provide excellent merging and collaboration facilities, but does not really allow patches to be applied to disparate code chunks in disparate images, especially where the historical information may not exist. Deltas, on the other hand, are stand-alone entities providing a patch, a path from an old state to a new state, but nothing else. Thus, they are not very collaborative, but they do allow applying, reverting, and differencing between systems and system states without needing additional infrastructure. A good analogy is that Monticello is to code packages what .sources is to the image. Similarly, deltas are to code packages what .changes is to the image. Hope that helps -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 |
|
|
In reply to this post by Damien Cassou-3
On Wed, Oct 03, 2007 at 10:16:55AM +0200, Damien Cassou wrote:
> 2007/10/3, G??ran Krampe <[hidden email]>: > > 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. :) > > You might want to have a look at the smalltalk model classes in MC2 > (one class from Class, one class for inst vars...) I looked at the model classes for MC2 before I started on DeltaStreams. The DS kernel model is: DSChange DSClassChange DSInstVarChange DSClassCommentChange ... DSMethodChange DSMethodSourceChange DSMethodProtocolChange ... DSDoIt DSCompositeChange DSChangeSequence DSDelta ... DSChangeCategorizer DSVisitor DSApplier DSSystemEditorApplier ... DSVisitor provides a ton of double-dispatch methods: applyChange: applyMethodSourceChange applyInstVarsChange apply: applyClassChange: applyCompositeChange: applyDelta: etc. Every DSClassChange has both a "before" and "after" state. Before working on DS, I worked with the MC1 MCPatchOperation, which provides similar capabilities as DSChange, but is not double-dispatch visitable. This made writing a readable diff for SqueakSource commit emails very difficult DSChange withAllSubclasses size "34" DSVisitor withAllSubclasses size "11" I don't know if this is the best, or even a good model, but it provides exactly what is needed to make deltas appliable, revertable, groupable, searchable, validatable, and condensable. It quite possibly has way to many classes. Using something more generic like PRCommands may make the model more generic, but that is not the immediate goal. I do want to try using the Pier model for this task someday, though... -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |