The Inbox: Monticello-cmm.1550112371873461.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

The Inbox: Monticello-cmm.1550112371873461.mcz

commits-2
Chris Muller uploaded a new version of Monticello to project The Inbox:
http://source.squeak.org/inbox/Monticello-cmm.1550112371873461.mcz

==================== Summary ====================

Name: Monticello-cmm.1550112371873461
Author: cmm
Time: 13 February 2019, 8:53:17.238995 pm
UUID: 4e5412b2-6fac-4192-846e-40e4c24eb282
Ancestors: Monticello-nice.694

Monticello only requires monotonicity and uniqueness for its version numbers, not consecutiveness.

=============== Diff against Monticello-nice.694 ===============

Item was added:
+ ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry') -----
+ hasAncestorNamed: aString
+ self allAncestorsDo:
+ [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].
+ ^ false!

Item was changed:
  MCPackageManager subclass: #MCWorkingCopy
+ instanceVariableNames: 'versionInfo ancestry repositoryGroup requiredPackages environment'
- instanceVariableNames: 'versionInfo ancestry counter repositoryGroup requiredPackages environment'
  classVariableNames: ''
  poolDictionaries: ''
  category: 'Monticello-Versioning'!

Item was changed:
  ----- Method: MCWorkingCopy>>nextVersionName (in category 'private') -----
  nextVersionName
  | branch oldName |
  ancestry ancestors isEmpty
  ifTrue:
+ [ branch := package name ]
- [ counter ifNil: [ counter := 0 ].
- branch := package name ]
  ifFalse:
  [ oldName := ancestry ancestors first versionName.
+ branch := oldName packageAndBranchName ].
+ ^ branch , '-' , Utilities authorInitials , '.' , DateAndTime now utcMicroseconds asString!
- branch := oldName packageAndBranchName.
- counter ifNil:
- [ counter := (ancestry ancestors detectMax:
- [ : eachVersionInfo | eachVersionInfo versionNumber ])
- ifNil: [ 0 ]
- ifNotNil:
- [ : highestNumbered | highestNumbered versionNumber ] ] ].
- counter := counter + 1.
- ^ branch , '-' , Utilities authorInitials , '.' , counter asString!

Item was changed:
  ----- Method: MCWorkingCopy>>uniqueVersionName (in category 'private') -----
  uniqueVersionName
  |versionName|
- counter := nil.
  [versionName := self nextVersionName.
+ (self repositoryGroup includesVersionNamed: versionName) or: [ ancestry hasAncestorNamed: versionName ]] whileTrue.
- self repositoryGroup includesVersionNamed: versionName] whileTrue.
  ^ versionName!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Eliot Miranda-2


On Wed, Feb 13, 2019 at 6:53 PM <[hidden email]> wrote:
Chris Muller uploaded a new version of Monticello to project The Inbox:
http://source.squeak.org/inbox/Monticello-cmm.1550112371873461.mcz

Whaaaa?!?  :-)  Shurely shome mishtske.  hic.
 


==================== Summary ====================

Name: Monticello-cmm.1550112371873461
Author: cmm
Time: 13 February 2019, 8:53:17.238995 pm
UUID: 4e5412b2-6fac-4192-846e-40e4c24eb282
Ancestors: Monticello-nice.694

Monticello only requires monotonicity and uniqueness for its version numbers, not consecutiveness.

=============== Diff against Monticello-nice.694 ===============

Item was added:
+ ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry') -----
+ hasAncestorNamed: aString
+       self allAncestorsDo:
+               [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].
+       ^ false!

Item was changed:
  MCPackageManager subclass: #MCWorkingCopy
+       instanceVariableNames: 'versionInfo ancestry repositoryGroup requiredPackages environment'
-       instanceVariableNames: 'versionInfo ancestry counter repositoryGroup requiredPackages environment'
        classVariableNames: ''
        poolDictionaries: ''
        category: 'Monticello-Versioning'!

