Or just invoke an update when you are inline...
update will merge.

Nicolas

2012/6/11 Frank Shearar <frank.shearar at gmail.com>:
> On 11 June 2012 20:35, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>
>> On 2012-06-11, at 21:26, Frank Shearar wrote:
>>
>>> On 11 June 2012 18:27, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>> On 2012-06-09, at 21:41, commits at source.squeak.org wrote:
>>>>
>>>>> Frank Shearar uploaded a new version of Kernel to project The Trunk:
>>>>> http://source.squeak.org/trunk/Kernel-fbs.697.mcz
>>>>>
>>>>> ==================== Summary ====================
>>>>>
>>>>> Name: Kernel-fbs.697
>>>>> Author: fbs
>>>>> Time: 8 June 2012, 2:58:00.068 pm
>>>>> UUID: bcec51c0-7e42-4f78-897b-73b99f088354
>>>>> Ancestors: Kernel-nice.693
>>>>>
>>>>> * The resolver instvar is initialised to an Array so #ifNotNil: is a no-op.
>>>>> * #evaluateResolver: reimplemented #cull:; rather use BlockClosure's version - less duplication.
>>>>
>>>>
>>>> This, too, is based on an old version. Kernel-nice.694 and Kernel-nice.695 are not merged.
>>>>
>>>> When you commit to trunk using Monticello, it should warn you about newer versions. Apparently you use a different method?
>>>
>>> Ah, I see now why "this, too". Er, I open my trunk (which I try to
>>> keep as up to date as possible, but don't necessarily update
>>> immediately prior to making my change - I'm usually offline at the
>>> time), make my change, and when I have a network connection, copy the
>>> snapshot to the inbox or trunk repository.
>>>
>>> I haven't seen any warnings though!
>>>
>>> frank
>>
>>
>> When you commit something to trunk it should be based on the latest version in trunk. For the inbox it doesn't really matter.
>>
>> What I do is develop, and when it's ready, I update (which merges the latest), and commit.
>>
>> If you committed something that is not based on the latest, then you must merge the latest, and commit again.
>
> Right. In short, my naive approach of committing snapshots doesn't
> work. OK, so if I want to work in an offline manner, then either I:
> * file out my changes in some manner until I'm online, update a clean
> image, file in the changes and then commit, or
> * save the mczs as before, update the (same) image, merge my mcz back
> in, and push?
>
> The first approach would result in the cleaner history, wouldn't it?
>
> frank
>
>> - Bert -
>>
>>
>>
>