The Inbox: Monticello-cmm.66240.mcz

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

The Inbox: Monticello-cmm.66240.mcz

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

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

Name: Monticello-cmm.66240
Author: cmm
Time: 16 February 2019, 4:49:51.685281 pm
UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
Ancestors: Monticello-eem.684

Monticello only requires monotonicity and uniqueness for its version numbers, not consecutiveness.  When saving a new package, generate a unique, 6-digit versionNumber.  Beginning approximately  2020-11-25T10:40:00+00:00, a 7th digit will appear -- no more than a local phone number -- which will be good until year 2038.

=============== Diff against Monticello-eem.684 ===============

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

Item was added:
+ ----- Method: MCVersionName class>>newVersionNameFor: (in category 'utilities') -----
+ newVersionNameFor: branchName
+ ^ branchName, '-' , Utilities authorInitials , '.' , self newVersionNumberString!

Item was added:
+ ----- Method: MCVersionName class>>newVersionNumberString (in category 'utilities') -----
+ newVersionNumberString
+ "Answer a unique version number for use in generating the versionNumber portion of my name."
+ ^ self versionNumberFor: DateAndTime now!

Item was added:
+ ----- Method: MCVersionName class>>versionNumberFor: (in category 'private') -----
+ versionNumberFor: aDateAndTime
+ "Answer a unique version number for use in generating the versionNumber portion of my name."
+ | epoch |
+ epoch := '2019-01-01T00:00:00+00:00' asDateAndTime.
+ ^ (aDateAndTime - epoch) days * 24 * 60!

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 ].
+ ^ MCVersionName newVersionNameFor: branch!
- branch := oldName packageAndBranchName.
- counter ifNil:
- [ counter := (ancestry ancestors detectMax:
- [ : eachVersionInfo | eachVersionInfo versionNumber ])
- ifNil: [ 0 ]
- ifNotNil:
- [ : highestNumbered | highestNumbered versionNumber ] ] ].
- counter := counter + 1.
- ^ branch , '-' , Utilities authorInitials , '.' , counter asString!

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


Reply | Threaded
Open this post in threaded view
|

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

Chris Muller-3
Hi all,

This version is intended to alleviate our concerns about readability
by making the number no longer than someone's local phone number.

Best,
  Chris




On Sat, Feb 16, 2019 at 4:49 PM <[hidden email]> wrote:

>
> Chris Muller uploaded a new version of Monticello to project The Inbox:
> http://source.squeak.org/inbox/Monticello-cmm.66240.mcz
>
> ==================== Summary ====================
>
> Name: Monticello-cmm.66240
> Author: cmm
> Time: 16 February 2019, 4:49:51.685281 pm
> UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
> Ancestors: Monticello-eem.684
>
> Monticello only requires monotonicity and uniqueness for its version numbers, not consecutiveness.  When saving a new package, generate a unique, 6-digit versionNumber.  Beginning approximately  2020-11-25T10:40:00+00:00, a 7th digit will appear -- no more than a local phone number -- which will be good until year 2038.
>
> =============== Diff against Monticello-eem.684 ===============
>
> Item was added:
> + ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry') -----
> + hasAncestorNamed: aString
> +       self allAncestorsDo:
> +               [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].
> +       ^ false!
>
> Item was added:
> + ----- Method: MCVersionName class>>newVersionNameFor: (in category 'utilities') -----
> + newVersionNameFor: branchName
> +       ^ branchName, '-' , Utilities authorInitials , '.' , self newVersionNumberString!
>
> Item was added:
> + ----- Method: MCVersionName class>>newVersionNumberString (in category 'utilities') -----
> + newVersionNumberString
> +       "Answer a unique version number for use in generating the versionNumber portion of my name."
> +       ^ self versionNumberFor: DateAndTime now!
>
> Item was added:
> + ----- Method: MCVersionName class>>versionNumberFor: (in category 'private') -----
> + versionNumberFor: aDateAndTime
> +       "Answer a unique version number for use in generating the versionNumber portion of my name."
> +       | epoch |
> +       epoch := '2019-01-01T00:00:00+00:00' asDateAndTime.
> +       ^ (aDateAndTime - epoch) days * 24 * 60!
>
> 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 ].
> +       ^ MCVersionName newVersionNameFor: branch!
> -                       branch := oldName packageAndBranchName.
> -                       counter ifNil:
> -                               [ counter := (ancestry ancestors detectMax:
> -                                       [ : eachVersionInfo | eachVersionInfo versionNumber ])
> -                                       ifNil: [ 0 ]
> -                                       ifNotNil:
> -                                               [ : highestNumbered | highestNumbered versionNumber ] ] ].
> -       counter := counter + 1.
> -       ^ branch , '-' , Utilities authorInitials , '.' , counter asString!
>
> Item was changed:
>   ----- Method: MCWorkingCopy>>uniqueVersionName (in category 'private') -----
>   uniqueVersionName
>         |versionName|
> -       counter := nil.
>         [versionName := self nextVersionName.
> +       (self repositoryGroup includesVersionNamed: versionName) or: [ ancestry hasAncestorNamed: versionName ]] whileTrue.
> -       self repositoryGroup includesVersionNamed: versionName] whileTrue.
>         ^ versionName!
>
>

Reply | Threaded
Open this post in threaded view
|

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

Levente Uzonyi
On Sat, 16 Feb 2019, Chris Muller wrote:

> Hi all,
>
> This version is intended to alleviate our concerns about readability
> by making the number no longer than someone's local phone number.

I still don't like this idea. Why?
- while single version numbers are not too large, the system version
number would still be 7 digits long
- the version number would lose information about the number of commits of
the given package. You may argue that it's not exact, but it still gives a
good estimate.
- the change is focused too much on the Trunk, while Monticello is used in
other places too
- it solves a problem that happens way too infrequently (different
packages with the same name)
- you can't commit the same package twice within a minute, which is a
something you do when you want to split multiple changes up into different
commits

Levente

>
> Best,
>  Chris
>
>
>
>
> On Sat, Feb 16, 2019 at 4:49 PM <[hidden email]> wrote:
>>
>> Chris Muller uploaded a new version of Monticello to project The Inbox:
>> http://source.squeak.org/inbox/Monticello-cmm.66240.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Monticello-cmm.66240
>> Author: cmm
>> Time: 16 February 2019, 4:49:51.685281 pm
>> UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
>> Ancestors: Monticello-eem.684
>>
>> Monticello only requires monotonicity and uniqueness for its version numbers, not consecutiveness.  When saving a new package, generate a unique, 6-digit versionNumber.  Beginning approximately  2020-11-25T10:40:00+00:00, a 7th digit will appear -- no more than a local phone number -- which will be good until year 2038.
>>
>> =============== Diff against Monticello-eem.684 ===============
>>
>> Item was added:
>> + ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry') -----
>> + hasAncestorNamed: aString
>> +       self allAncestorsDo:
>> +               [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].
>> +       ^ false!
>>
>> Item was added:
>> + ----- Method: MCVersionName class>>newVersionNameFor: (in category 'utilities') -----
>> + newVersionNameFor: branchName
>> +       ^ branchName, '-' , Utilities authorInitials , '.' , self newVersionNumberString!
>>
>> Item was added:
>> + ----- Method: MCVersionName class>>newVersionNumberString (in category 'utilities') -----
>> + newVersionNumberString
>> +       "Answer a unique version number for use in generating the versionNumber portion of my name."
>> +       ^ self versionNumberFor: DateAndTime now!
>>
>> Item was added:
>> + ----- Method: MCVersionName class>>versionNumberFor: (in category 'private') -----
>> + versionNumberFor: aDateAndTime
>> +       "Answer a unique version number for use in generating the versionNumber portion of my name."
>> +       | epoch |
>> +       epoch := '2019-01-01T00:00:00+00:00' asDateAndTime.
>> +       ^ (aDateAndTime - epoch) days * 24 * 60!
>>
>> 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 ].
>> +       ^ MCVersionName newVersionNameFor: branch!
>> -                       branch := oldName packageAndBranchName.
>> -                       counter ifNil:
>> -                               [ counter := (ancestry ancestors detectMax:
>> -                                       [ : eachVersionInfo | eachVersionInfo versionNumber ])
>> -                                       ifNil: [ 0 ]
>> -                                       ifNotNil:
>> -                                               [ : highestNumbered | highestNumbered versionNumber ] ] ].
>> -       counter := counter + 1.
>> -       ^ branch , '-' , Utilities authorInitials , '.' , counter asString!
>>
>> Item was changed:
>>   ----- Method: MCWorkingCopy>>uniqueVersionName (in category 'private') -----
>>   uniqueVersionName
>>         |versionName|
>> -       counter := nil.
>>         [versionName := self nextVersionName.
>> +       (self repositoryGroup includesVersionNamed: versionName) or: [ ancestry hasAncestorNamed: versionName ]] whileTrue.
>> -       self repositoryGroup includesVersionNamed: versionName] whileTrue.
>>         ^ versionName!
>>
>>

Reply | Threaded
Open this post in threaded view
|

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

Chris Muller-3
Hi Levente,

> > This version is intended to alleviate our concerns about readability
> > by making the number no longer than someone's local phone number.
>
> I still don't like this idea. Why?
> - while single version numbers are not too large, the system version
> number would still be 7 digits long

You mean, instead of 5?

> - the version number would lose information about the number of commits of
> the given package. You may argue that it's not exact, but it still gives a
> good estimate.

This is an easy number to calculate when the file is open and include
in header descrption of a VersionInfo...  For example:

Name: Monticello-cmm.66240
Author: cmm
Time: 16 February 2019, 4:49:51.685281 pm
UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
Ancestors (684): Monticello-eem.684

> - the change is focused too much on the Trunk, while Monticello is used in
> other places too

I don't understand this.  This is about Monticello's model, it has
nothing to do with trunk.

> - it solves a problem that happens way too infrequently (different
> packages with the same name)

It's actually not.  Working in Squeak on two separate laptops (i.e.,
home vs. work) is very common, but incredibly onerous because it
*frequently* results in duplicate package names.

This is more than "solving a problem",  it enables a new power of
simultaneous streams of development on the same packages in different
images -- with no danger of duplicates.

Moreover, it's an elegant way for Monticello to realize its goal of
providing a distributed code model.

> - you can't commit the same package twice within a minute, which is a
> something you do when you want to split multiple changes up into different
> commits

Of course you can.  This is just the default generated name, the user
or system can increment the number as needed.

 - Chris

Reply | Threaded
Open this post in threaded view
|

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

Tobias Pape
In reply to this post by commits-2
I do not understand what problem this is trying to solve in the first place.

-1

Best regards
        -Tobias