Item was changed:
  ----- Method: MCWorkingCopy>>nextVersionName (in category 'private') -----
  nextVersionName
        | branch oldName |
        ancestry ancestors isEmpty
                ifTrue:
+                       [ branch := package name ]
-                       [ counter ifNil: [ counter := 0 ].
-                       branch := package name ]
                ifFalse:
                        [ oldName := ancestry ancestors first versionName.
+                       branch := oldName packageAndBranchName ].
+       ^ branch , '-' , Utilities authorInitials , '.' , DateAndTime now utcMicroseconds asString!
-                       branch := oldName packageAndBranchName.
-                       counter ifNil:
-                               [ counter := (ancestry ancestors detectMax:
-                                       [ : eachVersionInfo | eachVersionInfo versionNumber ])
-                                       ifNil: [ 0 ]
-                                       ifNotNil:
-                                               [ : highestNumbered | highestNumbered versionNumber ] ] ].
-       counter := counter + 1.
-       ^ branch , '-' , Utilities authorInitials , '.' , counter asString!

Item was changed:
  ----- Method: MCWorkingCopy>>uniqueVersionName (in category 'private') -----
  uniqueVersionName
        |versionName|
-       counter := nil.
        [versionName := self nextVersionName.
+       (self repositoryGroup includesVersionNamed: versionName) or: [ ancestry hasAncestorNamed: versionName ]] whileTrue.
-       self repositoryGroup includesVersionNamed: versionName] whileTrue.
        ^ versionName!




--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Chris Muller-3
Nope.

On Wed, Feb 13, 2019 at 8:56 PM Eliot Miranda <[hidden email]> wrote:

>
>
>
> On Wed, Feb 13, 2019 at 6:53 PM <[hidden email]> wrote:
>>
>> Chris Muller uploaded a new version of Monticello to project The Inbox:
>> http://source.squeak.org/inbox/Monticello-cmm.1550112371873461.mcz
>
>
> Whaaaa?!?  :-)  Shurely shome mishtske.  hic.
>
>>
>>
>>
>> ==================== Summary ====================
>>
>> Name: Monticello-cmm.1550112371873461
>> Author: cmm
>> Time: 13 February 2019, 8:53:17.238995 pm
>> UUID: 4e5412b2-6fac-4192-846e-40e4c24eb282
>> Ancestors: Monticello-nice.694
>>
>> Monticello only requires monotonicity and uniqueness for its version numbers, not consecutiveness.
>>
>> =============== Diff against Monticello-nice.694 ===============
>>
>> Item was added:
>> + ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry') -----
>> + hasAncestorNamed: aString
>> +       self allAncestorsDo:
>> +               [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].
>> +       ^ false!
>>
>> Item was changed:
>>   MCPackageManager subclass: #MCWorkingCopy
>> +       instanceVariableNames: 'versionInfo ancestry repositoryGroup requiredPackages environment'
>> -       instanceVariableNames: 'versionInfo ancestry counter repositoryGroup requiredPackages environment'
>>         classVariableNames: ''
>>         poolDictionaries: ''
>>         category: 'Monticello-Versioning'!
>>
>> Item was changed:
>>   ----- Method: MCWorkingCopy>>nextVersionName (in category 'private') -----
>>   nextVersionName
>>         | branch oldName |
>>         ancestry ancestors isEmpty
>>                 ifTrue:
>> +                       [ branch := package name ]
>> -                       [ counter ifNil: [ counter := 0 ].
>> -                       branch := package name ]
>>                 ifFalse:
>>                         [ oldName := ancestry ancestors first versionName.
>> +                       branch := oldName packageAndBranchName ].
>> +       ^ branch , '-' , Utilities authorInitials , '.' , DateAndTime now utcMicroseconds asString!
>> -                       branch := oldName packageAndBranchName.
>> -                       counter ifNil:
>> -                               [ counter := (ancestry ancestors detectMax:
>> -                                       [ : eachVersionInfo | eachVersionInfo versionNumber ])
>> -                                       ifNil: [ 0 ]
>> -                                       ifNotNil:
>> -                                               [ : highestNumbered | highestNumbered versionNumber ] ] ].
>> -       counter := counter + 1.
>> -       ^ branch , '-' , Utilities authorInitials , '.' , counter asString!
>>
>> Item was changed:
>>   ----- Method: MCWorkingCopy>>uniqueVersionName (in category 'private') -----
>>   uniqueVersionName
>>         |versionName|
>> -       counter := nil.
>>         [versionName := self nextVersionName.
>> +       (self repositoryGroup includesVersionNamed: versionName) or: [ ancestry hasAncestorNamed: versionName ]] whileTrue.
>> -       self repositoryGroup includesVersionNamed: versionName] whileTrue.
>>         ^ versionName!
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Chris Muller-3
In reply to this post by Eliot Miranda-2
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?

