The Inbox: Monticello-cmm.66240.mcz

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

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

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

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

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