> On 16.02.2019, at 23:49, [hidden email] wrote:
>
> Chris Muller uploaded a new version of Monticello to project The Inbox:
> http://source.squeak.org/inbox/Monticello-cmm.66240.mcz
>
> ==================== Summary ====================
>
> Name: Monticello-cmm.66240
> Author: cmm
> Time: 16 February 2019, 4:49:51.685281 pm
> UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
> Ancestors: Monticello-eem.684
>
> Monticello only requires monotonicity and uniqueness for its version numbers, not consecutiveness.  When saving a new package, generate a unique, 6-digit versionNumber.  Beginning approximately  2020-11-25T10:40:00+00:00, a 7th digit will appear -- no more than a local phone number -- which will be good until year 2038.
>
> =============== Diff against Monticello-eem.684 ===============
>
> Item was added:
> + ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry') -----
> + hasAncestorNamed: aString
> + self allAncestorsDo:
> + [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].
> + ^ false!
>
> Item was added:
> + ----- Method: MCVersionName class>>newVersionNameFor: (in category 'utilities') -----
> + newVersionNameFor: branchName
> + ^ branchName, '-' , Utilities authorInitials , '.' , self newVersionNumberString!
>
> Item was added:
> + ----- Method: MCVersionName class>>newVersionNumberString (in category 'utilities') -----
> + newVersionNumberString
> + "Answer a unique version number for use in generating the versionNumber portion of my name."
> + ^ self versionNumberFor: DateAndTime now!
>
> Item was added:
> + ----- Method: MCVersionName class>>versionNumberFor: (in category 'private') -----
> + versionNumberFor: aDateAndTime
> + "Answer a unique version number for use in generating the versionNumber portion of my name."
> + | epoch |
> + epoch := '2019-01-01T00:00:00+00:00' asDateAndTime.
> + ^ (aDateAndTime - epoch) days * 24 * 60!
>
> 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 ].
> + ^ MCVersionName newVersionNameFor: branch!
> - branch := oldName packageAndBranchName.
> - counter ifNil:
> - [ counter := (ancestry ancestors detectMax:
> - [ : eachVersionInfo | eachVersionInfo versionNumber ])
> - ifNil: [ 0 ]
> - ifNotNil:
> - [ : highestNumbered | highestNumbered versionNumber ] ] ].
> - counter := counter + 1.
> - ^ branch , '-' , Utilities authorInitials , '.' , counter asString!
>
> Item was changed:
>  ----- Method: MCWorkingCopy>>uniqueVersionName (in category 'private') -----
>  uniqueVersionName
>   |versionName|
> - counter := nil.
>   [versionName := self nextVersionName.
> + (self repositoryGroup includesVersionNamed: versionName) or: [ ancestry hasAncestorNamed: versionName ]] whileTrue.
> - self repositoryGroup includesVersionNamed: versionName] whileTrue.
>   ^ versionName!
>
>


Reply | Threaded
Open this post in threaded view
|

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

Levente Uzonyi
In reply to this post by Chris Muller-3
On Sat, 16 Feb 2019, Chris Muller wrote:

> Hi Levente,
>
>> > This version is intended to alleviate our concerns about readability
>> > by making the number no longer than someone's local phone number.
>>
>> I still don't like this idea. Why?
>> - while single version numbers are not too large, the system version
>> number would still be 7 digits long
>
> You mean, instead of 5?

Yes, 5 is about the length of the longest sequence of digits one will
recognize and remember in one shot (it's still easy to miss though).
7 would be too long and too error prone: Is it 1342578 or 1345278? Hard to
tell without looking at those numbers thoroughly, isn't it?

>
>> - the version number would lose information about the number of commits of
>> the given package. You may argue that it's not exact, but it still gives a
>> good estimate.
>
> This is an easy number to calculate when the file is open and include
> in header descrption of a VersionInfo...  For example:

Yes. The problem is that the number would not exists outside the image.
When you only have a file on your disk, that information is not available.

>
> Name: Monticello-cmm.66240
> Author: cmm
> Time: 16 February 2019, 4:49:51.685281 pm
> UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
> Ancestors (684): Monticello-eem.684
>
>> - the change is focused too much on the Trunk, while Monticello is used in
>> other places too
>
> I don't understand this.  This is about Monticello's model, it has
> nothing to do with trunk.

The problem you're trying to solve (if I understand that correctly) has
only ever happened in the Trunk, and even there it only happened twice so
far. Anything smaller scale than the Trunk, it is very unlikely to face
this problem.

>
>> - it solves a problem that happens way too infrequently (different
>> packages with the same name)
>
> It's actually not.  Working in Squeak on two separate laptops (i.e.,
> home vs. work) is very common, but incredibly onerous because it
> *frequently* results in duplicate package names.

Right, but you'll notice it as soon as you try to commit it into your
repository. Outside the Trunk, it is very unlikely to have packages merged
into your repository before being commited there.

>
> This is more than "solving a problem",  it enables a new power of
> simultaneous streams of development on the same packages in different
> images -- with no danger of duplicates.
>
> Moreover, it's an elegant way for Monticello to realize its goal of
> providing a distributed code model.

Yes, but if I were to solve this problem, I would just extend the naming
scheme:
Instead of Monticello-cmm.684.mcz, it may as well be
Monticello-cmm.684.435c7c.mcz, which would preserve the version number but
extend the name with the first few digits of the UUID (which is actually
not so good, because of how UUID works, and using e.g. the SHA256 has of the
source file would be superior, but that would require further MC changes).

>
>> - you can't commit the same package twice within a minute, which is a
>> something you do when you want to split multiple changes up into different
>> commits
>
> Of course you can.  This is just the default generated name, the user
> or system can increment the number as needed.

So, this is something the suggested change doesn't support yet, isn't it?

Levente

>
> - Chris

Reply | Threaded
Open this post in threaded view
|

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

Chris Muller-3
> > You mean, instead of 5?
>
> Yes, 5 is about the length of the longest sequence of digits one will
> recognize and remember in one shot (it's still easy to miss though).
> 7 would be too long and too error prone: Is it 1342578 or 1345278? Hard to
> tell without looking at those numbers thoroughly, isn't it?

That's fair.  However, you could easily derive the same 5-digit
version of this number by the sum of the #numberOfAncestors count.
How it's done doesn't really concern Monticello.

I'm really curious how you're using this number, I almost never pay
that number any attention whatsoever.  Obviously, you have a human in
the loop, and it sounds like there's something manual about it..

> >> - the version number would lose information about the number of commits of
> >> the given package. You may argue that it's not exact, but it still gives a
> >> good estimate.
> >
> > This is an easy number to calculate when the file is open and include
> > in header descrption of a VersionInfo...  For example:
>
> Yes. The problem is that the number would not exists outside the image.
> When you only have a file on your disk, that information is not available.

Heh, you keep raising your "requirements" to calculate these obscure
metrics, it starts to feel like a game.  :)  Okay, assuming you have a
complete repository, how about:

    ls -1 PackageName-*.mc? | wc -l

Without knowing what use-case needs this metric under such conditions,
it's hard to know what the best solution would be...

Keep in mind, with my proposal you would be able to "eyeball" a
different metric that could be useful -- the age of the version..

> > Name: Monticello-cmm.66240
> > Author: cmm
> > Time: 16 February 2019, 4:49:51.685281 pm
> > UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
> > Ancestors (684): Monticello-eem.684
> >
> >> - it solves a problem that happens way too infrequently (different
> >> packages with the same name)
> >
> > It's actually not.  Working in Squeak on two separate laptops (i.e.,
> > home vs. work) is very common, but incredibly onerous because it
> > *frequently* results in duplicate package names.
>
> Right, but you'll notice it as soon as you try to commit it into your
> repository.

By then it's too late!  Please tell me what you would do in that
scenario, when you went to merge and found a couple of name conflicts
buried 4 or 5 deep in the ancestry of both chains?  Ignore it and
leave holes in your repository?  Or rewrite history?

It only takes this scenario to happen once to understand the level of
hassle or compromise it forces one into.

> > This is more than "solving a problem",  it enables a new power of
> > simultaneous streams of development on the same packages in different
> > images -- with no danger of duplicates.
> >
> > Moreover, it's an elegant way for Monticello to realize its goal of
> > providing a distributed code model.
>
> Yes, but if I were to solve this problem, I would just extend the naming
> scheme:
> Instead of Monticello-cmm.684.mcz, it may as well be
> Monticello-cmm.684.435c7c.mcz, which would preserve the version number but
> extend the name with the first few digits of the UUID (which is actually
> not so good, because of how UUID works, and using e.g. the SHA256 has of the
> source file would be superior, but that would require further MC changes).

Hey, I really appreciate the alternate suggestion!  I'm interested in
a _solution_ more than a particular implementation.  The suggestion
above sounds like it solves duplicates, but doesn't offer the extra
bonus field encoded into the name, and it also introduces a
more-complex name format that doesn't jibe with the legacy of files
out there.  We would want to make sure older Squeak images could
correctly access repositories with those name formats, and that no one
minded seeing a uuid inserted into their names.

> >> - you can't commit the same package twice within a minute, which is a
> >> something you do when you want to split multiple changes up into different
> >> commits
> >
> > Of course you can.  This is just the default generated name, the user
> > or system can increment the number as needed.
>
> So, this is something the suggested change doesn't support yet, isn't it?

It supports the user entering whatever name they want.
____

Maybe it would be best if I tried this out in one of my own packages.
I would just need to tweak MC's code to support it whenever it finds a
package number > 66000, otherwise stay with the old consecutive..


 - Chris

Reply | Threaded
Open this post in threaded view
|

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

Nicolas Cellier
Hi Chris,
Consciously or not, we use these numbers a lot.
For example, when inspecting the versions in inbox, it's very easy to remember and identify the versions, then select them in source.squeak.org web interface then move to treated inbox.
A version in inbox is like pull/merge requests in github/gitlab: it has short number and that helps quick identification, selection in a list, ...

Le dim. 17 févr. 2019 à 21:32, Chris Muller <[hidden email]> a écrit :
> > You mean, instead of 5?
>
> Yes, 5 is about the length of the longest sequence of digits one will
> recognize and remember in one shot (it's still easy to miss though).
> 7 would be too long and too error prone: Is it 1342578 or 1345278? Hard to
> tell without looking at those numbers thoroughly, isn't it?

That's fair.  However, you could easily derive the same 5-digit
version of this number by the sum of the #numberOfAncestors count.
How it's done doesn't really concern Monticello.

I'm really curious how you're using this number, I almost never pay
that number any attention whatsoever.  Obviously, you have a human in
the loop, and it sounds like there's something manual about it..

> >> - the version number would lose information about the number of commits of
> >> the given package. You may argue that it's not exact, but it still gives a
> >> good estimate.
> >
> > This is an easy number to calculate when the file is open and include
> > in header descrption of a VersionInfo...  For example:
>
> Yes. The problem is that the number would not exists outside the image.
> When you only have a file on your disk, that information is not available.

Heh, you keep raising your "requirements" to calculate these obscure
metrics, it starts to feel like a game.  :)  Okay, assuming you have a
complete repository, how about:

    ls -1 PackageName-*.mc? | wc -l

Without knowing what use-case needs this metric under such conditions,
it's hard to know what the best solution would be...

Keep in mind, with my proposal you would be able to "eyeball" a
different metric that could be useful -- the age of the version..

> > Name: Monticello-cmm.66240
> > Author: cmm
> > Time: 16 February 2019, 4:49:51.685281 pm
> > UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
> > Ancestors (684): Monticello-eem.684
> >
> >> - it solves a problem that happens way too infrequently (different
> >> packages with the same name)
> >
> > It's actually not.  Working in Squeak on two separate laptops (i.e.,
> > home vs. work) is very common, but incredibly onerous because it
> > *frequently* results in duplicate package names.
>
> Right, but you'll notice it as soon as you try to commit it into your
> repository.

By then it's too late!  Please tell me what you would do in that
scenario, when you went to merge and found a couple of name conflicts
buried 4 or 5 deep in the ancestry of both chains?  Ignore it and
leave holes in your repository?  Or rewrite history?

It only takes this scenario to happen once to understand the level of
hassle or compromise it forces one into.

> > This is more than "solving a problem",  it enables a new power of
> > simultaneous streams of development on the same packages in different
> > images -- with no danger of duplicates.
> >
> > Moreover, it's an elegant way for Monticello to realize its goal of
> > providing a distributed code model.
>
> Yes, but if I were to solve this problem, I would just extend the naming
> scheme:
> Instead of Monticello-cmm.684.mcz, it may as well be
> Monticello-cmm.684.435c7c.mcz, which would preserve the version number but
> extend the name with the first few digits of the UUID (which is actually
> not so good, because of how UUID works, and using e.g. the SHA256 has of the
> source file would be superior, but that would require further MC changes).

Hey, I really appreciate the alternate suggestion!  I'm interested in
a _solution_ more than a particular implementation.  The suggestion
above sounds like it solves duplicates, but doesn't offer the extra
bonus field encoded into the name, and it also introduces a
more-complex name format that doesn't jibe with the legacy of files
out there.  We would want to make sure older Squeak images could
correctly access repositories with those name formats, and that no one
minded seeing a uuid inserted into their names.

> >> - you can't commit the same package twice within a minute, which is a
> >> something you do when you want to split multiple changes up into different
> >> commits
> >
> > Of course you can.  This is just the default generated name, the user
> > or system can increment the number as needed.
>
> So, this is something the suggested change doesn't support yet, isn't it?

It supports the user entering whatever name they want.
____

Maybe it would be best if I tried this out in one of my own packages.
I would just need to tweak MC's code to support it whenever it finds a
package number > 66000, otherwise stay with the old consecutive..


 - Chris



Reply | Threaded
Open this post in threaded view
|

Monticello and version names and numbers (was: The Inbox: Monticello-cmm.66240.mcz)

Jakob Reschke
Hi,

Am So., 17. Feb. 2019 um 22:53 Uhr schrieb Nicolas Cellier <[hidden email]>:
Hi Chris,
Consciously or not, we use these numbers a lot.
For example, when inspecting the versions in inbox, it's very easy to remember and identify the versions, then select them in source.squeak.org web interface then move to treated inbox.
A version in inbox is like pull/merge requests in github/gitlab: it has short number and that helps quick identification, selection in a list, ...

Sounds like the inbox treating tools also only show the version name and not the commit message, at least not until you select a particular version... is that correct?

When I seek a version anywhere else but in Monticello, I look for the commit message. I don't have to deal with many pull requests, but I am regularly reluctant to remember even the three digits of them. ;-) I always look them up by browsing the pull requests where I see their titles, or I use the helpful issue reference autocompletion of GitHub that displays the titles next to the numbers and allows to search them by typing text. In my opinion, titles and commit messages are far more recognizable than any kind of number or identifier.

I read that one generalized use case is to take the version name to somewhere else for reference (as Nicolas and Eliot wrote). I just re-checked the Monticello repository browser: to copy a version name, you have to select (and download) the version, highlight the name in the text box below and press copy. Might be better to have a "copy version name" command in the pop-up menu of the version list. And a text box in the inbox treating UI where you can paste it... Going to a particular version in the repository browser currently requires you to scroll and look for the version number, or typing its name to filter the list. Both ways really require you to run the number through your mind, and using the filtering is awkward on top because after each keystroke, another version gets selected and downloaded, interrupting your typing. Also, longer numbers with low variance in the most-significant digits would increase that pain. What about a go-to text box above or below the list where you can paste a version name (or UUID in the future?), press enter, and be taken to it, if present? It could even take you to a different package than the one you have selected.

Just to be clear: my point is not to criticize your habits and ways to use the version numbers. But I suspect that the "humanly" requirements imposed on the numbers and version names indicates that there is a lack in the tool chain. Or the design, since you currently have to download a version wholly to get its message and UUID. Improving that might turn out to be better in the long term than sticking with the status quo. And it might solve more problems than just the one Chris is trying to solve here.

How much effort would it be to extend the server side of a Monticello HTTP repository such that it allows to query for the names, UUIDs and message headlines (and cache that information)? Like back in the days before IMAP, when you could opt to just fetch the headers of your emails...

Unfortunately extending the tools does not resolve the compatibility issue with older Squeak images. Or the brevity of the update number, although I am not yet sure whether this one is really worth saving.

Kind regards,
Jakob
 

Le dim. 17 févr. 2019 à 21:32, Chris Muller <[hidden email]> a écrit :
> > You mean, instead of 5?
>
> Yes, 5 is about the length of the longest sequence of digits one will
> recognize and remember in one shot (it's still easy to miss though).
> 7 would be too long and too error prone: Is it 1342578 or 1345278? Hard to
> tell without looking at those numbers thoroughly, isn't it?

That's fair.  However, you could easily derive the same 5-digit
version of this number by the sum of the #numberOfAncestors count.
How it's done doesn't really concern Monticello.

I'm really curious how you're using this number, I almost never pay
that number any attention whatsoever.  Obviously, you have a human in
the loop, and it sounds like there's something manual about it..

> >> - the version number would lose information about the number of commits of
> >> the given package. You may argue that it's not exact, but it still gives a
> >> good estimate.
> >
> > This is an easy number to calculate when the file is open and include
> > in header descrption of a VersionInfo...  For example:
>
> Yes. The problem is that the number would not exists outside the image.
> When you only have a file on your disk, that information is not available.

Heh, you keep raising your "requirements" to calculate these obscure
metrics, it starts to feel like a game.  :)  Okay, assuming you have a
complete repository, how about:

    ls -1 PackageName-*.mc? | wc -l

Without knowing what use-case needs this metric under such conditions,
it's hard to know what the best solution would be...

Keep in mind, with my proposal you would be able to "eyeball" a
different metric that could be useful -- the age of the version..

> > Name: Monticello-cmm.66240
> > Author: cmm
> > Time: 16 February 2019, 4:49:51.685281 pm
> > UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
> > Ancestors (684): Monticello-eem.684
> >
> >> - it solves a problem that happens way too infrequently (different
> >> packages with the same name)
> >
> > It's actually not.  Working in Squeak on two separate laptops (i.e.,
> > home vs. work) is very common, but incredibly onerous because it
> > *frequently* results in duplicate package names.
>
> Right, but you'll notice it as soon as you try to commit it into your
> repository.

By then it's too late!  Please tell me what you would do in that
scenario, when you went to merge and found a couple of name conflicts
buried 4 or 5 deep in the ancestry of both chains?  Ignore it and
leave holes in your repository?  Or rewrite history?

It only takes this scenario to happen once to understand the level of
hassle or compromise it forces one into.

> > This is more than "solving a problem",  it enables a new power of
> > simultaneous streams of development on the same packages in different
> > images -- with no danger of duplicates.
> >
> > Moreover, it's an elegant way for Monticello to realize its goal of
> > providing a distributed code model.
>
> Yes, but if I were to solve this problem, I would just extend the naming
> scheme:
> Instead of Monticello-cmm.684.mcz, it may as well be
> Monticello-cmm.684.435c7c.mcz, which would preserve the version number but
> extend the name with the first few digits of the UUID (which is actually
> not so good, because of how UUID works, and using e.g. the SHA256 has of the
> source file would be superior, but that would require further MC changes).

Hey, I really appreciate the alternate suggestion!  I'm interested in
a _solution_ more than a particular implementation.  The suggestion
above sounds like it solves duplicates, but doesn't offer the extra
bonus field encoded into the name, and it also introduces a
more-complex name format that doesn't jibe with the legacy of files
out there.  We would want to make sure older Squeak images could
correctly access repositories with those name formats, and that no one
minded seeing a uuid inserted into their names.

> >> - you can't commit the same package twice within a minute, which is a
> >> something you do when you want to split multiple changes up into different
> >> commits
> >
> > Of course you can.  This is just the default generated name, the user
> > or system can increment the number as needed.
>
> So, this is something the suggested change doesn't support yet, isn't it?

It supports the user entering whatever name they want.
____

Maybe it would be best if I tried this out in one of my own packages.
I would just need to tweak MC's code to support it whenever it finds a
package number > 66000, otherwise stay with the old consecutive..


 - Chris




cbc
Reply | Threaded
Open this post in threaded view
|

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

cbc
In reply to this post by Nicolas Cellier
Chris is still proposing a max 5 digit version number for a file - reasonable if not ideal

the much longer number they diverged to talking about is the squeak image version number which is used but much less often. that is the sum of all loaded package versions + the hard code number representing older unloaded packages. this would grow much larger. 

On Sun, Feb 17, 2019, 13:52 Nicolas Cellier <[hidden email] wrote:
Hi Chris,
Consciously or not, we use these numbers a lot.
For example, when inspecting the versions in inbox, it's very easy to remember and identify the versions, then select them in source.squeak.org web interface then move to treated inbox.
A version in inbox is like pull/merge requests in github/gitlab: it has short number and that helps quick identification, selection in a list, ...

Le dim. 17 févr. 2019 à 21:32, Chris Muller <[hidden email]> a écrit :
> > You mean, instead of 5?
>
> Yes, 5 is about the length of the longest sequence of digits one will
> recognize and remember in one shot (it's still easy to miss though).
> 7 would be too long and too error prone: Is it 1342578 or 1345278? Hard to
> tell without looking at those numbers thoroughly, isn't it?

That's fair.  However, you could easily derive the same 5-digit
version of this number by the sum of the #numberOfAncestors count.
How it's done doesn't really concern Monticello.

I'm really curious how you're using this number, I almost never pay
that number any attention whatsoever.  Obviously, you have a human in
the loop, and it sounds like there's something manual about it..

> >> - the version number would lose information about the number of commits of
> >> the given package. You may argue that it's not exact, but it still gives a
> >> good estimate.
> >
> > This is an easy number to calculate when the file is open and include
> > in header descrption of a VersionInfo...  For example:
>
> Yes. The problem is that the number would not exists outside the image.
> When you only have a file on your disk, that information is not available.

Heh, you keep raising your "requirements" to calculate these obscure
metrics, it starts to feel like a game.  :)  Okay, assuming you have a
complete repository, how about:

    ls -1 PackageName-*.mc? | wc -l

Without knowing what use-case needs this metric under such conditions,
it's hard to know what the best solution would be...

Keep in mind, with my proposal you would be able to "eyeball" a
different metric that could be useful -- the age of the version..

> > Name: Monticello-cmm.66240
> > Author: cmm
> > Time: 16 February 2019, 4:49:51.685281 pm
> > UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
> > Ancestors (684): Monticello-eem.684
> >
> >> - it solves a problem that happens way too infrequently (different
> >> packages with the same name)
> >
> > It's actually not.  Working in Squeak on two separate laptops (i.e.,
> > home vs. work) is very common, but incredibly onerous because it
> > *frequently* results in duplicate package names.
>
> Right, but you'll notice it as soon as you try to commit it into your
> repository.

By then it's too late!  Please tell me what you would do in that
scenario, when you went to merge and found a couple of name conflicts
buried 4 or 5 deep in the ancestry of both chains?  Ignore it and
leave holes in your repository?  Or rewrite history?

It only takes this scenario to happen once to understand the level of
hassle or compromise it forces one into.

> > This is more than "solving a problem",  it enables a new power of
> > simultaneous streams of development on the same packages in different
> > images -- with no danger of duplicates.
> >
> > Moreover, it's an elegant way for Monticello to realize its goal of
> > providing a distributed code model.
>
> Yes, but if I were to solve this problem, I would just extend the naming
> scheme:
> Instead of Monticello-cmm.684.mcz, it may as well be
> Monticello-cmm.684.435c7c.mcz, which would preserve the version number but
> extend the name with the first few digits of the UUID (which is actually
> not so good, because of how UUID works, and using e.g. the SHA256 has of the
> source file would be superior, but that would require further MC changes).

Hey, I really appreciate the alternate suggestion!  I'm interested in
a _solution_ more than a particular implementation.  The suggestion
above sounds like it solves duplicates, but doesn't offer the extra
bonus field encoded into the name, and it also introduces a
more-complex name format that doesn't jibe with the legacy of files
out there.  We would want to make sure older Squeak images could
correctly access repositories with those name formats, and that no one
minded seeing a uuid inserted into their names.

> >> - you can't commit the same package twice within a minute, which is a
> >> something you do when you want to split multiple changes up into different
> >> commits
> >
> > Of course you can.  This is just the default generated name, the user
> > or system can increment the number as needed.
>
> So, this is something the suggested change doesn't support yet, isn't it?

It supports the user entering whatever name they want.
____

Maybe it would be best if I tried this out in one of my own packages.
I would just need to tweak MC's code to support it whenever it finds a
package number > 66000, otherwise stay with the old consecutive..


 - Chris




Reply | Threaded
Open this post in threaded view
|

Re: Monticello and version names and numbers (was: The Inbox: Monticello-cmm.66240.mcz)

Nicolas Cellier
In reply to this post by Jakob Reschke
Hi Jakob,
All the information (name id commit message) are available in ancestry.
Unfortunately, when browsing a remote repository we only get the names, until we load each individual mcz. This is what is most limiting the possible ui improvment. That's also why we rely a bit more on name than others. Also note that we rarely use branch names and don't have GUI showing the ancestor graph; the ancestry is approximately encoded in version number (fork is a few versions ahead). We can't remove name feature without first adding replacement in servers and that's why we reject Chris proposals: we loose something more important than what we gain.

Changing the model is not that obvious. Each package retains a copy of whole history.
This redundancy confer the robustness of MC to missing ancestors and partial history. Note that Pharo did erase this ancestry in each release, which is really aggressive... you then can't find common ancestors when porting changes!

If we wan't the server to list more than names, either we pass many redundant information, wasting bandpass and response time, or we pass only head information for each mcz, but then loose history chain at each missing mcz. There are a lot of missing mcz (It's equivalent to a squash, except that the ancestry keeps track of intermediate commits).

It means that the server should carry an analysis of available package and ancestry relationship before transmitting these data... Not ideal!


Le lun. 18 févr. 2019 à 00:08, Jakob Reschke <[hidden email]> a écrit :
Hi,

Am So., 17. Feb. 2019 um 22:53 Uhr schrieb Nicolas Cellier <[hidden email]>:
Hi Chris,
Consciously or not, we use these numbers a lot.
For example, when inspecting the versions in inbox, it's very easy to remember and identify the versions, then select them in source.squeak.org web interface then move to treated inbox.
A version in inbox is like pull/merge requests in github/gitlab: it has short number and that helps quick identification, selection in a list, ...

Sounds like the inbox treating tools also only show the version name and not the commit message, at least not until you select a particular version... is that correct?

When I seek a version anywhere else but in Monticello, I look for the commit message. I don't have to deal with many pull requests, but I am regularly reluctant to remember even the three digits of them. ;-) I always look them up by browsing the pull requests where I see their titles, or I use the helpful issue reference autocompletion of GitHub that displays the titles next to the numbers and allows to search them by typing text. In my opinion, titles and commit messages are far more recognizable than any kind of number or identifier.

I read that one generalized use case is to take the version name to somewhere else for reference (as Nicolas and Eliot wrote). I just re-checked the Monticello repository browser: to copy a version name, you have to select (and download) the version, highlight the name in the text box below and press copy. Might be better to have a "copy version name" command in the pop-up menu of the version list. And a text box in the inbox treating UI where you can paste it... Going to a particular version in the repository browser currently requires you to scroll and look for the version number, or typing its name to filter the list. Both ways really require you to run the number through your mind, and using the filtering is awkward on top because after each keystroke, another version gets selected and downloaded, interrupting your typing. Also, longer numbers with low variance in the most-significant digits would increase that pain. What about a go-to text box above or below the list where you can paste a version name (or UUID in the future?), press enter, and be taken to it, if present? It could even take you to a different package than the one you have selected.

Just to be clear: my point is not to criticize your habits and ways to use the version numbers. But I suspect that the "humanly" requirements imposed on the numbers and version names indicates that there is a lack in the tool chain. Or the design, since you currently have to download a version wholly to get its message and UUID. Improving that might turn out to be better in the long term than sticking with the status quo. And it might solve more problems than just the one Chris is trying to solve here.

How much effort would it be to extend the server side of a Monticello HTTP repository such that it allows to query for the names, UUIDs and message headlines (and cache that information)? Like back in the days before IMAP, when you could opt to just fetch the headers of your emails...

Unfortunately extending the tools does not resolve the compatibility issue with older Squeak images. Or the brevity of the update number, although I am not yet sure whether this one is really worth saving.

Kind regards,
Jakob
 

Le dim. 17 févr. 2019 à 21:32, Chris Muller <[hidden email]> a écrit :
> > You mean, instead of 5?
>
> Yes, 5 is about the length of the longest sequence of digits one will
> recognize and remember in one shot (it's still easy to miss though).
> 7 would be too long and too error prone: Is it 1342578 or 1345278? Hard to
> tell without looking at those numbers thoroughly, isn't it?

That's fair.  However, you could easily derive the same 5-digit
version of this number by the sum of the #numberOfAncestors count.
How it's done doesn't really concern Monticello.

I'm really curious how you're using this number, I almost never pay
that number any attention whatsoever.  Obviously, you have a human in
the loop, and it sounds like there's something manual about it..

> >> - the version number would lose information about the number of commits of
> >> the given package. You may argue that it's not exact, but it still gives a
> >> good estimate.
> >
> > This is an easy number to calculate when the file is open and include
> > in header descrption of a VersionInfo...  For example:
>
> Yes. The problem is that the number would not exists outside the image.
> When you only have a file on your disk, that information is not available.

Heh, you keep raising your "requirements" to calculate these obscure
metrics, it starts to feel like a game.  :)  Okay, assuming you have a
complete repository, how about:

    ls -1 PackageName-*.mc? | wc -l

Without knowing what use-case needs this metric under such conditions,
it's hard to know what the best solution would be...

Keep in mind, with my proposal you would be able to "eyeball" a
different metric that could be useful -- the age of the version..

> > Name: Monticello-cmm.66240
> > Author: cmm
> > Time: 16 February 2019, 4:49:51.685281 pm
> > UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
> > Ancestors (684): Monticello-eem.684
> >
> >> - it solves a problem that happens way too infrequently (different
> >> packages with the same name)
> >
> > It's actually not.  Working in Squeak on two separate laptops (i.e.,
> > home vs. work) is very common, but incredibly onerous because it
> > *frequently* results in duplicate package names.
>
> Right, but you'll notice it as soon as you try to commit it into your
> repository.

By then it's too late!  Please tell me what you would do in that
scenario, when you went to merge and found a couple of name conflicts
buried 4 or 5 deep in the ancestry of both chains?  Ignore it and
leave holes in your repository?  Or rewrite history?

It only takes this scenario to happen once to understand the level of
hassle or compromise it forces one into.

> > This is more than "solving a problem",  it enables a new power of
> > simultaneous streams of development on the same packages in different
> > images -- with no danger of duplicates.
> >
> > Moreover, it's an elegant way for Monticello to realize its goal of
> > providing a distributed code model.
>
> Yes, but if I were to solve this problem, I would just extend the naming
> scheme:
> Instead of Monticello-cmm.684.mcz, it may as well be
> Monticello-cmm.684.435c7c.mcz, which would preserve the version number but
> extend the name with the first few digits of the UUID (which is actually
> not so good, because of how UUID works, and using e.g. the SHA256 has of the
> source file would be superior, but that would require further MC changes).

Hey, I really appreciate the alternate suggestion!  I'm interested in
a _solution_ more than a particular implementation.  The suggestion
above sounds like it solves duplicates, but doesn't offer the extra
bonus field encoded into the name, and it also introduces a
more-complex name format that doesn't jibe with the legacy of files
out there.  We would want to make sure older Squeak images could
correctly access repositories with those name formats, and that no one
minded seeing a uuid inserted into their names.

> >> - you can't commit the same package twice within a minute, which is a
> >> something you do when you want to split multiple changes up into different
> >> commits
> >
> > Of course you can.  This is just the default generated name, the user
> > or system can increment the number as needed.
>
> So, this is something the suggested change doesn't support yet, isn't it?

It supports the user entering whatever name they want.
____

Maybe it would be best if I tried this out in one of my own packages.
I would just need to tweak MC's code to support it whenever it finds a
package number > 66000, otherwise stay with the old consecutive..


 - Chris





Reply | Threaded
Open this post in threaded view
|

Re: Monticello and version names and numbers (was: The Inbox: Monticello-cmm.66240.mcz)

Nicolas Cellier
Additional note: if it's just for having reacher lists in ui, we could transmit head information only, that would enable some improvment already...

Le lun. 18 févr. 2019 à 09:50, Nicolas Cellier <[hidden email]> a écrit :
Hi Jakob,
All the information (name id commit message) are available in ancestry.
Unfortunately, when browsing a remote repository we only get the names, until we load each individual mcz. This is what is most limiting the possible ui improvment. That's also why we rely a bit more on name than others. Also note that we rarely use branch names and don't have GUI showing the ancestor graph; the ancestry is approximately encoded in version number (fork is a few versions ahead). We can't remove name feature without first adding replacement in servers and that's why we reject Chris proposals: we loose something more important than what we gain.

Changing the model is not that obvious. Each package retains a copy of whole history.
This redundancy confer the robustness of MC to missing ancestors and partial history. Note that Pharo did erase this ancestry in each release, which is really aggressive... you then can't find common ancestors when porting changes!

If we wan't the server to list more than names, either we pass many redundant information, wasting bandpass and response time, or we pass only head information for each mcz, but then loose history chain at each missing mcz. There are a lot of missing mcz (It's equivalent to a squash, except that the ancestry keeps track of intermediate commits).

It means that the server should carry an analysis of available package and ancestry relationship before transmitting these data... Not ideal!


Le lun. 18 févr. 2019 à 00:08, Jakob Reschke <[hidden email]> a écrit :
Hi,

Am So., 17. Feb. 2019 um 22:53 Uhr schrieb Nicolas Cellier <[hidden email]>:
Hi Chris,
Consciously or not, we use these numbers a lot.
For example, when inspecting the versions in inbox, it's very easy to remember and identify the versions, then select them in source.squeak.org web interface then move to treated inbox.
A version in inbox is like pull/merge requests in github/gitlab: it has short number and that helps quick identification, selection in a list, ...

Sounds like the inbox treating tools also only show the version name and not the commit message, at least not until you select a particular version... is that correct?

When I seek a version anywhere else but in Monticello, I look for the commit message. I don't have to deal with many pull requests, but I am regularly reluctant to remember even the three digits of them. ;-) I always look them up by browsing the pull requests where I see their titles, or I use the helpful issue reference autocompletion of GitHub that displays the titles next to the numbers and allows to search them by typing text. In my opinion, titles and commit messages are far more recognizable than any kind of number or identifier.

I read that one generalized use case is to take the version name to somewhere else for reference (as Nicolas and Eliot wrote). I just re-checked the Monticello repository browser: to copy a version name, you have to select (and download) the version, highlight the name in the text box below and press copy. Might be better to have a "copy version name" command in the pop-up menu of the version list. And a text box in the inbox treating UI where you can paste it... Going to a particular version in the repository browser currently requires you to scroll and look for the version number, or typing its name to filter the list. Both ways really require you to run the number through your mind, and using the filtering is awkward on top because after each keystroke, another version gets selected and downloaded, interrupting your typing. Also, longer numbers with low variance in the most-significant digits would increase that pain. What about a go-to text box above or below the list where you can paste a version name (or UUID in the future?), press enter, and be taken to it, if present? It could even take you to a different package than the one you have selected.

Just to be clear: my point is not to criticize your habits and ways to use the version numbers. But I suspect that the "humanly" requirements imposed on the numbers and version names indicates that there is a lack in the tool chain. Or the design, since you currently have to download a version wholly to get its message and UUID. Improving that might turn out to be better in the long term than sticking with the status quo. And it might solve more problems than just the one Chris is trying to solve here.

How much effort would it be to extend the server side of a Monticello HTTP repository such that it allows to query for the names, UUIDs and message headlines (and cache that information)? Like back in the days before IMAP, when you could opt to just fetch the headers of your emails...

Unfortunately extending the tools does not resolve the compatibility issue with older Squeak images. Or the brevity of the update number, although I am not yet sure whether this one is really worth saving.

Kind regards,
Jakob
 

Le dim. 17 févr. 2019 à 21:32, Chris Muller <[hidden email]> a écrit :
> > You mean, instead of 5?
>
> Yes, 5 is about the length of the longest sequence of digits one will
> recognize and remember in one shot (it's still easy to miss though).
> 7 would be too long and too error prone: Is it 1342578 or 1345278? Hard to
> tell without looking at those numbers thoroughly, isn't it?

That's fair.  However, you could easily derive the same 5-digit
version of this number by the sum of the #numberOfAncestors count.
How it's done doesn't really concern Monticello.

I'm really curious how you're using this number, I almost never pay
that number any attention whatsoever.  Obviously, you have a human in
the loop, and it sounds like there's something manual about it..

> >> - the version number would lose information about the number of commits of
> >> the given package. You may argue that it's not exact, but it still gives a
> >> good estimate.
> >
> > This is an easy number to calculate when the file is open and include
> > in header descrption of a VersionInfo...  For example:
>
> Yes. The problem is that the number would not exists outside the image.
> When you only have a file on your disk, that information is not available.

Heh, you keep raising your "requirements" to calculate these obscure
metrics, it starts to feel like a game.  :)  Okay, assuming you have a
complete repository, how about:

    ls -1 PackageName-*.mc? | wc -l

Without knowing what use-case needs this metric under such conditions,
it's hard to know what the best solution would be...

Keep in mind, with my proposal you would be able to "eyeball" a
different metric that could be useful -- the age of the version..

> > Name: Monticello-cmm.66240
> > Author: cmm
> > Time: 16 February 2019, 4:49:51.685281 pm
> > UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
> > Ancestors (684): Monticello-eem.684
> >
> >> - it solves a problem that happens way too infrequently (different
> >> packages with the same name)
> >
> > It's actually not.  Working in Squeak on two separate laptops (i.e.,
> > home vs. work) is very common, but incredibly onerous because it
> > *frequently* results in duplicate package names.
>
> Right, but you'll notice it as soon as you try to commit it into your
> repository.

By then it's too late!  Please tell me what you would do in that
scenario, when you went to merge and found a couple of name conflicts
buried 4 or 5 deep in the ancestry of both chains?  Ignore it and
leave holes in your repository?  Or rewrite history?

It only takes this scenario to happen once to understand the level of
hassle or compromise it forces one into.

> > This is more than "solving a problem",  it enables a new power of
> > simultaneous streams of development on the same packages in different
> > images -- with no danger of duplicates.
> >
> > Moreover, it's an elegant way for Monticello to realize its goal of
> > providing a distributed code model.
>
> Yes, but if I were to solve this problem, I would just extend the naming
> scheme:
> Instead of Monticello-cmm.684.mcz, it may as well be
> Monticello-cmm.684.435c7c.mcz, which would preserve the version number but
> extend the name with the first few digits of the UUID (which is actually
> not so good, because of how UUID works, and using e.g. the SHA256 has of the
> source file would be superior, but that would require further MC changes).

Hey, I really appreciate the alternate suggestion!  I'm interested in
a _solution_ more than a particular implementation.  The suggestion
above sounds like it solves duplicates, but doesn't offer the extra
bonus field encoded into the name, and it also introduces a
more-complex name format that doesn't jibe with the legacy of files
out there.  We would want to make sure older Squeak images could
correctly access repositories with those name formats, and that no one
minded seeing a uuid inserted into their names.

> >> - you can't commit the same package twice within a minute, which is a
> >> something you do when you want to split multiple changes up into different
> >> commits
> >
> > Of course you can.  This is just the default generated name, the user
> > or system can increment the number as needed.
>
> So, this is something the suggested change doesn't support yet, isn't it?

It supports the user entering whatever name they want.
____

Maybe it would be best if I tried this out in one of my own packages.
I would just need to tweak MC's code to support it whenever it finds a
package number > 66000, otherwise stay with the old consecutive..


 - Chris





Reply | Threaded
Open this post in threaded view
|

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

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

Can somebody please summarize the problem we want to solve (or address)
here? I still don't understand it... :-( If "uniqueness" is the problem,
just add this new number:

Monticello-cmm.66240.685

Best,
Marcel


commits-2 wrote

> Chris Muller uploaded a new version of Monticello to project The Inbox:
> http://source.squeak.org/inbox/Monticello-cmm.66240.mcz
>
> ==================== Summary ====================
>
> Name: Monticello-cmm.66240
> Author: cmm
> Time: 16 February 2019, 4:49:51.685281 pm
> UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
> Ancestors: Monticello-eem.684
>
> Monticello only requires monotonicity and uniqueness for its version
> numbers, not consecutiveness.  When saving a new package, generate a
> unique, 6-digit versionNumber.  Beginning approximately
> 2020-11-25T10:40:00+00:00, a 7th digit will appear -- no more than a local
> phone number -- which will be good until year 2038.
>
> =============== Diff against Monticello-eem.684 ===============
>
> Item was added:
> + ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry')
> -----
> + hasAncestorNamed: aString
> + self allAncestorsDo:
> + [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].
> + ^ false!
>
> Item was added:
> + ----- Method: MCVersionName class>>newVersionNameFor: (in category
> 'utilities') -----
> + newVersionNameFor: branchName
> + ^ branchName, '-' , Utilities authorInitials , '.' , self
> newVersionNumberString!
>
> Item was added:
> + ----- Method: MCVersionName class>>newVersionNumberString (in category
> 'utilities') -----
> + newVersionNumberString
> + "Answer a unique version number for use in generating the versionNumber
> portion of my name."
> + ^ self versionNumberFor: DateAndTime now!
>
> Item was added:
> + ----- Method: MCVersionName class>>versionNumberFor: (in category
> 'private') -----
> + versionNumberFor: aDateAndTime
> + "Answer a unique version number for use in generating the versionNumber
> portion of my name."
> + | epoch |
> + epoch := '2019-01-01T00:00:00+00:00' asDateAndTime.
> + ^ (aDateAndTime - epoch) days * 24 * 60!
>
> 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 ].
> + ^ MCVersionName newVersionNameFor: branch!
> - 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!





--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Reply | Threaded
Open this post in threaded view
|

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

Jakob Reschke
As I understood Chris, he tries to solve the following uniqueness problem: you can generate distinct MCVersions that have the same name (by saving to a local repository on different machines, for example). This produces problems when you want to "push" both of these versions to a central repository because of the way HTTP repositories (and others) depend on the uniqueness of version names. Moreover it is confusing for the repository maintainers because the ancestry of one version might refer to a version that is not present in the repository, but a different version with the same name *is* present in the repository, leading you to mistake one for the other.

The two-laptops-with-a-local-repository use case is not the regular Monticello workflow. That's why Levente says it happens way too infrequently. But it is a realization of a truly distributed workflow that Monticello should support.

In Git they say: everybody is on their own branch [even though everybody may have checkout out "master"]. Actually, every cloned repository is on its own branch... and the same applies to Monticello. Git does not suffer from the same problem because it does not use consecutive version numbers.

Am Mo., 18. Feb. 2019 um 13:41 Uhr schrieb marcel.taeumel <[hidden email]>:
Hi, there.

Can somebody please summarize the problem we want to solve (or address)
here? I still don't understand it... :-( If "uniqueness" is the problem,
just add this new number:

Monticello-cmm.66240.685

Best,
Marcel


commits-2 wrote
> Chris Muller uploaded a new version of Monticello to project The Inbox:
> http://source.squeak.org/inbox/Monticello-cmm.66240.mcz
>
> ==================== Summary ====================
>
> Name: Monticello-cmm.66240
> Author: cmm
> Time: 16 February 2019, 4:49:51.685281 pm
> UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
> Ancestors: Monticello-eem.684
>
> Monticello only requires monotonicity and uniqueness for its version
> numbers, not consecutiveness.  When saving a new package, generate a
> unique, 6-digit versionNumber.  Beginning approximately
> 2020-11-25T10:40:00+00:00, a 7th digit will appear -- no more than a local
> phone number -- which will be good until year 2038.
>
> =============== Diff against Monticello-eem.684 ===============
>
> Item was added:
> + ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry')
> -----
> + hasAncestorNamed: aString
> +     self allAncestorsDo:
> +             [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].
> +     ^ false!
>
> Item was added:
> + ----- Method: MCVersionName class>>newVersionNameFor: (in category
> 'utilities') -----
> + newVersionNameFor: branchName
> +     ^ branchName, '-' , Utilities authorInitials , '.' , self
> newVersionNumberString!
>
> Item was added:
> + ----- Method: MCVersionName class>>newVersionNumberString (in category
> 'utilities') -----
> + newVersionNumberString
> +     "Answer a unique version number for use in generating the versionNumber
> portion of my name."
> +     ^ self versionNumberFor: DateAndTime now!
>
> Item was added:
> + ----- Method: MCVersionName class>>versionNumberFor: (in category
> 'private') -----
> + versionNumberFor: aDateAndTime
> +     "Answer a unique version number for use in generating the versionNumber
> portion of my name."
> +     | epoch |
> +     epoch := '2019-01-01T00:00:00+00:00' asDateAndTime.
> +     ^ (aDateAndTime - epoch) days * 24 * 60!
>
> 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 ].
> +     ^ MCVersionName newVersionNameFor: branch!
> -                     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!





--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html



Reply | Threaded
Open this post in threaded view
|

Re: Monticello and version names and numbers (was: The Inbox: Monticello-cmm.66240.mcz)

Chris Muller-3
In reply to this post by Nicolas Cellier
Nicolas,

I was ready to drop this but your note is confusing.

> All the information (name id commit message) are available in ancestry.
> Unfortunately, when browsing a remote repository we only get the names, until we load each individual mcz. This is what is most limiting the possible ui improvment.

MCRepositories are generally only responsible for accessing at the mcz
/ mcd level, not the inner-contents of those files and not the
ancestral domain.  This is by design, proper, not a limiting of any MC
use-cases, since what Jakob wants to do should be done from the
History list of the WorkingCopy, not the repository browser.

> That's also why we rely a bit more on name than others. Also note that we rarely use branch names and don't have GUI showing the ancestor graph; the ancestry is approximately encoded in version number (fork is a few versions ahead).

It's not encoded at all.  You can't look at any version number and
know what its ancestor is.  Most often its the 2nd highest number
(whether 4 or 6 digits), but it may not be.

> We can't remove name feature without first adding replacement in servers and that's why we reject Chris proposals: we loose something more important than what we gain.

Remove what name feature?  The proposal of generating a 6-digit
default version number has nothing to do with servers.
What we "lose" by that proposal is having to look at 2 additional
digits in version #'s, plus whatever value people derived from their
consecutive nature.
What we gain is name uniqueness and a timestamp tersely encoded into the name.

That's probably the best deal we could hope for.  Any attempt to
complicate it and break compatibility by changing the scope of
responsibility of Repository's and their access protocol from clients
will not be economically feasible for anyone.

> Changing the model is not that obvious. Each package retains a copy of whole history.
> This redundancy confer the robustness of MC to missing ancestors and partial history. Note that Pharo did erase this ancestry in each release, which is really aggressive... you then can't find common ancestors when porting changes!
>
> If we wan't the server to list more than names,

We don't.

> either we pass many redundant information, wasting bandpass and response time, or we pass only head information for each mcz, but then loose history chain at each missing mcz. There are a lot of missing mcz (It's equivalent to a squash, except that the ancestry keeps track of intermediate commits).

OR, generate a six-digit version number and call it done.   :)    I
appreciate your point in the other thread about subconsciously liking
it to be only 4-5 digits, but I'm skeptical and might try it on one of
my packages to see.

 - Chris

>
> It means that the server should carry an analysis of available package and ancestry relationship before transmitting these data... Not ideal!
>
>
> Le lun. 18 févr. 2019 à 00:08, Jakob Reschke <[hidden email]> a écrit :
>>
>> Hi,
>>
>> Am So., 17. Feb. 2019 um 22:53 Uhr schrieb Nicolas Cellier <[hidden email]>:
>>>
>>> Hi Chris,
>>> Consciously or not, we use these numbers a lot.
>>> For example, when inspecting the versions in inbox, it's very easy to remember and identify the versions, then select them in source.squeak.org web interface then move to treated inbox.
>>> A version in inbox is like pull/merge requests in github/gitlab: it has short number and that helps quick identification, selection in a list, ...
>>
>>
>> Sounds like the inbox treating tools also only show the version name and not the commit message, at least not until you select a particular version... is that correct?
>>
>> When I seek a version anywhere else but in Monticello, I look for the commit message. I don't have to deal with many pull requests, but I am regularly reluctant to remember even the three digits of them. ;-) I always look them up by browsing the pull requests where I see their titles, or I use the helpful issue reference autocompletion of GitHub that displays the titles next to the numbers and allows to search them by typing text. In my opinion, titles and commit messages are far more recognizable than any kind of number or identifier.
>>
>> I read that one generalized use case is to take the version name to somewhere else for reference (as Nicolas and Eliot wrote). I just re-checked the Monticello repository browser: to copy a version name, you have to select (and download) the version, highlight the name in the text box below and press copy. Might be better to have a "copy version name" command in the pop-up menu of the version list. And a text box in the inbox treating UI where you can paste it... Going to a particular version in the repository browser currently requires you to scroll and look for the version number, or typing its name to filter the list. Both ways really require you to run the number through your mind, and using the filtering is awkward on top because after each keystroke, another version gets selected and downloaded, interrupting your typing. Also, longer numbers with low variance in the most-significant digits would increase that pain. What about a go-to text box above or below the list where you can paste a version name (or UUID in the future?), press enter, and be taken to it, if present? It could even take you to a different package than the one you have selected.
>>
>> Just to be clear: my point is not to criticize your habits and ways to use the version numbers. But I suspect that the "humanly" requirements imposed on the numbers and version names indicates that there is a lack in the tool chain. Or the design, since you currently have to download a version wholly to get its message and UUID. Improving that might turn out to be better in the long term than sticking with the status quo. And it might solve more problems than just the one Chris is trying to solve here.
>>
>> How much effort would it be to extend the server side of a Monticello HTTP repository such that it allows to query for the names, UUIDs and message headlines (and cache that information)? Like back in the days before IMAP, when you could opt to just fetch the headers of your emails...
>>
>> Unfortunately extending the tools does not resolve the compatibility issue with older Squeak images. Or the brevity of the update number, although I am not yet sure whether this one is really worth saving.
>>
>> Kind regards,
>> Jakob
>>
>>>
>>>
>>> Le dim. 17 févr. 2019 à 21:32, Chris Muller <[hidden email]> a écrit :
>>>>
>>>> > > You mean, instead of 5?
>>>> >
>>>> > Yes, 5 is about the length of the longest sequence of digits one will
>>>> > recognize and remember in one shot (it's still easy to miss though).
>>>> > 7 would be too long and too error prone: Is it 1342578 or 1345278? Hard to
>>>> > tell without looking at those numbers thoroughly, isn't it?
>>>>
>>>> That's fair.  However, you could easily derive the same 5-digit
>>>> version of this number by the sum of the #numberOfAncestors count.
>>>> How it's done doesn't really concern Monticello.
>>>>
>>>> I'm really curious how you're using this number, I almost never pay
>>>> that number any attention whatsoever.  Obviously, you have a human in
>>>> the loop, and it sounds like there's something manual about it..
>>>>
>>>> > >> - the version number would lose information about the number of commits of
>>>> > >> the given package. You may argue that it's not exact, but it still gives a
>>>> > >> good estimate.
>>>> > >
>>>> > > This is an easy number to calculate when the file is open and include
>>>> > > in header descrption of a VersionInfo...  For example:
>>>> >
>>>> > Yes. The problem is that the number would not exists outside the image.
>>>> > When you only have a file on your disk, that information is not available.
>>>>
>>>> Heh, you keep raising your "requirements" to calculate these obscure
>>>> metrics, it starts to feel like a game.  :)  Okay, assuming you have a
>>>> complete repository, how about:
>>>>
>>>>     ls -1 PackageName-*.mc? | wc -l
>>>>
>>>> Without knowing what use-case needs this metric under such conditions,
>>>> it's hard to know what the best solution would be...
>>>>
>>>> Keep in mind, with my proposal you would be able to "eyeball" a
>>>> different metric that could be useful -- the age of the version..
>>>>
>>>> > > Name: Monticello-cmm.66240
>>>> > > Author: cmm
>>>> > > Time: 16 February 2019, 4:49:51.685281 pm
>>>> > > UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
>>>> > > Ancestors (684): Monticello-eem.684
>>>> > >
>>>> > >> - it solves a problem that happens way too infrequently (different
>>>> > >> packages with the same name)
>>>> > >
>>>> > > It's actually not.  Working in Squeak on two separate laptops (i.e.,
>>>> > > home vs. work) is very common, but incredibly onerous because it
>>>> > > *frequently* results in duplicate package names.
>>>> >
>>>> > Right, but you'll notice it as soon as you try to commit it into your
>>>> > repository.
>>>>
>>>> By then it's too late!  Please tell me what you would do in that
>>>> scenario, when you went to merge and found a couple of name conflicts
>>>> buried 4 or 5 deep in the ancestry of both chains?  Ignore it and
>>>> leave holes in your repository?  Or rewrite history?
>>>>
>>>> It only takes this scenario to happen once to understand the level of
>>>> hassle or compromise it forces one into.
>>>>
>>>> > > This is more than "solving a problem",  it enables a new power of
>>>> > > simultaneous streams of development on the same packages in different
>>>> > > images -- with no danger of duplicates.
>>>> > >
>>>> > > Moreover, it's an elegant way for Monticello to realize its goal of
>>>> > > providing a distributed code model.
>>>> >
>>>> > Yes, but if I were to solve this problem, I would just extend the naming
>>>> > scheme:
>>>> > Instead of Monticello-cmm.684.mcz, it may as well be
>>>> > Monticello-cmm.684.435c7c.mcz, which would preserve the version number but
>>>> > extend the name with the first few digits of the UUID (which is actually
>>>> > not so good, because of how UUID works, and using e.g. the SHA256 has of the
>>>> > source file would be superior, but that would require further MC changes).
>>>>
>>>> Hey, I really appreciate the alternate suggestion!  I'm interested in
>>>> a _solution_ more than a particular implementation.  The suggestion
>>>> above sounds like it solves duplicates, but doesn't offer the extra
>>>> bonus field encoded into the name, and it also introduces a
>>>> more-complex name format that doesn't jibe with the legacy of files
>>>> out there.  We would want to make sure older Squeak images could
>>>> correctly access repositories with those name formats, and that no one
>>>> minded seeing a uuid inserted into their names.
>>>>
>>>> > >> - you can't commit the same package twice within a minute, which is a
>>>> > >> something you do when you want to split multiple changes up into different
>>>> > >> commits
>>>> > >
>>>> > > Of course you can.  This is just the default generated name, the user
>>>> > > or system can increment the number as needed.
>>>> >
>>>> > So, this is something the suggested change doesn't support yet, isn't it?
>>>>
>>>> It supports the user entering whatever name they want.
>>>> ____
>>>>
>>>> Maybe it would be best if I tried this out in one of my own packages.
>>>> I would just need to tweak MC's code to support it whenever it finds a
>>>> package number > 66000, otherwise stay with the old consecutive..
>>>>
>>>>
>>>>  - Chris
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Monticello and version names and numbers (was: The Inbox: Monticello-cmm.66240.mcz)

Jakob Reschke
Am Mo., 18. Feb. 2019 um 17:30 Uhr schrieb Chris Muller <[hidden email]>:

MCRepositories are generally only responsible for accessing at the mcz
/ mcd level, not the inner-contents of those files and not the
ancestral domain.  This is by design, proper, not a limiting of any MC
use-cases, since what Jakob wants to do should be done from the
History list of the WorkingCopy, not the repository browser.