Best,
  Chris

On Wed, Feb 13, 2019 at 8:56 PM Eliot Miranda <[hidden email]> wrote:

>
>
>
> On Wed, Feb 13, 2019 at 6:53 PM <[hidden email]> wrote:
>>
>> Chris Muller uploaded a new version of Monticello to project The Inbox:
>> http://source.squeak.org/inbox/Monticello-cmm.1550112371873461.mcz
>
>
> Whaaaa?!?  :-)  Shurely shome mishtske.  hic.
>
>>
>>
>>
>> ==================== Summary ====================
>>
>> Name: Monticello-cmm.1550112371873461
>> Author: cmm
>> Time: 13 February 2019, 8:53:17.238995 pm
>> UUID: 4e5412b2-6fac-4192-846e-40e4c24eb282
>> Ancestors: Monticello-nice.694
>>
>> Monticello only requires monotonicity and uniqueness for its version numbers, not consecutiveness.
>>
>> =============== Diff against Monticello-nice.694 ===============
>>
>> Item was added:
>> + ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry') -----
>> + hasAncestorNamed: aString
>> +       self allAncestorsDo:
>> +               [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].
>> +       ^ false!
>>
>> Item was changed:
>>   MCPackageManager subclass: #MCWorkingCopy
>> +       instanceVariableNames: 'versionInfo ancestry repositoryGroup requiredPackages environment'
>> -       instanceVariableNames: 'versionInfo ancestry counter repositoryGroup requiredPackages environment'
>>         classVariableNames: ''
>>         poolDictionaries: ''
>>         category: 'Monticello-Versioning'!
>>
>> Item was changed:
>>   ----- Method: MCWorkingCopy>>nextVersionName (in category 'private') -----
>>   nextVersionName
>>         | branch oldName |
>>         ancestry ancestors isEmpty
>>                 ifTrue:
>> +                       [ branch := package name ]
>> -                       [ counter ifNil: [ counter := 0 ].
>> -                       branch := package name ]
>>                 ifFalse:
>>                         [ oldName := ancestry ancestors first versionName.
>> +                       branch := oldName packageAndBranchName ].
>> +       ^ branch , '-' , Utilities authorInitials , '.' , DateAndTime now utcMicroseconds asString!
>> -                       branch := oldName packageAndBranchName.
>> -                       counter ifNil:
>> -                               [ counter := (ancestry ancestors detectMax:
>> -                                       [ : eachVersionInfo | eachVersionInfo versionNumber ])
>> -                                       ifNil: [ 0 ]
>> -                                       ifNotNil:
>> -                                               [ : highestNumbered | highestNumbered versionNumber ] ] ].
>> -       counter := counter + 1.
>> -       ^ branch , '-' , Utilities authorInitials , '.' , counter asString!
>>
>> Item was changed:
>>   ----- Method: MCWorkingCopy>>uniqueVersionName (in category 'private') -----
>>   uniqueVersionName
>>         |versionName|
>> -       counter := nil.
>>         [versionName := self nextVersionName.
>> +       (self repositoryGroup includesVersionNamed: versionName) or: [ ancestry hasAncestorNamed: versionName ]] whileTrue.
>> -       self repositoryGroup includesVersionNamed: versionName] whileTrue.
>>         ^ versionName!
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Eliot Miranda-2


