[squeak-dev] The Inbox: Monticello-cmm.66240.mcz

Jakob Reschke forums.jakob at resfarm.de
Mon Feb 18 20:58:19 UTC 2019


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 <eliot.miranda at gmail.com>
geschrieben:

> Hi Jakob,
>
> On Mon, Feb 18, 2019 at 5:54 AM Jakob Reschke <forums.jakob at resfarm.de>
> 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 <
>> Marcel.Taeumel at hpi.de>:
>>
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190218/89c42eda/attachment.html>


More information about the Squeak-dev mailing list