Displaying that in a proper log view instead of a name list could also be okay. BUT one would first have to know for certain the branch heads/tips/ends of each package, so you would know which versions you have to load to be able to display a complete log. Also keep in mind the case when you do not (yet) have a working copy.

Could be done by fetching the directory listing, downloading the top version (which would require the numbers to continue to increase monotonously, hmm), extracting the history, eliminating all versions from the listing that are contained in the history (which would still require the names to be unique, hmm), repeat with the top version of the remaining listing, until none are left. Takes a while until it's finished and has some, hopefully rare, bad case scenarios...


Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by Jakob Reschke
Hi Jakob,

On Mon, Feb 18, 2019 at 5:54 AM Jakob Reschke <[hidden email]> wrote:
As I understood Chris, he tries to solve the following uniqueness problem: you can generate distinct MCVersions that have the same name (by saving to a local repository on different machines, for example). This produces problems when you want to "push" both of these versions to a central repository because of the way HTTP repositories (and others) depend on the uniqueness of version names. Moreover it is confusing for the repository maintainers because the ancestry of one version might refer to a version that is not present in the repository, but a different version with the same name *is* present in the repository, leading you to mistake one for the other.

Why would one want to confuse oneself by doing this?
 

The two-laptops-with-a-local-repository use case is not the regular Monticello workflow. That's why Levente says it happens way too infrequently. But it is a realization of a truly distributed workflow that Monticello should support.

In Git they say: everybody is on their own branch [even though everybody may have checkout out "master"]. Actually, every cloned repository is on its own branch... and the same applies to Monticello. Git does not suffer from the same problem because it does not use consecutive version numbers.

I still don't understand.  Provided we have unique personal identifiers there is no problem.  Often in VMMaker we will produce packages with the same version number but different initials (because they are produced by different people).  This presents no problem at all.  I don't get it.

A problem could come where one generates two different versions oneself.  But as the old joke goes "Doctor my thumb hurts.  Why?  Because I'm hitting my thumb with a hammer!  Doctor: Don't do that."
 

Am Mo., 18. Feb. 2019 um 13:41 Uhr schrieb marcel.taeumel <[hidden email]>:
Hi, there.

Can somebody please summarize the problem we want to solve (or address)
here? I still don't understand it... :-( If "uniqueness" is the problem,
just add this new number:

Monticello-cmm.66240.685

Best,
Marcel


commits-2 wrote
> Chris Muller uploaded a new version of Monticello to project The Inbox:
> http://source.squeak.org/inbox/Monticello-cmm.66240.mcz
>
> ==================== Summary ====================
>
> Name: Monticello-cmm.66240
> Author: cmm
> Time: 16 February 2019, 4:49:51.685281 pm
> UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
> Ancestors: Monticello-eem.684
>
> Monticello only requires monotonicity and uniqueness for its version
> numbers, not consecutiveness.  When saving a new package, generate a
> unique, 6-digit versionNumber.  Beginning approximately
> 2020-11-25T10:40:00+00:00, a 7th digit will appear -- no more than a local
> phone number -- which will be good until year 2038.
>
> =============== Diff against Monticello-eem.684 ===============
>
> Item was added:
> + ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry')
> -----
> + hasAncestorNamed: aString
> +     self allAncestorsDo:
> +             [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].
> +     ^ false!
>
> Item was added:
> + ----- Method: MCVersionName class>>newVersionNameFor: (in category
> 'utilities') -----
> + newVersionNameFor: branchName
> +     ^ branchName, '-' , Utilities authorInitials , '.' , self
> newVersionNumberString!
>
> Item was added:
> + ----- Method: MCVersionName class>>newVersionNumberString (in category
> 'utilities') -----
> + newVersionNumberString
> +     "Answer a unique version number for use in generating the versionNumber
> portion of my name."
> +     ^ self versionNumberFor: DateAndTime now!
>
> Item was added:
> + ----- Method: MCVersionName class>>versionNumberFor: (in category
> 'private') -----
> + versionNumberFor: aDateAndTime
> +     "Answer a unique version number for use in generating the versionNumber
> portion of my name."
> +     | epoch |
> +     epoch := '2019-01-01T00:00:00+00:00' asDateAndTime.
> +     ^ (aDateAndTime - epoch) days * 24 * 60!
>
> 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 ].
> +     ^ MCVersionName newVersionNameFor: branch!
> -                     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!





--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html




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


Reply | Threaded
Open this post in threaded view
|

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

Jakob Reschke
Haha, for some reason I find it hard to get this across. My emails always get longer and longer trying to express myself very thoroughly. Sometimes I leave half a sentence of explanation out to not digress further or dissect an analogy too much, and of course you spot the omission and bring it up (the author initials). :-)

---

As I wrote, the problem does not arise with the regular workflow where one saves to one upstream, central Monticello repository directly.

Using local repos before copying versions upstream can be useful for multiple reasons. 1. you don't have an Internet connection available for whatever reason, 2. you want to create many small commits and only later copy/push them all for everyone to see. I suppose this is something Git or Mercurial users are more likely to even try in the first place.

Then on top you'd have to do that on two machines and, thus, two different local repos that you don't sync up for a certain period of time. The best reason for that is probably a private machine and a corporate machine. You might use the latter on the train on your way to work. But the other might also be a Raspberry Pi and your Internet at home is down for longer and you don't want to set up a small server just for your Monticello repo, I don't know.

Let's try something different. The issue can also surface with two shared repositories, namely Trunk and Inbox.
- Say we have a package X and everyone starts from version X-whoever.1.
- Alice commits a patch of it to the Inbox, X-Alice.2.
- Bob finds that change interesting and creates another version on top of it in the Inbox, X-Bob.3.
- Some time passes because nobody looks at the Inbox. Coincidentally, nobody else touches X in the meantime either.
- Then Alice finds a serious bug in X and commits it right to the Trunk. Because this time she uses a fresh Trunk image that has never seen the Inbox version, this creates *another* X-Alice.2.

The reason and fundamental problem is that the two repositories Trunk and Inbox don't know of each other, like two local repositories or distributed repositories in general. That's why Git does not use consecutive numbers and Mercurial only shows them as a local view on a repository, but never uses them to distinguish versions internally. The author initials in the version names of Monticello do not always resolve the issue when one single person (or two using the same initials for that matter) have access to both of the shared repositories that contain versions of the same package.

- Everything is still fine, until at some point Charlie shows up and finally checks the Inbox.
- He likes the changes made on X by Bob (maybe also those made by Alice, but let's say Charlie does not even notice that Bob's version is not based on the X-Alice.2 in Trunk) and merges X-Bob.3 to Trunk, creating the merge version X-Charlie.4 in the process.

Now we have two distinct X-Alice.2 versions in the history of package X, but only one is present in Trunk You cannot even copy the X-Alice.2 from Inbox to the Trunk, right?

X-Charlie.4 --- X-Bob.3 --- X-Alice.2 [from Inbox] --- X-whoever.1
\-------- X-Alice.2 [from Trunk] -----------------------------/

One might say that this is irrelevant because Alice's first commit message is preserved in the ancestry of X-Bob.3. And since X-Bob.3 also contains the changes from Alice's Inbox version, who cares? Maybe nobody. But the fact is that you can never checkout the snapshot of X-Alice.2 [from Inbox] by looking at the Trunk. And the Inbox version surely will be moved to Treated at some point, and who looks there ever again?

Not so much luck for Chris with his two laptops who eventually tries to consolidate all of his versions in a single repository, but cannot because two of them have the same name...

Now who is to blame for the situation? Should Alice have remembered that there is another version with the same name/number still in the Inbox? Which other number should she have chosen instead? 3, creating a mysterious gap in Trunk? Why does she have to care at all? Should Bob not have jumped at the opportunity to extend something that was still in the Inbox? Should Charlie not have merged a version that has an elder name-twin in its ancestry? Is package X not worthy of a complete snapshot history because nobody had a look at it in the Inbox for so long? Should Chris (sorry btw, I'm just using you as the persona because you brought up the example) not have used two machines to work on the same project? Should he have contracted a more reliable ISP or be more enthusiastic about setting up a central MC repository on the LAN (which still doesn't help when he is on the train)? Should one generally not use two repositories for the same package?

Or should Monticello, calling itself a distributed version control system, have prevented the issue in the first place, by design (not identify versions by name) or implementation (e. g., with Chris's or other's proposals)?

So yes, the issue is theoretical 99.99% of the time. But the practical 0.01% does happen as Chris pointed out and as I-forgot-who noticed when cleaning up the Inbox a few days ago. I've never run into it myself, even though I sometimes did save to the package cache first and copied later. I don't need a solution now or any time soon. It might not even be worth to be fixed. But I find the issue interesting. Otherwise I wouldn't be typing so much text, sorry. :-)

Kind regards,
Jakob


Am Mo., 18. Feb. 2019, 20:08 hat Eliot Miranda <[hidden email]> geschrieben:
Hi Jakob,

On Mon, Feb 18, 2019 at 5:54 AM Jakob Reschke <[hidden email]> wrote:
As I understood Chris, he tries to solve the following uniqueness problem: you can generate distinct MCVersions that have the same name (by saving to a local repository on different machines, for example). This produces problems when you want to "push" both of these versions to a central repository because of the way HTTP repositories (and others) depend on the uniqueness of version names. Moreover it is confusing for the repository maintainers because the ancestry of one version might refer to a version that is not present in the repository, but a different version with the same name *is* present in the repository, leading you to mistake one for the other.

Why would one want to confuse oneself by doing this?
 

The two-laptops-with-a-local-repository use case is not the regular Monticello workflow. That's why Levente says it happens way too infrequently. But it is a realization of a truly distributed workflow that Monticello should support.

In Git they say: everybody is on their own branch [even though everybody may have checkout out "master"]. Actually, every cloned repository is on its own branch... and the same applies to Monticello. Git does not suffer from the same problem because it does not use consecutive version numbers.

I still don't understand.  Provided we have unique personal identifiers there is no problem.  Often in VMMaker we will produce packages with the same version number but different initials (because they are produced by different people).  This presents no problem at all.  I don't get it.

A problem could come where one generates two different versions oneself.  But as the old joke goes "Doctor my thumb hurts.  Why?  Because I'm hitting my thumb with a hammer!  Doctor: Don't do that."
 

Am Mo., 18. Feb. 2019 um 13:41 Uhr schrieb marcel.taeumel <[hidden email]>:
Hi, there.

Can somebody please summarize the problem we want to solve (or address)
here? I still don't understand it... :-( If "uniqueness" is the problem,
just add this new number:

Monticello-cmm.66240.685

Best,
Marcel


