Le jeu. 14 févr. 2019 à 10:06, Jakob Reschke <forums.jakob at resfarm.de> a
écrit :

> Should the numbers be relevant at all, except for human recognizing maybe?
> All that should count internally is the ancestry anyway. And the versions
> already have UUIDs, what more do they need.
>
> exactly! this number is for humans only and 10 significand digits kust
does not work.

Git has not had consecutive numbers for more than 13 years and it works
> quite well... Mercurial does have them, but does not rely on them and the
> are assigned differently in each clone.
>
> Fortunately, there are explicit branch names for helping us sorting out
the graph layout (make a mental image of it).
But they are not necessary for git tools, just for us humans.

Am Do., 14. Feb. 2019, 05:24 hat Chris Muller <ma.chris.m at gmail.com>
> geschrieben:
>
>> 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/75fe16e4/attachment.html>