On 30 January 2013 18:33, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of Kernel to project The Inbox: http://source.squeak.org/inbox/Kernel-fbs.735.mcz
==================== Summary ====================
Name: Kernel-fbs.735 Author: fbs Time: 30 January 2013, 6:33:47.078 pm UUID: 18ffff61-cfcf-4843-8c64-caea3ceb3fbc Ancestors: Kernel-fbs.734
Actually, return a Message, and find out the receiver of the Message from the signalercontext.
Also, _returning_ the value of #subclassResponsibility means that you can return to the original caller the value of your just implemented method.
=============== Diff against Kernel-fbs.734 ===============
Item was added:
- ----- Method: ContextPart>>asMessage (in category 'converting') -----
- asMessage
| sender selector args |
sender := self sender.
selector := sender method selector.
args := Array new: selector numArgs.
1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
^ Message selector: selector arguments: args.!
Item was removed:
- ----- Method: ContextPart>>asMessageSend (in category 'converting') -----
- asMessageSend
| sender selector args |
sender := self sender.
selector := sender method selector.
args := Array new: selector numArgs.
1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
^ MessageSend receiver: self receiver selector: selector arguments: args.!
<snip>
Diffs serve as a helper for reviewers. To that end, the diffs ought to actually show what changes would be applied to trunk should the change be accepted. This diff, for instance, shows the removal of #asMessageSend and the addition of #asMessage, but really the change applied to trunk will be just the addition of #asMessage.
In other words when something undergoes a few rounds of review (and I'd think this should be the _norm_) the reviewer must reconstruct a series of diffs to get an idea of how trunk will change.
Wouldn't it be better to diff against trunk rather than against the mcz's ancestor? (*)
frank
(*) This is actually how github's pull requests work: you _can_ see the commit history, but you also have a straight "this is what will change" view, which is where I normally look.
On Wed, Jan 30, 2013 at 10:50 AM, Frank Shearar frank.shearar@gmail.comwrote:
On 30 January 2013 18:33, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of Kernel to project The Inbox: http://source.squeak.org/inbox/Kernel-fbs.735.mcz
==================== Summary ====================
Name: Kernel-fbs.735 Author: fbs Time: 30 January 2013, 6:33:47.078 pm UUID: 18ffff61-cfcf-4843-8c64-caea3ceb3fbc Ancestors: Kernel-fbs.734
Actually, return a Message, and find out the receiver of the Message
from the signalercontext.
Also, _returning_ the value of #subclassResponsibility means that you
can return to the original caller the value of your just implemented method.
=============== Diff against Kernel-fbs.734 ===============
Item was added:
- ----- Method: ContextPart>>asMessage (in category 'converting') -----
- asMessage
| sender selector args |
sender := self sender.
selector := sender method selector.
args := Array new: selector numArgs.
1 to: selector numArgs do: [ :i | args at: i put: (sender
tempAt: i)].
^ Message selector: selector arguments: args.!
Item was removed:
- ----- Method: ContextPart>>asMessageSend (in category 'converting')
- asMessageSend
| sender selector args |
sender := self sender.
selector := sender method selector.
args := Array new: selector numArgs.
1 to: selector numArgs do: [ :i | args at: i put: (sender
tempAt: i)].
^ MessageSend receiver: self receiver selector: selector
arguments: args.!
<snip>
Diffs serve as a helper for reviewers. To that end, the diffs ought to actually show what changes would be applied to trunk should the change be accepted. This diff, for instance, shows the removal of #asMessageSend and the addition of #asMessage, but really the change applied to trunk will be just the addition of #asMessage.
In other words when something undergoes a few rounds of review (and I'd think this should be the _norm_) the reviewer must reconstruct a series of diffs to get an idea of how trunk will change.
Wouldn't it be better to diff against trunk rather than against the mcz's ancestor? (*)
frank
Yes, it would be better to diff against trunk. But 'Trunk' isn't a defined state - what you have currently as Trunk isn't what I have currently as trunk - I haven't updated as recently as you have, for instance, so the changes that will be applied if I accepted/updated will be different than if you accept/update.
Maybe you are talking about diffs against the most recent predecessor in the Trunk Repository? That should be doable - but if there is no predecessor (a completely new package is moved in), then all of the messages are new.
-Chris
On 31 January 2013 00:16, Chris Cunningham cunningham.cb@gmail.com wrote:
On Wed, Jan 30, 2013 at 10:50 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 30 January 2013 18:33, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of Kernel to project The Inbox: http://source.squeak.org/inbox/Kernel-fbs.735.mcz
==================== Summary ====================
Name: Kernel-fbs.735 Author: fbs Time: 30 January 2013, 6:33:47.078 pm UUID: 18ffff61-cfcf-4843-8c64-caea3ceb3fbc Ancestors: Kernel-fbs.734
Actually, return a Message, and find out the receiver of the Message from the signalercontext.
Also, _returning_ the value of #subclassResponsibility means that you can return to the original caller the value of your just implemented method.
=============== Diff against Kernel-fbs.734 ===============
Item was added:
- ----- Method: ContextPart>>asMessage (in category 'converting') -----
- asMessage
| sender selector args |
sender := self sender.
selector := sender method selector.
args := Array new: selector numArgs.
1 to: selector numArgs do: [ :i | args at: i put: (sender
tempAt: i)].
^ Message selector: selector arguments: args.!
Item was removed:
- ----- Method: ContextPart>>asMessageSend (in category 'converting')
- asMessageSend
| sender selector args |
sender := self sender.
selector := sender method selector.
args := Array new: selector numArgs.
1 to: selector numArgs do: [ :i | args at: i put: (sender
tempAt: i)].
^ MessageSend receiver: self receiver selector: selector
arguments: args.!
<snip>
Diffs serve as a helper for reviewers. To that end, the diffs ought to actually show what changes would be applied to trunk should the change be accepted. This diff, for instance, shows the removal of #asMessageSend and the addition of #asMessage, but really the change applied to trunk will be just the addition of #asMessage.
In other words when something undergoes a few rounds of review (and I'd think this should be the _norm_) the reviewer must reconstruct a series of diffs to get an idea of how trunk will change.
Wouldn't it be better to diff against trunk rather than against the mcz's ancestor? (*)
frank
Yes, it would be better to diff against trunk. But 'Trunk' isn't a defined state - what you have currently as Trunk isn't what I have currently as trunk - I haven't updated as recently as you have, for instance, so the changes that will be applied if I accepted/updated will be different than if you accept/update.
No, "trunk" is whatever the trunk repo says.
Once I figure out how to load the version of ss3 that SqF runs and turned it into an SM package (*), I'll submit the patch Bert asked for, and we'll have diffs against the trunk repo.
frank
(*) Is it possible to transfer ownership of a package in SM? I guess adding a new admin would be the way...
Am 31.01.2013 um 23:56 schrieb Frank Shearar frank.shearar@gmail.com:
On 31 January 2013 00:16, Chris Cunningham cunningham.cb@gmail.com wrote:
On Wed, Jan 30, 2013 at 10:50 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 30 January 2013 18:33, commits@source.squeak.org wrote:
<snip>
Diffs serve as a helper for reviewers. To that end, the diffs ought to actually show what changes would be applied to trunk should the change be accepted. This diff, for instance, shows the removal of #asMessageSend and the addition of #asMessage, but really the change applied to trunk will be just the addition of #asMessage.
In other words when something undergoes a few rounds of review (and I'd think this should be the _norm_) the reviewer must reconstruct a series of diffs to get an idea of how trunk will change.
Wouldn't it be better to diff against trunk rather than against the mcz's ancestor? (*)
frank
Yes, it would be better to diff against trunk. But 'Trunk' isn't a defined state - what you have currently as Trunk isn't what I have currently as trunk - I haven't updated as recently as you have, for instance, so the changes that will be applied if I accepted/updated will be different than if you accept/update.
No, "trunk" is whatever the trunk repo says.
Once I figure out how to load the version of ss3 that SqF runs and turned it into an SM package (*), I'll submit the patch Bert asked for, and we'll have diffs against the trunk repo.
Hello Frank. I just want to make sure that you know that source.squeak.org is _not_ running ss3. While I am reguarily “harvesting” features from the source.squeak.org version into ss3, its not the version running there :)
best -tobas
On 1 February 2013 10:47, Tobias Pape Das.Linux@gmx.de wrote:
Am 31.01.2013 um 23:56 schrieb Frank Shearar frank.shearar@gmail.com:
On 31 January 2013 00:16, Chris Cunningham cunningham.cb@gmail.com wrote:
On Wed, Jan 30, 2013 at 10:50 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 30 January 2013 18:33, commits@source.squeak.org wrote:
<snip>
Diffs serve as a helper for reviewers. To that end, the diffs ought to actually show what changes would be applied to trunk should the change be accepted. This diff, for instance, shows the removal of #asMessageSend and the addition of #asMessage, but really the change applied to trunk will be just the addition of #asMessage.
In other words when something undergoes a few rounds of review (and I'd think this should be the _norm_) the reviewer must reconstruct a series of diffs to get an idea of how trunk will change.
Wouldn't it be better to diff against trunk rather than against the mcz's ancestor? (*)
frank
Yes, it would be better to diff against trunk. But 'Trunk' isn't a defined state - what you have currently as Trunk isn't what I have currently as trunk - I haven't updated as recently as you have, for instance, so the changes that will be applied if I accepted/updated will be different than if you accept/update.
No, "trunk" is whatever the trunk repo says.
Once I figure out how to load the version of ss3 that SqF runs and turned it into an SM package (*), I'll submit the patch Bert asked for, and we'll have diffs against the trunk repo.
Hello Frank. I just want to make sure that you know that source.squeak.org is _not_ running ss3. While I am reguarily “harvesting” features from the source.squeak.org version into ss3, its not the version running there :)
Hi Tobias,
Sorry, yes, I misspoke, because I completely misunderstood your mentioning of ss3 earlier in the thread. You were asking me to submit a patch to ss3 in addition to ss-SqF.
frank
best -tobas
Am 30.01.2013 um 19:50 schrieb Frank Shearar frank.shearar@gmail.com:
On 30 January 2013 18:33, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of Kernel to project The Inbox: http://source.squeak.org/inbox/Kernel-fbs.735.mcz
==================== Summary ====================
Name: Kernel-fbs.735 Author: fbs Time: 30 January 2013, 6:33:47.078 pm UUID: 18ffff61-cfcf-4843-8c64-caea3ceb3fbc Ancestors: Kernel-fbs.734
Actually, return a Message, and find out the receiver of the Message from the signalercontext.
Also, _returning_ the value of #subclassResponsibility means that you can return to the original caller the value of your just implemented method.
=============== Diff against Kernel-fbs.734 ===============
Item was added:
- ----- Method: ContextPart>>asMessage (in category 'converting') -----
- asMessage
| sender selector args |
sender := self sender.
selector := sender method selector.
args := Array new: selector numArgs.
1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
^ Message selector: selector arguments: args.!
Item was removed:
- ----- Method: ContextPart>>asMessageSend (in category 'converting') -----
- asMessageSend
| sender selector args |
sender := self sender.
selector := sender method selector.
args := Array new: selector numArgs.
1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
^ MessageSend receiver: self receiver selector: selector arguments: args.!
<snip>
Diffs serve as a helper for reviewers. To that end, the diffs ought to actually show what changes would be applied to trunk should the change be accepted. This diff, for instance, shows the removal of #asMessageSend and the addition of #asMessage, but really the change applied to trunk will be just the addition of #asMessage.
In other words when something undergoes a few rounds of review (and I'd think this should be the _norm_) the reviewer must reconstruct a series of diffs to get an idea of how trunk will change.
Wouldn't it be better to diff against trunk rather than against the mcz's ancestor? (*)
frank
You should move obsolete versions out of the inbox. The diff is against the latest ancestor in inbox or trunk.
We could change that to prefer trunk over inbox as diff base, agreed. Care to submit a squeaksource patch? :)
- Bert -
On 31 January 2013 06:31, Bert Freudenberg bert@freudenbergs.de wrote:
Am 30.01.2013 um 19:50 schrieb Frank Shearar frank.shearar@gmail.com:
On 30 January 2013 18:33, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of Kernel to project The Inbox: http://source.squeak.org/inbox/Kernel-fbs.735.mcz
==================== Summary ====================
Name: Kernel-fbs.735 Author: fbs Time: 30 January 2013, 6:33:47.078 pm UUID: 18ffff61-cfcf-4843-8c64-caea3ceb3fbc Ancestors: Kernel-fbs.734
Actually, return a Message, and find out the receiver of the Message from the signalercontext.
Also, _returning_ the value of #subclassResponsibility means that you can return to the original caller the value of your just implemented method.
=============== Diff against Kernel-fbs.734 ===============
Item was added:
- ----- Method: ContextPart>>asMessage (in category 'converting') -----
- asMessage
| sender selector args |
sender := self sender.
selector := sender method selector.
args := Array new: selector numArgs.
1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
^ Message selector: selector arguments: args.!
Item was removed:
- ----- Method: ContextPart>>asMessageSend (in category 'converting') -----
- asMessageSend
| sender selector args |
sender := self sender.
selector := sender method selector.
args := Array new: selector numArgs.
1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
^ MessageSend receiver: self receiver selector: selector arguments: args.!
<snip>
Diffs serve as a helper for reviewers. To that end, the diffs ought to actually show what changes would be applied to trunk should the change be accepted. This diff, for instance, shows the removal of #asMessageSend and the addition of #asMessage, but really the change applied to trunk will be just the addition of #asMessage.
In other words when something undergoes a few rounds of review (and I'd think this should be the _norm_) the reviewer must reconstruct a series of diffs to get an idea of how trunk will change.
Wouldn't it be better to diff against trunk rather than against the mcz's ancestor? (*)
frank
You should move obsolete versions out of the inbox. The diff is against the latest ancestor in inbox or trunk.
OK, but if we do that then we lose ancestry. I know what you're hinting at, and I'd also like to see the equivalent of a git squash - "take these versions in this branch and squish them together so that the main line only sees a single commit". Right now that's pretty onerous: it'd be a manual task, fraught with opportunities to mess up. Er, actually, am I talking nonsense? Given some series of mczs, once the chain/latest has passed peer review, I could
* load the latest versions into a clean up-to-date image * file out the versions (so we flush the ancestry) * load the fileouts into a clean up-to-date image * commit to trunk, with suitable commit messages.
That's nearly automatable, except for the commit messages.
We could change that to prefer trunk over inbox as diff base, agreed. Care to submit a squeaksource patch? :)
*ahem*. OK - that's http://source.squeak.org/SqueakSource-SqF/ right?
frank
- Bert -
On 31 January 2013 09:36, Frank Shearar frank.shearar@gmail.com wrote:
On 31 January 2013 06:31, Bert Freudenberg bert@freudenbergs.de wrote:
Am 30.01.2013 um 19:50 schrieb Frank Shearar frank.shearar@gmail.com:
On 30 January 2013 18:33, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of Kernel to project The Inbox: http://source.squeak.org/inbox/Kernel-fbs.735.mcz
==================== Summary ====================
Name: Kernel-fbs.735 Author: fbs Time: 30 January 2013, 6:33:47.078 pm UUID: 18ffff61-cfcf-4843-8c64-caea3ceb3fbc Ancestors: Kernel-fbs.734
Actually, return a Message, and find out the receiver of the Message from the signalercontext.
Also, _returning_ the value of #subclassResponsibility means that you can return to the original caller the value of your just implemented method.
=============== Diff against Kernel-fbs.734 ===============
Item was added:
- ----- Method: ContextPart>>asMessage (in category 'converting') -----
- asMessage
| sender selector args |
sender := self sender.
selector := sender method selector.
args := Array new: selector numArgs.
1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
^ Message selector: selector arguments: args.!
Item was removed:
- ----- Method: ContextPart>>asMessageSend (in category 'converting') -----
- asMessageSend
| sender selector args |
sender := self sender.
selector := sender method selector.
args := Array new: selector numArgs.
1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
^ MessageSend receiver: self receiver selector: selector arguments: args.!
<snip>
Diffs serve as a helper for reviewers. To that end, the diffs ought to actually show what changes would be applied to trunk should the change be accepted. This diff, for instance, shows the removal of #asMessageSend and the addition of #asMessage, but really the change applied to trunk will be just the addition of #asMessage.
In other words when something undergoes a few rounds of review (and I'd think this should be the _norm_) the reviewer must reconstruct a series of diffs to get an idea of how trunk will change.
Wouldn't it be better to diff against trunk rather than against the mcz's ancestor? (*)
frank
You should move obsolete versions out of the inbox. The diff is against the latest ancestor in inbox or trunk.
OK, but if we do that then we lose ancestry. I know what you're hinting at, and I'd also like to see the equivalent of a git squash - "take these versions in this branch and squish them together so that the main line only sees a single commit". Right now that's pretty onerous: it'd be a manual task, fraught with opportunities to mess up. Er, actually, am I talking nonsense? Given some series of mczs, once the chain/latest has passed peer review, I could
- load the latest versions into a clean up-to-date image
- file out the versions (so we flush the ancestry)
- load the fileouts into a clean up-to-date image
- commit to trunk, with suitable commit messages.
That's nearly automatable, except for the commit messages.
We could change that to prefer trunk over inbox as diff base, agreed. Care to submit a squeaksource patch? :)
*ahem*. OK - that's http://source.squeak.org/SqueakSource-SqF/ right?
Sorry, I obviously meant
MCHttpRepository location: 'http://source.squeak.org/ss' user: '' password: ''
frank
- Bert -
On 31 January 2013 09:49, Frank Shearar frank.shearar@gmail.com wrote:
On 31 January 2013 09:36, Frank Shearar frank.shearar@gmail.com wrote:
On 31 January 2013 06:31, Bert Freudenberg bert@freudenbergs.de wrote:
Am 30.01.2013 um 19:50 schrieb Frank Shearar frank.shearar@gmail.com:
On 30 January 2013 18:33, commits@source.squeak.org wrote:
Frank Shearar uploaded a new version of Kernel to project The Inbox: http://source.squeak.org/inbox/Kernel-fbs.735.mcz
==================== Summary ====================
Name: Kernel-fbs.735 Author: fbs Time: 30 January 2013, 6:33:47.078 pm UUID: 18ffff61-cfcf-4843-8c64-caea3ceb3fbc Ancestors: Kernel-fbs.734
Actually, return a Message, and find out the receiver of the Message from the signalercontext.
Also, _returning_ the value of #subclassResponsibility means that you can return to the original caller the value of your just implemented method.
=============== Diff against Kernel-fbs.734 ===============
Item was added:
- ----- Method: ContextPart>>asMessage (in category 'converting') -----
- asMessage
| sender selector args |
sender := self sender.
selector := sender method selector.
args := Array new: selector numArgs.
1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
^ Message selector: selector arguments: args.!
Item was removed:
- ----- Method: ContextPart>>asMessageSend (in category 'converting') -----
- asMessageSend
| sender selector args |
sender := self sender.
selector := sender method selector.
args := Array new: selector numArgs.
1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
^ MessageSend receiver: self receiver selector: selector arguments: args.!
<snip>
Diffs serve as a helper for reviewers. To that end, the diffs ought to actually show what changes would be applied to trunk should the change be accepted. This diff, for instance, shows the removal of #asMessageSend and the addition of #asMessage, but really the change applied to trunk will be just the addition of #asMessage.
In other words when something undergoes a few rounds of review (and I'd think this should be the _norm_) the reviewer must reconstruct a series of diffs to get an idea of how trunk will change.
Wouldn't it be better to diff against trunk rather than against the mcz's ancestor? (*)
frank
You should move obsolete versions out of the inbox. The diff is against the latest ancestor in inbox or trunk.
OK, but if we do that then we lose ancestry. I know what you're hinting at, and I'd also like to see the equivalent of a git squash - "take these versions in this branch and squish them together so that the main line only sees a single commit". Right now that's pretty onerous: it'd be a manual task, fraught with opportunities to mess up. Er, actually, am I talking nonsense? Given some series of mczs, once the chain/latest has passed peer review, I could
- load the latest versions into a clean up-to-date image
- file out the versions (so we flush the ancestry)
- load the fileouts into a clean up-to-date image
- commit to trunk, with suitable commit messages.
That's nearly automatable, except for the commit messages.
We could change that to prefer trunk over inbox as diff base, agreed. Care to submit a squeaksource patch? :)
*ahem*. OK - that's http://source.squeak.org/SqueakSource-SqF/ right?
Sorry, I obviously meant
MCHttpRepository location: 'http://source.squeak.org/ss' user: '' password: ''
Also, how do I load it? It looks like it at least depends on Seaside. Any chance of an Installer script?
frank
- Bert -
On 2013-01-31, at 10:51, Frank Shearar frank.shearar@gmail.com wrote:
On 31 January 2013 09:49, Frank Shearar frank.shearar@gmail.com wrote:
On 31 January 2013 09:36, Frank Shearar frank.shearar@gmail.com wrote:
On 31 January 2013 06:31, Bert Freudenberg bert@freudenbergs.de wrote:
We could change that to prefer trunk over inbox as diff base, agreed. Care to submit a squeaksource patch? :)
MCHttpRepository location: 'http://source.squeak.org/ss' user: '' password: ''
Also, how do I load it? It looks like it at least depends on Seaside. Any chance of an Installer script?
Try SSLoader-ar.1.mcm (no guarantees though).
- Bert -
Am 31.01.2013 um 10:36 schrieb Frank Shearar frank.shearar@gmail.com:
On 31 January 2013 06:31, Bert Freudenberg bert@freudenbergs.de wrote:
Am 30.01.2013 um 19:50 schrieb Frank Shearar frank.shearar@gmail.com:
On 30 January 2013 18:33, commits@source.squeak.org wrote:
<snip>
Diffs serve as a helper for reviewers. To that end, the diffs ought to actually show what changes would be applied to trunk should the change be accepted. This diff, for instance, shows the removal of #asMessageSend and the addition of #asMessage, but really the change applied to trunk will be just the addition of #asMessage.
In other words when something undergoes a few rounds of review (and I'd think this should be the _norm_) the reviewer must reconstruct a series of diffs to get an idea of how trunk will change.
Wouldn't it be better to diff against trunk rather than against the mcz's ancestor? (*)
frank
You should move obsolete versions out of the inbox. The diff is against the latest ancestor in inbox or trunk.
OK, but if we do that then we lose ancestry. I know what you're hinting at, and I'd also like to see the equivalent of a git squash - "take these versions in this branch and squish them together so that the main line only sees a single commit".
What about the "adopt ancestor" option of monticello? This would neatly allow this.
BEst -Tobias
Right now that's pretty onerous: it'd be a manual task, fraught with opportunities to mess up. Er, actually, am I talking nonsense? Given some series of mczs, once the chain/latest has passed peer review, I could
- load the latest versions into a clean up-to-date image
- file out the versions (so we flush the ancestry)
- load the fileouts into a clean up-to-date image
- commit to trunk, with suitable commit messages.
That's nearly automatable, except for the commit messages.
We could change that to prefer trunk over inbox as diff base, agreed. Care to submit a squeaksource patch? :)
*ahem*. OK - that's http://source.squeak.org/SqueakSource-SqF/ right?
and http://www.squeaksource.com/squeaksource3 *tongueincheek* ;)
Best -Tobias
On 31 January 2013 10:00, Tobias Pape Das.Linux@gmx.de wrote:
Am 31.01.2013 um 10:36 schrieb Frank Shearar frank.shearar@gmail.com:
On 31 January 2013 06:31, Bert Freudenberg bert@freudenbergs.de wrote:
Am 30.01.2013 um 19:50 schrieb Frank Shearar frank.shearar@gmail.com:
On 30 January 2013 18:33, commits@source.squeak.org wrote:
<snip>
Diffs serve as a helper for reviewers. To that end, the diffs ought to actually show what changes would be applied to trunk should the change be accepted. This diff, for instance, shows the removal of #asMessageSend and the addition of #asMessage, but really the change applied to trunk will be just the addition of #asMessage.
In other words when something undergoes a few rounds of review (and I'd think this should be the _norm_) the reviewer must reconstruct a series of diffs to get an idea of how trunk will change.
Wouldn't it be better to diff against trunk rather than against the mcz's ancestor? (*)
frank
You should move obsolete versions out of the inbox. The diff is against the latest ancestor in inbox or trunk.
OK, but if we do that then we lose ancestry. I know what you're hinting at, and I'd also like to see the equivalent of a git squash - "take these versions in this branch and squish them together so that the main line only sees a single commit".
What about the "adopt ancestor" option of monticello? This would neatly allow this.
It look me a while to find it (it's the "Backport" button, right?), but it's just what I wanted. Thanks!
frank
BEst -Tobias
Right now that's pretty onerous: it'd be a manual task, fraught with opportunities to mess up. Er, actually, am I talking nonsense? Given some series of mczs, once the chain/latest has passed peer review, I could
- load the latest versions into a clean up-to-date image
- file out the versions (so we flush the ancestry)
- load the fileouts into a clean up-to-date image
- commit to trunk, with suitable commit messages.
That's nearly automatable, except for the commit messages.
We could change that to prefer trunk over inbox as diff base, agreed. Care to submit a squeaksource patch? :)
*ahem*. OK - that's http://source.squeak.org/SqueakSource-SqF/ right?
and http://www.squeaksource.com/squeaksource3 *tongueincheek* ;)
Best -Tobias
On 2013-01-31, at 10:36, Frank Shearar frank.shearar@gmail.com wrote:
On 31 January 2013 06:31, Bert Freudenberg bert@freudenbergs.de wrote:
Am 30.01.2013 um 19:50 schrieb Frank Shearar frank.shearar@gmail.com:
Wouldn't it be better to diff against trunk rather than against the mcz's ancestor? (*)
frank
You should move obsolete versions out of the inbox. The diff is against the latest ancestor in inbox or trunk.
OK, but if we do that then we lose ancestry.
How so? All ancestry info is stored in each package version.
I know what you're hinting at, and I'd also like to see the equivalent of a git squash - "take these versions in this branch and squish them together so that the main line only sees a single commit".
That's pretty much what happens if you move or merge a version into trunk.
Right now that's pretty onerous: it'd be a manual task, fraught with opportunities to mess up. Er, actually, am I talking nonsense? Given some series of mczs, once the chain/latest has passed peer review, I could
- load the latest versions into a clean up-to-date image
- file out the versions (so we flush the ancestry)
- load the fileouts into a clean up-to-date image
- commit to trunk, with suitable commit messages.
That's nearly automatable, except for the commit messages.
No, you would just merge your latest inbox thingy into trunk, and explain what that does in the commit message. When other people update, that's the only commit they see.
- Bert -
squeak-dev@lists.squeakfoundation.org