> On Feb 13, 2019, at 7:13 PM, Chris Muller <[hidden email]> 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.  When was the discussion around this change?  I’ve been out if things (apologies) but I find this change quite horrible.

>
> Best,
>  Chris
>
>> On Wed, Feb 13, 2019 at 8:56 PM Eliot Miranda <[hidden email]> wrote:
>>
>>
>>
>>> On Wed, Feb 13, 2019 at 6:53 PM <[hidden email]> wrote:
>>>
>>> Chris Muller uploaded a new version of Monticello to project The Inbox:
>>> http://source.squeak.org/inbox/Monticello-cmm.1550112371873461.mcz
>>
>>
>> Whaaaa?!?  :-)  Shurely shome mishtske.  hic.
>>
>>>
>>>
>>>
>>> ==================== Summary ====================
>>>
>>> Name: Monticello-cmm.1550112371873461
>>> Author: cmm
>>> Time: 13 February 2019, 8:53:17.238995 pm
>>> UUID: 4e5412b2-6fac-4192-846e-40e4c24eb282
>>> Ancestors: Monticello-nice.694
>>>
>>> Monticello only requires monotonicity and uniqueness for its version numbers, not consecutiveness.
>>>
>>> =============== Diff against Monticello-nice.694 ===============
>>>
>>> Item was added:
>>> + ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry') -----
>>> + hasAncestorNamed: aString
>>> +       self allAncestorsDo:
>>> +               [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].
>>> +       ^ false!
>>>
>>> Item was changed:
>>>  MCPackageManager subclass: #MCWorkingCopy
>>> +       instanceVariableNames: 'versionInfo ancestry repositoryGroup requiredPackages environment'
>>> -       instanceVariableNames: 'versionInfo ancestry counter repositoryGroup requiredPackages environment'
>>>        classVariableNames: ''
>>>        poolDictionaries: ''
>>>        category: 'Monticello-Versioning'!
>>>
>>> Item was changed:
>>>  ----- Method: MCWorkingCopy>>nextVersionName (in category 'private') -----
>>>  nextVersionName
>>>        | branch oldName |
>>>        ancestry ancestors isEmpty
>>>                ifTrue:
>>> +                       [ branch := package name ]
>>> -                       [ counter ifNil: [ counter := 0 ].
>>> -                       branch := package name ]
>>>                ifFalse:
>>>                        [ oldName := ancestry ancestors first versionName.
>>> +                       branch := oldName packageAndBranchName ].
>>> +       ^ branch , '-' , Utilities authorInitials , '.' , DateAndTime now utcMicroseconds asString!
>>> -                       branch := oldName packageAndBranchName.
>>> -                       counter ifNil:
>>> -                               [ counter := (ancestry ancestors detectMax:
>>> -                                       [ : eachVersionInfo | eachVersionInfo versionNumber ])
>>> -                                       ifNil: [ 0 ]
>>> -                                       ifNotNil:
>>> -                                               [ : highestNumbered | highestNumbered versionNumber ] ] ].
>>> -       counter := counter + 1.
>>> -       ^ branch , '-' , Utilities authorInitials , '.' , counter asString!
>>>
>>> Item was changed:
>>>  ----- Method: MCWorkingCopy>>uniqueVersionName (in category 'private') -----
>>>  uniqueVersionName
>>>        |versionName|
>>> -       counter := nil.
>>>        [versionName := self nextVersionName.
>>> +       (self repositoryGroup includesVersionNamed: versionName) or: [ ancestry hasAncestorNamed: versionName ]] whileTrue.
>>> -       self repositoryGroup includesVersionNamed: versionName] whileTrue.
>>>        ^ versionName!
>>>
>>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Chris Muller-4
HI Eliot,

