On 2012-06-11, at 21:56, Frank Shearar wrote:

> 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


Merges are part of the MC model, so I wouldn't call them bad. 

You could simply wait to commit until you're online. Before committing, you would update. That almost ensures your's will be current.

Or, you commit to your package cache while offline, and when online you load updates. If there is no newer version you just copy your version to trunk, but if it did the merge, you commit that one as a new package (but you should paste the commit message for simpler reference).

- Bert -