Smalltalk › Squeak › Squeak - Dev

DeltaStreams again

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Göran Krampe

DeltaStreams again

Hi!

After yet another night of hacking I have come a bit further. I started
working on #apply and #revert. #revert is implemented like:

self asAntiDelta apply

...and asAntiDelta is more or less done by:

changes reverseDo: [:each | antiDelta addChange: each asAntiChange]

...modulo my memory. ;)

I came as far as a test case where I create a DSDelta with three changes:
- Create class
- Change its comment
- Add two ivars

..and then can nuke the class, apply delta (Johnny is back!) and revert
delta (Johnny is gone again!). Well, apart from some buglet in
SystemEditor regarding class comment - this works.

DSDelta>>apply looks something like:

^self class applier apply: self

Which means the actual apply code is broken out into an "applier" object
which uses double dispatch on all change instances to do the work. I am
implementing a DSSystemEditorApplier.

Well, that is it for now. :) Note though that I am doing a bit of
"spiking" here - all kinds of changes are not working yet and so on.

regards, Göran

Jason Johnson-5

Re: DeltaStreams again

Hi,

I downloaded the new Deltas the other day. First I must say it looked
good, I like how it's going.

Second is, I noticed you group certain changes together as one. For
example if I delete a bunch of iVars and say "accept" that will show
up as one change. How does this work with cherry picking? For
example, if I'm working maintenance and I fix 3 bugs at once, it might
be that I remove a bunch of variables from a class as part of the fix.
Then later I want to move the variable removals into a change set
named after the bug. Will I be able to separate them after the fact?

Jason Johnson-5

Re: DeltaStreams again

Göran,

Did you miss my question from this message, or are you mad at me? :)

On 9/11/07, Jason Johnson <[hidden email]> wrote:

> Hi,
>
> I downloaded the new Deltas the other day. First I must say it looked
> good, I like how it's going.
>
> Second is, I noticed you group certain changes together as one. For
> example if I delete a bunch of iVars and say "accept" that will show
> up as one change. How does this work with cherry picking? For
> example, if I'm working maintenance and I fix 3 bugs at once, it might
> be that I remove a bunch of variables from a class as part of the fix.
> Then later I want to move the variable removals into a change set
> named after the bug. Will I be able to separate them after the fact?
>

Tapple Gao

Re: DeltaStreams again

On Fri, Oct 05, 2007 at 07:19:58AM +0200, Jason Johnson wrote:

> G?ran,
>
> Did you miss my question from this message, or are you mad at me? :)
>
> On 9/11/07, Jason Johnson <[hidden email]> wrote:
> > Hi,
> >
> > I downloaded the new Deltas the other day. First I must say it looked
> > good, I like how it's going.
> >
> > Second is, I noticed you group certain changes together as one. For
> > example if I delete a bunch of iVars and say "accept" that will show
> > up as one change. How does this work with cherry picking? For
> > example, if I'm working maintenance and I fix 3 bugs at once, it might
> > be that I remove a bunch of variables from a class as part of the fix.
> > Then later I want to move the variable removals into a change set
> > named after the bug. Will I be able to separate them after the fact?

I forgot all about this question. I don't know how common this
use case would be, but I am building the unit tests to support
lots of wierd cases, and this one seems less obscure than the
ones I have tested.

It seems reasonable. A big constraint of the instance variable
modifying code is that the order of instance variables is
important, so add/remove won't always cut it. See the thread:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119602.html

Perhaps a series of ivar additions could be modeled as:
add: #ivar3 after: #ivar1
add: #ivar3 beforeIndex: 2
add: #ivar3 newState: #(ivar1 ivar3 ivar2)

The current model is
before: #(ivar1 ivar2); after: #(ivar1 ivar3 ivar2)
but yes, it does group several additions as one change

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808

Jason Johnson-5

Re: DeltaStreams again

Well, if a bunch of things are removed at once, I don't care about the
order, since it's the same. But I do care about being able to
separate them into different deltas after the fact.

It may seem a little obscure at the moment, but this feature is what
made darcs popular.

On 10/5/07, Matthew Fulmer <[hidden email]> wrote:

> On Fri, Oct 05, 2007 at 07:19:58AM +0200, Jason Johnson wrote:
> > G?ran,
> >
> > Did you miss my question from this message, or are you mad at me? :)
> >
> > On 9/11/07, Jason Johnson <[hidden email]> wrote:
> > > Hi,
> > >
> > > I downloaded the new Deltas the other day. First I must say it looked
> > > good, I like how it's going.
> > >
> > > Second is, I noticed you group certain changes together as one. For
> > > example if I delete a bunch of iVars and say "accept" that will show
> > > up as one change. How does this work with cherry picking? For
> > > example, if I'm working maintenance and I fix 3 bugs at once, it might
> > > be that I remove a bunch of variables from a class as part of the fix.
> > > Then later I want to move the variable removals into a change set
> > > named after the bug. Will I be able to separate them after the fact?
>
> I forgot all about this question. I don't know how common this
> use case would be, but I am building the unit tests to support
> lots of wierd cases, and this one seems less obscure than the
> ones I have tested.
>
> It seems reasonable. A big constraint of the instance variable
> modifying code is that the order of instance variables is
> important, so add/remove won't always cut it. See the thread:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119602.html
>
> Perhaps a series of ivar additions could be modeled as:
> add: #ivar3 after: #ivar1
> add: #ivar3 beforeIndex: 2
> add: #ivar3 newState: #(ivar1 ivar3 ivar2)
>
> The current model is
> before: #(ivar1 ivar2); after: #(ivar1 ivar3 ivar2)
> but yes, it does group several additions as one change
>
> --
> Matthew Fulmer -- http://mtfulmer.wordpress.com/
> Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
>
>