> > On Feb 13, 2019, at 7:13 PM, Chris Muller <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Jakob Reschke
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.

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.

Am Do., 14. Feb. 2019, 05:24 hat Chris Muller <[hidden email]> geschrieben:
HI Eliot,

> > On Feb 13, 2019, at 7:13 PM, Chris Muller <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Nicolas Cellier
In reply to this post by Chris Muller-4
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 <[hidden email]> a écrit :
HI Eliot,

> > On Feb 13, 2019, at 7:13 PM, Chris Muller <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Nicolas Cellier
In reply to this post by Jakob Reschke


Le jeu. 14 févr. 2019 à 10:06, Jakob Reschke <[hidden email]> 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 <[hidden email]> geschrieben:
HI Eliot,

> > On Feb 13, 2019, at 7:13 PM, Chris Muller <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Nicolas Cellier
Oh, but it is in the inbox already,
the reaction of Eliot made me think it wasn't.
apologies for my own confusion!

Le jeu. 14 févr. 2019 à 10:12, Nicolas Cellier <[hidden email]> a écrit :


Le jeu. 14 févr. 2019 à 10:06, Jakob Reschke <[hidden email]> 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 <[hidden email]> geschrieben:
HI Eliot,

> > On Feb 13, 2019, at 7:13 PM, Chris Muller <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

marcel.taeumel
In reply to this post by commits-2
Hi Chris,

-1

Since this directly affects Squeak's build number, we should not embrace such shenanigans. People could never estimate the count of changes between builds/updates again.

At least, we should try to minimize the jumps between versions as much as possible. Even though we might never be able to enforce that. Make it part of our community's goodwill and spirit to try at least.


Or choose one of many other models/mantras/idioms that strive for simplicity.

Best,
Marcel

Am 14.02.2019 03:53:27 schrieb [hidden email] <[hidden email]>:

Chris Muller uploaded a new version of Monticello to project The Inbox:
http://source.squeak.org/inbox/Monticello-cmm.1550112371873461.mcz

==================== Summary ====================

Name: Monticello-cmm.1550112371873461
Author: cmm
Time: 13 February 2019, 8:53:17.238995 pm
UUID: 4e5412b2-6fac-4192-846e-40e4c24eb282
Ancestors: Monticello-nice.694

Monticello only requires monotonicity and uniqueness for its version numbers, not consecutiveness.

=============== Diff against Monticello-nice.694 ===============

Item was added:
+ ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry') -----
+ hasAncestorNamed: aString
+ self allAncestorsDo:
+ [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].
+ ^ false!

Item was changed:
MCPackageManager subclass: #MCWorkingCopy
+ instanceVariableNames: 'versionInfo ancestry repositoryGroup requiredPackages environment'
- instanceVariableNames: 'versionInfo ancestry counter repositoryGroup requiredPackages environment'
classVariableNames: ''
poolDictionaries: ''
category: 'Monticello-Versioning'!

Item was changed:
----- Method: MCWorkingCopy>>nextVersionName (in category 'private') -----
nextVersionName
| branch oldName |
ancestry ancestors isEmpty
ifTrue:
+ [ branch := package name ]
- [ counter ifNil: [ counter := 0 ].
- branch := package name ]
ifFalse:
[ oldName := ancestry ancestors first versionName.
+ branch := oldName packageAndBranchName ].
+ ^ branch , '-' , Utilities authorInitials , '.' , DateAndTime now utcMicroseconds asString!
- branch := oldName packageAndBranchName.
- counter ifNil:
- [ counter := (ancestry ancestors detectMax:
- [ : eachVersionInfo | eachVersionInfo versionNumber ])
- ifNil: [ 0 ]
- ifNotNil:
- [ : highestNumbered | highestNumbered versionNumber ] ] ].
- counter := counter + 1.
- ^ branch , '-' , Utilities authorInitials , '.' , counter asString!

Item was changed:
----- Method: MCWorkingCopy>>uniqueVersionName (in category 'private') -----
uniqueVersionName
|versionName|
- counter := nil.
[versionName := self nextVersionName.
+ (self repositoryGroup includesVersionNamed: versionName) or: [ ancestry hasAncestorNamed: versionName ]] whileTrue.
- self repositoryGroup includesVersionNamed: versionName] whileTrue.
^ versionName!




cbc
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

cbc
In reply to this post by Nicolas Cellier
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 <[hidden email]> 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 <[hidden email]> a écrit :
HI Eliot,

> > On Feb 13, 2019, at 7:13 PM, Chris Muller <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Bert Freudenberg
-1

- Bert - 


On Thu, Feb 14, 2019 at 10:12 AM Chris Cunningham <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> a écrit :
HI Eliot,

> > On Feb 13, 2019, at 7:13 PM, Chris Muller <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Eliot Miranda-2
In reply to this post by Nicolas Cellier


On Feb 14, 2019, at 1:07 AM, Nicolas Cellier <[hidden email]> wrote:

Hi Chris,
i don't like this change because it looses a very important thing: READABILITY

+1.  And memorability; impossible to remember these accurately.  And writability, for the same reason.


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 <[hidden email]> a écrit :
HI Eliot,

> > On Feb 13, 2019, at 7:13 PM, Chris Muller <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Chris Muller-3
In reply to this post by Bert Freudenberg
Wow, please relax guys, this was just to invite an exercise for us to
open our minds and have a "thought experiment" about a crazy idea.  I
haven't had time myself to digest all the implications of the idea
well enough to have developed any "advocacy" for it, this hurricane of
abhorrence and vehement resistance is unnecessary.  :)  Some of these
responses indicate to me that you may not have thought it all the way
through either, and I'd like to respond to some of them, since I seem
to be the only one actually open to the idea.

Nicolas wrote:
> i don't like this change because it looses a very important thing: READABILITY

I *feel* the same way you guys do about the readability, even though I
can't put my finger on what use-case needs to care about readability.

The tools put everything where it needs to be.  I would only ever
cut-and-paste a VersionName never type it, so it's not about typing..
What then?

I sense I may just be feeling a "resistance to change," more than
identifying any practical disadvantage due to readability of the
version number.

AND, the number of digits can be further mitigated in any case...

> 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.

We're dealing with up to four digits today.  If we used
minute-resolution, we would only need to add three more digits for a
total of 7.

7 is only 2 more digits than 5, which you said would work, and if we
would be open-minded to a base-36 number, then we're back down to only
5 alphanumeric digits.

I know, it's not _quite_ as nice, but keep in mind, besides total
elimination of duplicates, we also get a *useful encoding* out of
this, the timestamp of the version!  Chris Cunningham had something to
say about
that:

> 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

Nope, #utcMicroseconds saves the day, since it's the same for
everybody, globally.

Marcel:

> Since this directly affects Squeak's build number...

Not adversely.  It's just a number and its still monotonic.  Okay,
maybe readability again, but again...  in what use-case does that
matter?

> People could never estimate the count of changes between builds/updates again.

I assume you mean count of "versions", since we're pretty bad at
making 1:1 changes:versions.  Neither metric is important to
Monticello, but if you need it for something else (release notes?),
then this helps enable an accurate count by having the DateAndTime
encoded into the name, so just count the number of versions that are
after the date of the last release (which should be a field in the
image).

I don't think there's not even any easy way to do the same today
since, as you said, the version number can only provide an estimate.

> Monotonicity doesn't count as long as you have a tool that can sort out the ancestry.

Monotonicity is needed to identify the proper orphan(s) in the tree
which are the most-recently developed.  There tend to be a lot of
other extra orphans in repositories...

> 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.

