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

[Jerome Peace]

Hi Bert,

I've learned a lot from this thread. Especially from
your suggestions for solutions. You seem to know your
way around MC and its repositorys.

I am looking a MC from outside that experience. So
when you say:

>What MC does is sensible.

I want to ask:

In what context?
The problem with squeak releases is that you are
likely to have new people doing them each time.
Probably doing it for the experience.
So part of what is needed is a system that is easy to
teach to the inexperienced.

So what is required of MC is not just that it be
sensible to itself or to an experienced user.

(Can you remember exactly how you came by your
experience? Was there a pleasuralby way to it. Or did
you achieve it by trial and error.  If the latter how
much penalty did MC impose on the experience?)

Leaving that aside. I am hankering for two tools to
improve things.

First a better way to print out a uuid. Since its
based on time I should be able to take an encoded UUID
and print it out asHumanIntelligableText. 

Secondly it would seem that a time based version
number would be a little less dangerous than a
sequential version. So a package would be name
somethink like:
PackageName-subPackage-initials.yymmddnn.mcz
with yymmddnn is a number based on time with a
sufficient resolution to solve most problems.
The details may be modified to meet other design
criteria (e.g. spaceCompression).

The first should be easy to do. I wonder what it would
take to train MC to work with the second.


Yours in curiosity and service, --Jerome Peace

***
>[V3dot10] Re: RV: Do in a workspace and say if could
build
>
>
>Bert Freudenberg bert at freudenbergs.de 
>Wed Jun 20 21:57:12 UTC 2007 
>
>
>On Jun 20, 2007, at 23:31 , Lex Spoon wrote:
>
>> Ken Causey <ken at kencausey.com> writes:
>>> Well, isn't this fun. ;)
>>>
>>> I tried this and all was going well until I got
the very same  
>>> complaint
>>> 'Could not find version...' for Etoys-edc.23. 
Etoys-edc.25 has an
>>> ancester Etoys-edc.23 with a different UUID than
the copy in the
>>> repository... same story.
>>
>> Well, they are supposed to be "universally unique",
right?  So the
>> more uniqueness, the better!
>>
>> Seriously, it sounds like Monticello would be
better off using the
>> name of the package as the identifier, instead of a
generated random
>> number or whatever it uses.  In this case, "Etoys"
would seem to make
>> a great identifier.
>>
>> 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.
>
>What MC does is sensible.
>
>- Bert -
>
>
***



       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting