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!
On Wed, Feb 13, 2019 at 6:53 PM commits@source.squeak.org 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 repositoryGrouprequiredPackages environment'
instanceVariableNames: 'versionInfo ancestry counterrepositoryGroup 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 nowutcMicroseconds 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!
Nope.
On Wed, Feb 13, 2019 at 8:56 PM Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Feb 13, 2019 at 6:53 PM commits@source.squeak.org 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
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 eliot.miranda@gmail.com wrote:
On Wed, Feb 13, 2019 at 6:53 PM commits@source.squeak.org 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
On Feb 13, 2019, at 7:13 PM, Chris Muller asqueaker@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. 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 eliot.miranda@gmail.com wrote:
On Wed, Feb 13, 2019 at 6:53 PM commits@source.squeak.org 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
HI Eliot,
On Feb 13, 2019, at 7:13 PM, Chris Muller asqueaker@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
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 ma.chris.m@gmail.com geschrieben:
HI Eliot,
On Feb 13, 2019, at 7:13 PM, Chris Muller asqueaker@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-1550030998Whilst 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
Le jeu. 14 févr. 2019 à 10:06, Jakob Reschke forums.jakob@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@gmail.com
geschrieben:
HI Eliot,
On Feb 13, 2019, at 7:13 PM, Chris Muller asqueaker@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-1550030998Whilst 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
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 < nicolas.cellier.aka.nice@gmail.com> a écrit :
Le jeu. 14 févr. 2019 à 10:06, Jakob Reschke forums.jakob@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@gmail.com
geschrieben:
HI Eliot,
On Feb 13, 2019, at 7:13 PM, Chris Muller asqueaker@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-1550030998Whilst 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
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@gmail.com a écrit :
HI Eliot,
On Feb 13, 2019, at 7:13 PM, Chris Muller asqueaker@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-1550030998Whilst 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
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@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@gmail.com a écrit :
HI Eliot,
On Feb 13, 2019, at 7:13 PM, Chris Muller asqueaker@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-1550030998Whilst 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
-1
- Bert -
On Thu, Feb 14, 2019 at 10:12 AM Chris Cunningham cunningham.cb@gmail.com 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 < nicolas.cellier.aka.nice@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@gmail.com a écrit :
HI Eliot,
On Feb 13, 2019, at 7:13 PM, Chris Muller asqueaker@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-1550030998Whilst 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
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 bert@freudenbergs.de wrote:
-1
- Bert -
On Thu, Feb 14, 2019 at 10:12 AM Chris Cunningham cunningham.cb@gmail.com 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 nicolas.cellier.aka.nice@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@gmail.com a écrit :
HI Eliot,
On Feb 13, 2019, at 7:13 PM, Chris Muller asqueaker@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-1550030998Whilst 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
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."
On Feb 14, 2019, at 1:07 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com 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 ma.chris.m@gmail.com a écrit : HI Eliot,
On Feb 13, 2019, at 7:13 PM, Chris Muller asqueaker@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-1550030998Whilst 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
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 < eliot.miranda@gmail.com>:
On Feb 14, 2019, at 1:07 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> 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 ma.chris.m@gmail.com a écrit :
HI Eliot,
On Feb 13, 2019, at 7:13 PM, Chris Muller asqueaker@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-1550030998Whilst 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
Hi Jakob,
On Feb 14, 2019, at 2:12 PM, Jakob Reschke forums.jakob@resfarm.de 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 eliot.miranda@gmail.com:
On Feb 14, 2019, at 1:07 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com 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 ma.chris.m@gmail.com a écrit : HI Eliot,
On Feb 13, 2019, at 7:13 PM, Chris Muller asqueaker@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-1550030998Whilst 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
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
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
Hi all,
I don't understand how Monticello relies on version names to be unique for proper operation? I thought internally it always worked with the UUIDs?
In other words what are simplest possible steps to reproduce the problem (problems?) which is solved by the proposed change?
Bernhard
Am 17.02.2019 um 00:25 schrieb Chris Muller ma.chris.m@gmail.com:
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
Hi Bernhard,
On Tue, Feb 19, 2019 at 9:13 AM Bernhard Pieber bernhard@pieber.com wrote:
Hi all,
I don't understand how Monticello relies on version names to be unique for proper operation? I thought internally it always worked with the UUIDs?
You are right. See Bert's message http://forum.world.st/MC-true-ancestors-false-positive-tp5095206p5095649.htm...
In other words what are simplest possible steps to reproduce the problem (problems?) which is solved by the proposed change?
Jakob posted this: http://forum.world.st/The-Inbox-Monticello-cmm-66240-mcz-tp5095396p5095647.h...
Bernhard
Am 17.02.2019 um 00:25 schrieb Chris Muller ma.chris.m@gmail.com:
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
I don't understand how Monticello relies on version names to be unique for proper operation?
Because MCDirectoryRepository relies on a single directory in your filesystem, which can't store any two version with the same name. Therefore, it currently can't possibly represent a complete representation of the code model once a duplicate happens.
I thought internally it always worked with the UUIDs?
For internal ancestral operations, it does, the names are needed to know which files to access when, say, you request a diff operation.
- Chris
In other words what are simplest possible steps to reproduce the problem (problems?) which is solved by the proposed change?
Bernhard
Am 17.02.2019 um 00:25 schrieb Chris Muller ma.chris.m@gmail.com:
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
On Tue, Feb 19, 2019 at 3:08 PM Chris Muller asqueaker@gmail.com wrote:
I don't understand how Monticello relies on version names to be unique
for proper operation?
Because MCDirectoryRepository relies on a single directory in your filesystem, which can't store any two version with the same name.
It happily stores two versions with the same version name, just not with the same filename. E.g. as mcc and mcd. Or multiple mcd with different bases even.
Therefore, it currently can't possibly represent a complete
representation of the code model once a duplicate happens.
If you think about how file names and version names relate, it actually is not only possible, but trivial:
'Monticello-bf.540.mcz' asMCVersionName = 'Monticello-bf.540(1).mcz' ==> true
'Monticello-bf.540(1).mcz' asMCVersionName versionName ==> 'Monticello-bf.540'
I thought internally it always worked with the UUIDs?
For internal ancestral operations, it does, the names are needed to know which files to access when, say, you request a diff operation.
If I read the code correctly, then all we need to do is upload the second version of 'Monticello-bf.540' as 'Monticello-bf.540(1).mcz' to trunk. Then MC should find both files when looking up the ancestry, it should parse the actual version ID, and use the right one.
- Bert -
- Chris
In other words what are simplest possible steps to reproduce the problem
(problems?) which is solved by the proposed change?
Bernhard
Am 17.02.2019 um 00:25 schrieb Chris Muller ma.chris.m@gmail.com:
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
On Tue, Feb 19, 2019 at 3:27 PM Bert Freudenberg bert@freudenbergs.de wrote:
On Tue, Feb 19, 2019 at 3:08 PM Chris Muller asqueaker@gmail.com wrote:
I don't understand how Monticello relies on version names to be unique
for proper operation?
Because MCDirectoryRepository relies on a single directory in your filesystem, which can't store any two version with the same name.
It happily stores two versions with the same version name, just not with the same filename. E.g. as mcc and mcd. Or multiple mcd with different bases even.
Therefore, it currently can't possibly represent a complete
representation of the code model once a duplicate happens.
If you think about how file names and version names relate, it actually is not only possible, but trivial:
'Monticello-bf.540.mcz' asMCVersionName = 'Monticello-bf.540(1).mcz' ==> true
'Monticello-bf.540(1).mcz' asMCVersionName versionName ==> 'Monticello-bf.540'
I thought internally it always worked with the UUIDs?
For internal ancestral operations, it does, the names are needed to know which files to access when, say, you request a diff operation.
If I read the code correctly, then all we need to do is upload the second version of 'Monticello-bf.540' as 'Monticello-bf.540(1).mcz' to trunk. Then MC should find both files when looking up the ancestry, it should parse the actual version ID, and use the right one.
<3
+1000. KISS
- Bert -
- Chris
In other words what are simplest possible steps to reproduce the
problem (problems?) which is solved by the proposed change?
Bernhard
Am 17.02.2019 um 00:25 schrieb Chris Muller ma.chris.m@gmail.com:
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
On 20.02.2019, at 03:50, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Feb 19, 2019 at 3:27 PM Bert Freudenberg bert@freudenbergs.de wrote: On Tue, Feb 19, 2019 at 3:08 PM Chris Muller asqueaker@gmail.com wrote:
I don't understand how Monticello relies on version names to be unique for proper operation?
Because MCDirectoryRepository relies on a single directory in your filesystem, which can't store any two version with the same name.
It happily stores two versions with the same version name, just not with the same filename. E.g. as mcc and mcd. Or multiple mcd with different bases even.
Therefore, it currently can't possibly represent a complete representation of the code model once a duplicate happens.
If you think about how file names and version names relate, it actually is not only possible, but trivial:
'Monticello-bf.540.mcz' asMCVersionName = 'Monticello-bf.540(1).mcz' ==> true
'Monticello-bf.540(1).mcz' asMCVersionName versionName ==> 'Monticello-bf.540'
I thought internally it always worked with the UUIDs?
For internal ancestral operations, it does, the names are needed to know which files to access when, say, you request a diff operation.
If I read the code correctly, then all we need to do is upload the second version of 'Monticello-bf.540' as 'Monticello-bf.540(1).mcz' to trunk. Then MC should find both files when looking up the ancestry, it should parse the actual version ID, and use the right one.
<3
+1000. KISS
That's not even hacky. I like it!
Best regards -Tobias
Bert -
Chris
In other words what are simplest possible steps to reproduce the problem (problems?) which is solved by the proposed change?
Bernhard
Am 17.02.2019 um 00:25 schrieb Chris Muller ma.chris.m@gmail.com:
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
-- _,,,^..^,,,_ best, Eliot
For internal ancestral operations, it does, the names are needed to know which files to access when, say, you request a diff operation.
If I read the code correctly, then all we need to do is upload the second version of 'Monticello-bf.540' as 'Monticello-bf.540(1).mcz' to trunk. Then MC should find both files when looking up the ancestry, it should parse the actual version ID, and use the right one.
Yo! You're right!!
'Monticello-bf.540' asMCVersionName = 'Monticello-bf.540(1).mcz' asMCVersionName "true"
Oh my, what a rabbit-hole of a discussion we had if, all along, all we had to do was rename the file! I'm glad we ultimately identified the fix (which was right in front of us all along, lol!) and even more delighted that we'll be able to make our repositories whole in spite of existing duplicates!
Thanks Bert and all!
- Chris
Yes, this solution is amazingly simple. But it took a lot of discussion and analysis to find it!
--Hannes
On 2/20/19, Chris Muller asqueaker@gmail.com wrote:
For internal ancestral operations, it does, the names are needed to know which files to access when, say, you request a diff operation.
If I read the code correctly, then all we need to do is upload the second version of 'Monticello-bf.540' as 'Monticello-bf.540(1).mcz' to trunk. Then MC should find both files when looking up the ancestry, it should parse the actual version ID, and use the right one.
Yo! You're right!!
'Monticello-bf.540' asMCVersionName = 'Monticello-bf.540(1).mcz'asMCVersionName "true"
Oh my, what a rabbit-hole of a discussion we had if, all along, all we had to do was rename the file! I'm glad we ultimately identified the fix (which was right in front of us all along, lol!) and even more delighted that we'll be able to make our repositories whole in spite of existing duplicates!
Thanks Bert and all!
- Chris
Yes, this solution is amazingly simple. It is interesting that it can take a lot of discussion and analysis to find something like this!
--Hannes
On 2/20/19, Chris Muller asqueaker@gmail.com wrote:
For internal ancestral operations, it does, the names are needed to know which files to access when, say, you request a diff operation.
If I read the code correctly, then all we need to do is upload the second version of 'Monticello-bf.540' as 'Monticello-bf.540(1).mcz' to trunk. Then MC should find both files when looking up the ancestry, it should parse the actual version ID, and use the right one.
Yo! You're right!!
'Monticello-bf.540' asMCVersionName = 'Monticello-bf.540(1).mcz'asMCVersionName "true"
Oh my, what a rabbit-hole of a discussion we had if, all along, all we had to do was rename the file! I'm glad we ultimately identified the fix (which was right in front of us all along, lol!) and even more delighted that we'll be able to make our repositories whole in spite of existing duplicates!
Thanks Bert and all!
- Chris
Thank you very much Bert!
Did you got it from the reading code, or from prior knowledge? Or a mix of the two (prior knowledge that it never was a problem)?
One thing is sure, you did not learn this via class comments ;)
Le jeu. 21 févr. 2019 à 18:21, H. Hirzel hannes.hirzel@gmail.com a écrit :
Yes, this solution is amazingly simple. It is interesting that it can take a lot of discussion and analysis to find something like this!
--Hannes
On 2/20/19, Chris Muller asqueaker@gmail.com wrote:
For internal ancestral operations, it does, the names are needed to know which files to access when, say, you request a diff operation.
If I read the code correctly, then all we need to do is upload the
second
version of 'Monticello-bf.540' as 'Monticello-bf.540(1).mcz' to trunk. Then MC should find both files when looking up the ancestry, it should parse the actual version ID, and use the right one.
Yo! You're right!!
'Monticello-bf.540' asMCVersionName = 'Monticello-bf.540(1).mcz'asMCVersionName "true"
Oh my, what a rabbit-hole of a discussion we had if, all along, all we had to do was rename the file! I'm glad we ultimately identified the fix (which was right in front of us all along, lol!) and even more delighted that we'll be able to make our repositories whole in spite of existing duplicates!
Thanks Bert and all!
- Chris
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.
Also, Occam's razor: https://en.wikipedia.org/wiki/Occam%27s_razor [https://en.wikipedia.org/wiki/Occam%27s_razor]
Or choose one of many other models/mantras/idioms that strive for simplicity.
Best, Marcel Am 14.02.2019 03:53:27 schrieb commits@source.squeak.org commits@source.squeak.org: 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!
squeak-dev@lists.squeakfoundation.org
-
Bernhard Pieber -
Bert Freudenberg -
Chris Cunningham -
Chris Muller -
Chris Muller -
commits＠source.squeak.org -
David T. Lewis -
Eliot Miranda -
H. Hirzel -
Jakob Reschke -
Marcel Taeumel -
Nicolas Cellier -
Tobias Pape