Delta streams status (was Re: monticello question)

stephane ducasse stephane.ducasse at free.fr
Wed Jan 23 19:42:01 UTC 2008


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
>
>




More information about the Squeak-dev mailing list