The Inbox: Monticello-cmm.155011237187346
Locked
12
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
Re: The Inbox: Monticello-cmm.155011237187346
12
 
|
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! |
Re: The Inbox: Monticello-cmm.155011237187346
|
|
On Wed, Feb 13, 2019 at 6:53 PM <[hidden email]> wrote: Chris Muller uploaded a new version of Monticello to project The Inbox: Whaaaa?!? :-) Shurely shome mishtske. hic.
_,,,^..^,,,_ best, Eliot |
Re: The Inbox: Monticello-cmm.155011237187346
|
|
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 > |
Re: The Inbox: Monticello-cmm.155011237187346
|
|
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 > |
Re: The Inbox: Monticello-cmm.155011237187346
|
|
> 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 >> > |
Re: The Inbox: Monticello-cmm.155011237187346
|
|
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 |
Re: The Inbox: Monticello-cmm.155011237187346
|
|
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, |
Re: The Inbox: Monticello-cmm.155011237187346
|
|
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, |
Re: The Inbox: Monticello-cmm.155011237187346
|
|
In reply to this post by Jakob Reschke
Le jeu. 14 févr. 2019 à 10:06, Jakob Reschke <[hidden email]> a écrit :
exactly! this number is for humans only and 10 significand digits kust does not work.
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.
|
Re: The Inbox: Monticello-cmm.155011237187346
|
|
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 :
|
Re: The Inbox: Monticello-cmm.155011237187346
|
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. Also, Occam's razor: https://en.wikipedia.org/wiki/Occam%27s_razor Or choose one of many other models/mantras/idioms that strive for simplicity. Best, Marcel
|
|
|
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:
|
Re: The Inbox: Monticello-cmm.155011237187346
|
|
-1 - Bert - On Thu, Feb 14, 2019 at 10:12 AM Chris Cunningham <[hidden email]> wrote:
|
Re: The Inbox: Monticello-cmm.155011237187346
|
|
In reply to this post by Nicolas Cellier
|
Re: The Inbox: Monticello-cmm.155011237187346
|
|
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 >>>> >>> >> > |
Re: The Inbox: Monticello-cmm.155011237187346
|
|
> > 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." |
Re: The Inbox: Monticello-cmm.155011237187346
|
|
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]>:
|
Re: The Inbox: Monticello-cmm.155011237187346
|
|
Hi Jakob,
- 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.
|
Re: The Inbox: Monticello-cmm.155011237187346
|
|
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 |
Re: The Inbox: Monticello-cmm.155011237187346
|
|
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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |