Is there a blog some where that shows the status of Delta streams? I
haven't heard anything in a while about those and I'm very interested in how it turns out. On Jan 22, 2008 12:06 AM, Keith Hodges <[hidden email]> wrote: > > itsme213 wrote: > > "Bert Freudenberg" <[hidden email]> wrote > > > >> Not really, because it is snapshot-based. > >> > > > > Ah, I think I get it. > > > > I was looking for a grouping corresponding to a refactoring. Would it make > > sense for refactorings to show up in whole? > > > > Thanks ... Sophie > > > DeltaStream's is able to represent groups of changes as you suggest > > Keith > > |
On Tue, Jan 22, 2008 at 06:29:15PM +0100, Jason Johnson wrote:
> Is there a blog some where that shows the status of Delta streams? I > haven't heard anything in a while about those and I'm very interested > in how it turns out. I wrote a post about it a while ago on my blog: http://mtfulmer.wordpress.com (I'm a horrible blogger). I had about a 2 month period of zero activity last year after I released 0.1 (which is why I made a release then). I am actively working on DeltaStreams in my spare time again (about an hour a day on the bus). and plan to release this code as 0.2 when I anticipate another lack of spare time. The biggest feature I added since I wrote that blog post is change validation. I added three types of validation to changes: 1. Orphan - The class this change refers to should be there, but isn't 2. Conflict: this change assumes a prior version that is not as expected. 3. Valid: Does this change even make sense (does the superclass or shared pool exist, etc) I added 136 unit tests to make sure these checks work as expected and they all pass. Now I am working on making the UI be able to display deltas in a reasonable manner, like show all removed classes in lower-contrast gray, highlight conflicts, ask for confirmation when applying unclean changes. Currently I am having bugs related to my buggy SystemOrganizerEditor, which makes some classes that the delta includes changes for not show up in the UI. Next I am going to implement more filtering of changes (only the "select changes for this class" actually works. I would like to do that on a package, category, protocol, and method level too). Next will be manipulation of deltas (add/remove changes manually), and Monticello integration (try updating this package to a new Monticello version). The last one will probably require a rewrite of SystemChangeNotifier to be extensible. I will use Announcements in this rewrite. All these changes will bring deltas up to the usability level of change-sets. At this point, I will probably make a release and try to get it into LPF as an alpha-level addition. It should be usable and stable enough to replace change sets at this point, even though delta streams are not even implemented yet. After that point, I will need to start implementing DeltaStreams. First, I will need a much better file-out format for deltas (something forward-compatible like chunk format, XML, Atom, or Spoon). the current file-out format is a version-specific binary DataStream format that is not compatible across releases. After that, I will start implementing Delta stream, which will allow the remote subscription to various update streams to work. Releases are unscheduled. I will probably make them when I either anticipate a lack of spare time or when I anticipate that a lot of work will be needed getting the next step ready before steady bug-fixing can resume. So, 0.2 will likely be made just before Monticello integration in the above schedule. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 |
Cool, thanks for the update (a couple of comments below)
On Jan 23, 2008 1:08 AM, Matthew Fulmer <[hidden email]> wrote: > > All these changes will bring deltas up to the usability level > of change-sets. At this point, I will probably make a release > and try to get it into LPF as an alpha-level addition. It should > be usable and stable enough to replace change sets at this > point, even though delta streams are not even implemented yet. That's good news. I had a pay project out there to add undo functionality to existing change sets to make them a little better, but Goran came up with this idea just before we had a release ready. :) Story of my life around here. But it's good to see that you will be able to replace existing change sets. I have in mind a change management system myself that will leverage your work. > After that point, I will need to start implementing > DeltaStreams. First, I will need a much better file-out format > for deltas (something forward-compatible like chunk format, XML, > Atom, or Spoon). the current file-out format is a > version-specific binary DataStream format that is not compatible > across releases. And this will replace the .changes file we have now, yes? If so, do you have a way of converting the existing changes in the system over so nothing is lost in the conversion? > After that, I will start implementing Delta > stream, which will allow the remote subscription to various > update streams to work. > > Releases are unscheduled. Sure. I understand your time situation very well. I certainly didn't mean my mail as some kind of push, I was just curious if there was a place somewhere I could keep current with the status. Thanks for that. >I will probably make them when I > either anticipate a lack of spare time or when I anticipate that > a lot of work will be needed getting the next step ready before > steady bug-fixing can resume. So, 0.2 will likely be made just > before Monticello integration in the above schedule. > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 |
On Wed, Jan 23, 2008 at 06:32:21AM +0100, Jason Johnson wrote:
> Cool, thanks for the update (a couple of comments below) > > On Jan 23, 2008 1:08 AM, Matthew Fulmer <[hidden email]> wrote: > > > > All these changes will bring deltas up to the usability level > > of change-sets. At this point, I will probably make a release > > and try to get it into LPF as an alpha-level addition. It should > > be usable and stable enough to replace change sets at this > > point, even though delta streams are not even implemented yet. > > That's good news. I had a pay project out there to add undo > functionality to existing change sets to make them a little better, > but Goran came up with this idea just before we had a release ready. > :) Story of my life around here. Hmm. I don't recall that. How did it work? > But it's good to see that you will be able to replace existing change > sets. I have in mind a change management system myself that will > leverage your work. Oh? Do tell. If you would like to contribute to DeltaStreams; feel free. The repository is world-writable. > > After that point, I will need to start implementing > > DeltaStreams. First, I will need a much better file-out format > > for deltas (something forward-compatible like chunk format, XML, > > Atom, or Spoon). the current file-out format is a > > version-specific binary DataStream format that is not compatible > > across releases. > > And this will replace the .changes file we have now, yes? If so, do > you have a way of converting the existing changes in the system over > so nothing is lost in the conversion? No. I have no plans to get rid of the .changes file anytime soon. After streams are implemented, I plan to get logging working so it is quite superior to the .changes file, and maybe after that look into removing the .changes file. DeltaStreams will probably need a 1.0 release before I even consider replacing the .changes file. So until that time comes, delta streams will live side-by-side the .changes file, duplicating what it is doing, but more nicely. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 |
Hi!
Just wanted to say that I am here. :) My interest is still there but can't say when I can spare hours. regards, Göran |
In reply to this post by Tapple Gao
On Jan 23, 2008 8:49 AM, Matthew Fulmer <[hidden email]> wrote:
> > Hmm. I don't recall that. How did it work? The project (or the pay system)? Assuming you meant the project, all it was was making the #undo (or whatever it is) message on change sets actually work. And it worked well, but Goran announced Delta streams days before it was ready so I didn't bother trying to get it into the 3.10. > Oh? Do tell. If you would like to contribute to DeltaStreams; > feel free. The repository is world-writable. Oh, it will be a while. I actually have less free time then you! :) Basically I have looked into Darcs a bit, and much of the complexity of that system comes from the fact that it can't make many assumptions about what it is revisioning. Smalltalk by contrast, can know everything it wants to about the source code it's revisioning. Getting undo to work was the first step in that direction, but now I will just use Delta streams instead since it's cleaner then the old change set stuff. The "killer app" feature of Darcs is "cherry picking" and Smalltalk has that for free already at any stage the developer wants, instead of at the end as Darcs has to do it. > No. I have no plans to get rid of the .changes file anytime > soon. After streams are implemented, I plan to get logging > working so it is quite superior to the .changes file, and maybe > after that look into removing the .changes file. DeltaStreams > will probably need a 1.0 release before I even consider > replacing the .changes file. So until that time comes, > delta streams will live side-by-side the .changes > file, duplicating what it is doing, but more nicely. Fair enough. |
In reply to this post by Tapple Gao
If you plan to replace changeset and tools. Will you have
classDefinition as first class entity vs. Doit as it is now? Because class definition as doit makes the replay of functionality quite tedious. Stef > On Tue, Jan 22, 2008 at 06:29:15PM +0100, Jason Johnson wrote: >> Is there a blog some where that shows the status of Delta streams? I >> haven't heard anything in a while about those and I'm very interested >> in how it turns out. > > I wrote a post about it a while ago on my blog: > http://mtfulmer.wordpress.com (I'm a horrible blogger). I had > about a 2 month period of zero activity last year after I > released 0.1 (which is why I made a release then). > > I am actively working on DeltaStreams in my spare time again > (about an hour a day on the bus). and plan to release this code > as 0.2 when I anticipate another lack of spare time. The > biggest feature I added since I wrote that blog post is change > validation. I added three types of validation to changes: > > 1. Orphan - The class this change refers to should be there, but > isn't > 2. Conflict: this change assumes a prior version that is not as > expected. > 3. Valid: Does this change even make sense (does the superclass > or shared pool exist, etc) > > I added 136 unit tests to make sure these checks work as > expected and they all pass. Now I am working on making the UI > be able to display deltas in a reasonable manner, like show all > removed classes in lower-contrast gray, highlight conflicts, ask > for confirmation when applying unclean changes. Currently I am > having bugs related to my buggy SystemOrganizerEditor, which > makes some classes that the delta includes changes for not show > up in the UI. Next I am going to implement more filtering of > changes (only the "select changes for this class" actually > works. I would like to do that on a package, category, protocol, > and method level too). Next will be manipulation of deltas > (add/remove changes manually), and Monticello integration (try > updating this package to a new Monticello version). The last one > will probably require a rewrite of SystemChangeNotifier to be > extensible. I will use Announcements in this rewrite. > > All these changes will bring deltas up to the usability level > of change-sets. At this point, I will probably make a release > and try to get it into LPF as an alpha-level addition. It should > be usable and stable enough to replace change sets at this > point, even though delta streams are not even implemented yet. > > After that point, I will need to start implementing > DeltaStreams. First, I will need a much better file-out format > for deltas (something forward-compatible like chunk format, XML, > Atom, or Spoon). the current file-out format is a > version-specific binary DataStream format that is not compatible > across releases. After that, I will start implementing Delta > stream, which will allow the remote subscription to various > update streams to work. > > Releases are unscheduled. I will probably make them when I > either anticipate a lack of spare time or when I anticipate that > a lot of work will be needed getting the next step ready before > steady bug-fixing can resume. So, 0.2 will likely be made just > before Monticello integration in the above schedule. > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 > > |
Hi!
> If you plan to replace changeset and tools. Will you have > classDefinition as first class entity vs. Doit as it is now? > Because class definition as doit makes the replay of functionality > quite tedious. ALL code modifications are first class entities. And note that the basic functionality of Deltas are more or less there already - I demonstrated it at OOPSLA in october and the... bof1 movie has that IIRC. :) I am truly happy that Matthew stepped up and did so much work on it - I have unfortunately been swamped. But my "swampedness" has some positive sides - a bit of it is Gjallar related - and that benefits Squeak in general since quite a bit of what we do there gets fed back as useful stuff in general. regards, Göran |
Free forum by Nabble | Edit this page |