Guys, sometimes you have to accept the reality of a "legacy."
Monticello is a distributed code legacy database with thousands upon
thousands of MCZ files distributed on machines all over the world, and
accessed by Squeak images old and new.  Breaking that legacy, while
being "more complex," instead of using leverage afforded by the domain
and staying compatible via a very simple solution, is not only the
wrong thing to do, no one will even ever propose it since, if someone
had that kind of time to invest, they'd build a new system instead.

 - Chris


 - Chris

On Thu, Feb 14, 2019 at 1:17 PM Bert Freudenberg <[hidden email]> wrote:

>
> -1
>
> - Bert -
>
>
> On Thu, Feb 14, 2019 at 10:12 AM Chris Cunningham <[hidden email]> wrote:
>>
>> 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 <[hidden email]> 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 <[hidden email]> a écrit :
>>>>
>>>> HI Eliot,
>>>>
>>>> > > On Feb 13, 2019, at 7:13 PM, Chris Muller <[hidden email]> 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
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Chris Muller-3
> > Monotonicity doesn't count as long as you have a tool that can sort out the ancestry.
>
> Monotonicity is needed to identify the proper orphan(s) in the tree
> which are the most-recently developed.  There tend to be a lot of
> other extra orphans in repositories...

Sorry, not orphans, "leaves."

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Jakob Reschke
In reply to this post by Eliot Miranda-2
Curious that few people in the Git community complain about unmemorable hashes as the commit identifiers. I suppose the difference is in the tools: in Monticello you always see a list of version names, wheras in Git each entry in the log is always accompanied with the headline of the commit message. The hashes are usually shortened to the first seven digits for human consumption. Actually it is the same in Subversion already: you never get a list of the revision numbers alone when you have to select or find some revisions.

Concerning local directory repositories (and maybe the HTTP ones): again in Git and Subversion, hardly anybody ever looks at the illegible internal data structures in the .git and .svn directories or the Subversion repository folder and everybody is perfectly fine with that (and sending patches via email if they must). In ENVY you can use whatever you like as the version names, the true version identifier is a timestamp (and the name of the object being versioned), and all of it is hidden in the repository blob. But in Monticello and especially its "file-based" repositories the version names have been made so prominent that they must meet the additional requirement of looking nice in a directory listing. How unfortunate.

Am Do., 14. Feb. 2019 um 22:40 Uhr schrieb Eliot Miranda <[hidden email]>:


On Feb 14, 2019, at 1:07 AM, Nicolas Cellier <[hidden email]> wrote:

Hi Chris,
i don't like this change because it looses a very important thing: READABILITY

+1.  And memorability; impossible to remember these accurately.  And writability, for the same reason.


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 <[hidden email]> a écrit :
HI Eliot,

> > On Feb 13, 2019, at 7:13 PM, Chris Muller <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Eliot Miranda-2
Hi Jakob,


On Feb 14, 2019, at 2:12 PM, Jakob Reschke <[hidden email]> wrote:

Curious that few people in the Git community complain about unmemorable hashes as the commit identifiers. I suppose the difference is in the tools: in Monticello you always see a list of version names, wheras in Git each entry in the log is always accompanied with the headline of the commit message. The hashes are usually shortened to the first seven digits for human consumption. Actually it is the same in Subversion already: you never get a list of the revision numbers alone when you have to select or find some revisions.

Concerning local directory repositories (and maybe the HTTP ones): again in Git and Subversion, hardly anybody ever looks at the illegible internal data structures in the .git and .svn directories or the Subversion repository folder and everybody is perfectly fine with that (and sending patches via email if they must). In ENVY you can use whatever you like as the version names, the true version identifier is a timestamp (and the name of the object being versioned), and all of it is hidden in the repository blob. But in Monticello and especially its "file-based" repositories the version names have been made so prominent that they must meet the additional requirement of looking nice in a directory listing. How unfortunate.

That’s not the use case.  I think the directory listing is a straw man.  The use cases that I have most often are
- telling someone which version to load or which version contained a specific change.  Being able to say “1234”, which I can remember and repeat accurately, instead of 4163820683965, which I cannot, is a key difference
- writing down in a git commit for generated sources from which MC version a particular set of sources were generated from.  I want that information to be easy to write abc easy to read.