commits-2 wrote
> Chris Muller uploaded a new version of Monticello to project The Inbox:
> http://source.squeak.org/inbox/Monticello-cmm.66240.mcz
>
> ==================== Summary ====================
>
> Name: Monticello-cmm.66240
> Author: cmm
> Time: 16 February 2019, 4:49:51.685281 pm
> UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
> Ancestors: Monticello-eem.684
>
> Monticello only requires monotonicity and uniqueness for its version
> numbers, not consecutiveness.  When saving a new package, generate a
> unique, 6-digit versionNumber.  Beginning approximately
> 2020-11-25T10:40:00+00:00, a 7th digit will appear -- no more than a local
> phone number -- which will be good until year 2038.
>
> =============== Diff against Monticello-eem.684 ===============
>
> Item was added:
> + ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry')
> -----
> + hasAncestorNamed: aString
> +     self allAncestorsDo:
> +             [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].
> +     ^ false!
>
> Item was added:
> + ----- Method: MCVersionName class>>newVersionNameFor: (in category
> 'utilities') -----
> + newVersionNameFor: branchName
> +     ^ branchName, '-' , Utilities authorInitials , '.' , self
> newVersionNumberString!
>
> Item was added:
> + ----- Method: MCVersionName class>>newVersionNumberString (in category
> 'utilities') -----
> + newVersionNumberString
> +     "Answer a unique version number for use in generating the versionNumber
> portion of my name."
> +     ^ self versionNumberFor: DateAndTime now!
>
> Item was added:
> + ----- Method: MCVersionName class>>versionNumberFor: (in category
> 'private') -----
> + versionNumberFor: aDateAndTime
> +     "Answer a unique version number for use in generating the versionNumber
> portion of my name."
> +     | epoch |
> +     epoch := '2019-01-01T00:00:00+00:00' asDateAndTime.
> +     ^ (aDateAndTime - epoch) days * 24 * 60!
>
> 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 ].
> +     ^ MCVersionName newVersionNameFor: branch!
> -                     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!





--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html




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



Reply | Threaded
Open this post in threaded view
|

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

Jakob Reschke
In reply to this post by marcel.taeumel
Am Mo., 18. Feb. 2019 um 13:41 Uhr schrieb marcel.taeumel <[hidden email]>:
If "uniqueness" is the problem,
just add this new number:

Monticello-cmm.66240.685

I like this one. It combines the "random" identifier with the consecutive number, kind of like Mercurial. One could also use some digits of the UUID if any portion of it has sufficient variance. What about the legacy here?


Reply | Threaded
Open this post in threaded view
|

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

Nicolas Cellier
In reply to this post by Jakob Reschke
It's me who discovered a conflicting package in the inbox. Guess which package? Monticello itself! Irony...

I have since introduced a warning in the UI: when you select the package it is marked as bold red and the text panes signals in bol red that there is a conflicting name in working copy ancestry. So the chance to merge a conflict should greatly be reduced, at least for our trunk/inbox which generally has very short chains of commits.

It could still hapen that we merge two non conflicting version that have a conflicting ancestor though. We can test that case as well if we think it's worth...

In 15 years of squeaking and maybe a thousand commits, that happened to myself to produce version name clashes maybe 3 or 4 times, either from different computers, or even different directories on same computer.

So yes, uniqueness matters, but clashes are rare, and merge of clashes very rare.

Le lun. 18 févr. 2019 à 21:58, Jakob Reschke <[hidden email]> a écrit :
Haha, for some reason I find it hard to get this across. My emails always get longer and longer trying to express myself very thoroughly. Sometimes I leave half a sentence of explanation out to not digress further or dissect an analogy too much, and of course you spot the omission and bring it up (the author initials). :-)

---

As I wrote, the problem does not arise with the regular workflow where one saves to one upstream, central Monticello repository directly.

Using local repos before copying versions upstream can be useful for multiple reasons. 1. you don't have an Internet connection available for whatever reason, 2. you want to create many small commits and only later copy/push them all for everyone to see. I suppose this is something Git or Mercurial users are more likely to even try in the first place.

Then on top you'd have to do that on two machines and, thus, two different local repos that you don't sync up for a certain period of time. The best reason for that is probably a private machine and a corporate machine. You might use the latter on the train on your way to work. But the other might also be a Raspberry Pi and your Internet at home is down for longer and you don't want to set up a small server just for your Monticello repo, I don't know.

Let's try something different. The issue can also surface with two shared repositories, namely Trunk and Inbox.
- Say we have a package X and everyone starts from version X-whoever.1.
- Alice commits a patch of it to the Inbox, X-Alice.2.
- Bob finds that change interesting and creates another version on top of it in the Inbox, X-Bob.3.
- Some time passes because nobody looks at the Inbox. Coincidentally, nobody else touches X in the meantime either.
- Then Alice finds a serious bug in X and commits it right to the Trunk. Because this time she uses a fresh Trunk image that has never seen the Inbox version, this creates *another* X-Alice.2.

The reason and fundamental problem is that the two repositories Trunk and Inbox don't know of each other, like two local repositories or distributed repositories in general. That's why Git does not use consecutive numbers and Mercurial only shows them as a local view on a repository, but never uses them to distinguish versions internally. The author initials in the version names of Monticello do not always resolve the issue when one single person (or two using the same initials for that matter) have access to both of the shared repositories that contain versions of the same package.

- Everything is still fine, until at some point Charlie shows up and finally checks the Inbox.
- He likes the changes made on X by Bob (maybe also those made by Alice, but let's say Charlie does not even notice that Bob's version is not based on the X-Alice.2 in Trunk) and merges X-Bob.3 to Trunk, creating the merge version X-Charlie.4 in the process.

Now we have two distinct X-Alice.2 versions in the history of package X, but only one is present in Trunk You cannot even copy the X-Alice.2 from Inbox to the Trunk, right?

X-Charlie.4 --- X-Bob.3 --- X-Alice.2 [from Inbox] --- X-whoever.1
\-------- X-Alice.2 [from Trunk] -----------------------------/

One might say that this is irrelevant because Alice's first commit message is preserved in the ancestry of X-Bob.3. And since X-Bob.3 also contains the changes from Alice's Inbox version, who cares? Maybe nobody. But the fact is that you can never checkout the snapshot of X-Alice.2 [from Inbox] by looking at the Trunk. And the Inbox version surely will be moved to Treated at some point, and who looks there ever again?

Not so much luck for Chris with his two laptops who eventually tries to consolidate all of his versions in a single repository, but cannot because two of them have the same name...

Now who is to blame for the situation? Should Alice have remembered that there is another version with the same name/number still in the Inbox? Which other number should she have chosen instead? 3, creating a mysterious gap in Trunk? Why does she have to care at all? Should Bob not have jumped at the opportunity to extend something that was still in the Inbox? Should Charlie not have merged a version that has an elder name-twin in its ancestry? Is package X not worthy of a complete snapshot history because nobody had a look at it in the Inbox for so long? Should Chris (sorry btw, I'm just using you as the persona because you brought up the example) not have used two machines to work on the same project? Should he have contracted a more reliable ISP or be more enthusiastic about setting up a central MC repository on the LAN (which still doesn't help when he is on the train)? Should one generally not use two repositories for the same package?

Or should Monticello, calling itself a distributed version control system, have prevented the issue in the first place, by design (not identify versions by name) or implementation (e. g., with Chris's or other's proposals)?

So yes, the issue is theoretical 99.99% of the time. But the practical 0.01% does happen as Chris pointed out and as I-forgot-who noticed when cleaning up the Inbox a few days ago. I've never run into it myself, even though I sometimes did save to the package cache first and copied later. I don't need a solution now or any time soon. It might not even be worth to be fixed. But I find the issue interesting. Otherwise I wouldn't be typing so much text, sorry. :-)

Kind regards,
Jakob


Am Mo., 18. Feb. 2019, 20:08 hat Eliot Miranda <[hidden email]> geschrieben:
Hi Jakob,

On Mon, Feb 18, 2019 at 5:54 AM Jakob Reschke <[hidden email]> wrote:
As I understood Chris, he tries to solve the following uniqueness problem: you can generate distinct MCVersions that have the same name (by saving to a local repository on different machines, for example). This produces problems when you want to "push" both of these versions to a central repository because of the way HTTP repositories (and others) depend on the uniqueness of version names. Moreover it is confusing for the repository maintainers because the ancestry of one version might refer to a version that is not present in the repository, but a different version with the same name *is* present in the repository, leading you to mistake one for the other.

Why would one want to confuse oneself by doing this?
 

The two-laptops-with-a-local-repository use case is not the regular Monticello workflow. That's why Levente says it happens way too infrequently. But it is a realization of a truly distributed workflow that Monticello should support.

In Git they say: everybody is on their own branch [even though everybody may have checkout out "master"]. Actually, every cloned repository is on its own branch... and the same applies to Monticello. Git does not suffer from the same problem because it does not use consecutive version numbers.

I still don't understand.  Provided we have unique personal identifiers there is no problem.  Often in VMMaker we will produce packages with the same version number but different initials (because they are produced by different people).  This presents no problem at all.  I don't get it.

A problem could come where one generates two different versions oneself.  But as the old joke goes "Doctor my thumb hurts.  Why?  Because I'm hitting my thumb with a hammer!  Doctor: Don't do that."
 

Am Mo., 18. Feb. 2019 um 13:41 Uhr schrieb marcel.taeumel <[hidden email]>:
Hi, there.

Can somebody please summarize the problem we want to solve (or address)
here? I still don't understand it... :-( If "uniqueness" is the problem,
just add this new number:

Monticello-cmm.66240.685

Best,
Marcel


commits-2 wrote
> Chris Muller uploaded a new version of Monticello to project The Inbox:
> http://source.squeak.org/inbox/Monticello-cmm.66240.mcz
>
> ==================== Summary ====================
>
> Name: Monticello-cmm.66240
> Author: cmm
> Time: 16 February 2019, 4:49:51.685281 pm
> UUID: 435c7c35-3b22-4f66-b733-070ccd48a980
> Ancestors: Monticello-eem.684
>
> Monticello only requires monotonicity and uniqueness for its version
> numbers, not consecutiveness.  When saving a new package, generate a
> unique, 6-digit versionNumber.  Beginning approximately
> 2020-11-25T10:40:00+00:00, a 7th digit will appear -- no more than a local
> phone number -- which will be good until year 2038.
>
> =============== Diff against Monticello-eem.684 ===============
>
> Item was added:
> + ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry')
> -----
> + hasAncestorNamed: aString
> +     self allAncestorsDo:
> +             [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].
> +     ^ false!
>
> Item was added:
> + ----- Method: MCVersionName class>>newVersionNameFor: (in category
> 'utilities') -----
> + newVersionNameFor: branchName
> +     ^ branchName, '-' , Utilities authorInitials , '.' , self
> newVersionNumberString!
>
> Item was added:
> + ----- Method: MCVersionName class>>newVersionNumberString (in category
> 'utilities') -----
> + newVersionNumberString
> +     "Answer a unique version number for use in generating the versionNumber
> portion of my name."
> +     ^ self versionNumberFor: DateAndTime now!
>
> Item was added:
> + ----- Method: MCVersionName class>>versionNumberFor: (in category
> 'private') -----
> + versionNumberFor: aDateAndTime
> +     "Answer a unique version number for use in generating the versionNumber
> portion of my name."
> +     | epoch |
> +     epoch := '2019-01-01T00:00:00+00:00' asDateAndTime.
> +     ^ (aDateAndTime - epoch) days * 24 * 60!
>
> 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 ].
> +     ^ MCVersionName newVersionNameFor: branch!
> -                     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!





--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html




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




12