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 <forums.jakob at resfarm.de> 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 <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/5ecccd77/attachment.html>