Am Do., 14. Feb. 2019 um 22:40 Uhr schrieb Eliot Miranda <[hidden email]>:


On Feb 14, 2019, at 1:07 AM, Nicolas Cellier <[hidden email]> wrote:

Hi Chris,
i don't like this change because it looses a very important thing: READABILITY

+1.  And memorability; impossible to remember these accurately.  And writability, for the same reason.


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 <[hidden email]> a écrit :
HI Eliot,

> > On Feb 13, 2019, at 7:13 PM, Chris Muller <[hidden email]> 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






Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

David T. Lewis
In reply to this post by Chris Muller-3
On Wed, Feb 13, 2019 at 09:13:17PM -0600, Chris Muller 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?
>

Hi Chris,

I like the idea of having valid version histories, but I'm not sure
that working with the version number is the best approach. Here's my
take on it overall:

I am reminded of Craig's "Name and Identity are Distinct" approach in
Naiad (http://wiki.squeak.org/squeak/5618).

An instance of MCVersionInfo has both a name and an identity. There is
an instance variable for each (#name and #id in class MCVersionInfo),
and they serve different purposes. The name is for human consumption,
and the identity is a UUID for identity. It is probably not a good
idea to conflate the two.

Our file based repositories cheat by assuming that the naming convention
will align with the actual history. This is simple and it works most of
the the time, but not always.

If we want to make this better, then we should invent some new way of
indexing the repositories such that the claimed history matches the
actual (UUID identity based) ancestry.

I do not know how to do this, and I don't know if it is really even
worth the trouble. But I am sure that it can be done, and I expect
that any such solution should be based on #id and not on #name.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-cmm.1550112371873461.mcz

Chris Muller-4
Hi Dave and all,

> > 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?
> >
>
> Hi Chris,
>
> I like the idea of having valid version histories, but I'm not sure
> that working with the version number is the best approach. Here's my
> take on it overall:
>
> I am reminded of Craig's "Name and Identity are Distinct" approach in
> Naiad (http://wiki.squeak.org/squeak/5618).
>
> An instance of MCVersionInfo has both a name and an identity. There is
> an instance variable for each (#name and #id in class MCVersionInfo),
> and they serve different purposes. The name is for human consumption,
> and the identity is a UUID for identity. It is probably not a good
> idea to conflate the two.
>
> Our file based repositories cheat by assuming that the naming convention
> will align with the actual history. This is simple and it works most of
> the the time, but not always.
>
> If we want to make this better, then we should invent some new way of
> indexing the repositories such that the claimed history matches the
> actual (UUID identity based) ancestry.

We're all familiar with the model and understand the limitations of
names.  But the fact is that the Monticello model has names, and it
expects them to be unique for proper operation.  Because of how
pervasive it has spread throughout the Squeak ecosystem, you have to
work within the constraints of that legacy.  It's not enough that
MCFileBasedRepository is expected to work transparently with
MCHttpRepository in the future, it has to remain comatible with past
files and clients, too.

The approach of Monticello-cmm.66240 I just put into the Inbox does
that, whilst addressing the readability concerns that were expressed earlier.

> I do not know how to do this, and I don't know if it is really even
> worth the trouble.

If we have a way to fix it so easily, we should responsibly evaluate
the potential benefit to Monticello and the community.  "Not worth the
trouble" is not a reason, since its already done in
Monticello-cmm.66240 -- all you have to do is say "yes"!    :)

It's not just about inconvenience,but an inelegant flaw in
Monticello's model.  It wants to be "distributed," but it can't handle
the most simple use case of working on two different laptops.

> But I am sure that it can be done, and I expect
> that any such solution should be based on #id and not on #name.

No, this is the only solution that maintains Monticellos distribution
AND compatibility with the existing legacy.

 - Chris




 - Chris

12