[V3dot10] Re: RV: Do in a workspace and say if could build

[Bert Freudenberg]

On Jun 21, 2007, at 0:49 , Lex Spoon wrote:

> Bert Freudenberg <bert at freudenbergs.de> writes:
>> On Jun 20, 2007, at 23:31 , Lex Spoon wrote:
>>> Maybe it is not even too late.  Could the tools simply detect  
>>> that the
>>> packages are using generated uuid's, and then guess a "uuid" by
>>> looking at the filename?  E.g., for a file named "Etoys-edc.23",
>>> quietly treating the uuid as "Etoys"?
>>
>> Huh? Fo merging you *really* need the most recent common ancestor,
>> and you need to be *sure* which it is. UUIDs work well for this.
>> *Anything* could have happened between the two versions that were
>> saved under the same name and you would completely lose these changes
>> when comparing names only.
>
> Maybe I have the terms wrong, but I still do not see how a UUID helps
> with this.  You would identify a specific ancestor by name ("Etoys")
> plus version ("edc.23").  What is the problem?

The problem is that this is not unique. Like, the actual problem we  
were discussing is that Edgar accidentally saves two versions with  
the same name ("edc.23").

> Going the other way, do you truly want to have a repository that has
> two separate packages named Etoys-edc.23?  That sounds like a recipe
> for chaos.

Right, one should not do this. But that's just policy, or common  
sense if you will.

MC itself does not put any meanings into version names. You cannot  
tell form a version name which one is newer, or to what package it  
belongs. It's just a human-readable name.

Now, the squeaksource server UI as well as the MC UI tools actually  
interpret the names according to established conventions. This makes  
live easier if you adopt these rules, too (and harder if you ignore  
them). They should still work, none-theless, if you give arbitrary  
names to versions.

Given the distributed development model behind MC UUIDs are about the  
only choice. For example, it's well possible two developers use the  
same initials. Both produce version 23. Then what?


- Bert -