Hi.

I have issues with the cmm proposal - besides the size of the number (which
is too big), basing it on timestamp is going to be a problem.  First off we
have to decide on a mandatory specific timezone, otherwise we will have
commits created before other commits being flagged as 'more current' if
they are in the right timezones - and we have enough widely spaced
developers/committers that this WILL happen.

Further, with the timezones, getting all of our dev machines (and/or all of
the repository machines) synced up with the same time and right timezone
offset rules is HARD.  From personal experience, even with a set of Unix
boxes all setup to sync off the same timeserver, they still drift out of
sync with each other.  It is a mess.

However, the idea of "using the ID as filename in the backend" I don't
really like, either.  I use file directories locally for development, and
having them all stored as an unintelligible name there will cause me angst
in the short term.  Further, I would assume that passing files via email,
say, we'd still keep the 'backend' name as well?  Or the other artificial
'name'?

Also, this would mean that we'd need to patch all of our publicly facing
repositories, right?  The Squeak ones are definitely doable; the ones
located in other companies gets weirder; personal 'public' repositories are
definitely weirder, especially if their owners have moved on to other
pursuits.  And then there is SmalltalkHub as well.  Of course, maybe I'm
just overworrying about this part.

-cbc

On Thu, Feb 14, 2019 at 1:08 AM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> Hi Chris,
> i don't like this change because it looses a very important thing:
> READABILITY
>
> Monotonicity doesn't count as long as you have a tool that can sort out
> the ancestry.
> Since we always browse the versions thru some MC tools it's superfluous.
> Monotonicity is mainly for helping us poor humans to quckly identify the
> relationship between two packages in the graph.
>
> This is only going to work with 3 to 5 figures in version number.
> With 10 figures, this is ruining our brain and just does not work.
> Please revert or put in inbox purgatory while we have a chance to discuss
> it.
>
> As for uniqueness, this is a small problem.
> As long as we have unique ID, then we should use that for storing and
> retrieving a package.
> The ID is stored in the ancestry, so it's just a matter of using the ID as
> filename in the backend rather than the ambiguous package name.
> It's more complex because we have to change our servers and protocols, but
> it would be the right thing to do.
> I think that you are doing the easy but and not the right one with your
> quick and clever hack.
>
> Le jeu. 14 févr. 2019 à 05:23, Chris Muller <ma.chris.m at gmail.com> a
> écrit :
>
>> HI Eliot,
>>
>> > > On Feb 13, 2019, at 7:13 PM, Chris Muller <asqueaker at gmail.com>
>> wrote:
>> > >
>> > > What are the two most-important properties we want from our
>> > > versionNumber?  Monotonicity and uniqueness.  The current scheme only
>> > > provides the former, this uses DateAndTime now utcMicroseconds to
>> > > provide the latter, too.  As a bonus it also happens to encode the
>> > > save timestamp into the VersionName, so available without having to
>> > > open the file.
>> > >
>> > > I admit it looks intimidating given what we're used to seeing, but
>> > > what of the added safety and utility?
>> >
>> > It is trumped by the illegibility.
>>
>> Not as bad as it appears, since the high-order digits will be the same
>> between version #'s, plus, second-resolution should be sufficient, so
>> versions in a list would actually look like this:
>>
>>     Monticello-cmm-1550203798
>>     Monticello-cmm-1550117398
>>     Monticello-cmm-1550030998
>>
>> Whilst still retaining all of the utility.  Maybe even a setting in
>> the tools could hide the high-order digits in the UI if we wanted...
>> We're already into 4 digits in our version #'s anyway so....
>>
>> > When was the discussion around this change?
>>
>> You're participating in it now.   :)
>>
>> There was another change to earlier today that you may be interested
>> in asking that question about too, since it changed 19-year old
>> SequenceableCollection>>#= with a one-day old replacement and actually
>> went into trunk.  This one is in the Inbox.
>>
>> > I’ve been out if things (apologies) but I find this change quite
>> horrible.
>>
>> I understand this initial gut reaction, but I hope you'll think and
>> sleep on it, and help think about the problem and some alternative
>> solutions you like better.  VersionName uniqueness is important for
>> the Monticello model.
>>
>> Best,
>>   Chris
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190214/8eb6dc87/attachment.html>