Daniel Vainsencher wrote:
> Julian Fitzell <julian at beta4.com> wrote:
> 
>>I won't answer the other two points as Avi or Colin would be better able 
>>to do so, but I can answer this one.  When you merge a version into your 
>>working copy, you are incorporating the changes between that version and 
>>  your closest common ancestor.  You then add that version as an 
>>ancestor of your working copy.
>>
>>But your working copy is still modified relative to its primary ancestor.
> 
> Well, that depends what you consider your primary ancestor. Since the
> name of the working copy is that of the file I merged, I really expect
> the flag to be relative to that.

The primary ancestor is always the pristine one you actually had when 
you started making changes (so this means when you save or load).  It is 
also (from an implementation point of view) the first ancestor in your 
ancestor list.

I'm not sure what you mean by "the name of the working copy" but I think 
you mean what you see in brackets in the Working Copy browser.  What is 
in brackets is not the name of the version but the list of ancestors of 
the version.  In the case where you have just committed, your working 
copy is a brand new, un-named version with the committed version as an 
ancestor (which is why it looks like a name).  When you merge in a 
version, both ancestors would be listed in parentheses.  In the case of 
starting with an empty package and merging, the only actual ancestor is 
the one you merged in, even though there is a theoretical "Empty 
Package" just as there is an Empty Set which is the primary ancestor of 
the working copy.  This part of the UI is certainly confusing. 
Personally, I think using essentially arbitrary version names isn't very 
useful anyway but that UI needs more work and I haven't had the energy 
recently to push on it.

>>I have suggested to Avi that having a button 
>>that loads when your working copy is previously unmodified and merges 
>>when it's modified would be a good idea to reduce the need for users to 
>>know the differences.  But before we can do this we need a more reliable 
>>system of noticing when changes are made to the package (we can't catch 
>>class changes at the moment, for example).
> 
> Seems to me that the distinction I'm asking for should be made based on
> the actual differences found. In the example I give, the empty package
> has no ancestors, and therefore the diff is two way, so you know nothing
> useful before you actually do the diff... IIUC.

Again, it actually has the Empty Package as its ancestor, this just 
isn't being shown to you.  You can probably use the Adopt function to 
tell MC that the code in your image is based on the code in an .mcz file 
without actually loading the code and having it appear as changes.  But 
I'd have to test it to be sure that the logic there is right in my head.

Clearly there are some usability tweaks needed... I've been noticing my 
own over the last few days as we start using the new MC code for Seaside 
development at work.  I'll need to find some more time to throw at this 
soon so keep throwing out problems and hopefully somebody will have time.

Julian