<div dir="auto">It's me who discovered a conflicting package in the inbox. Guess which package? Monticello itself! Irony...<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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...</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">So yes, uniqueness matters, but clashes are rare, and merge of clashes very rare.</div></div><br><div class="gmail_quote"><div dir="ltr">Le lun. 18 févr. 2019 à 21:58, Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de">forums.jakob@resfarm.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="auto">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). :-)<div dir="auto"><br></div><div dir="auto">---<br><div dir="auto"><div dir="auto"><br></div><div dir="auto">As I wrote, the problem does not arise with the regular workflow where one saves to one upstream, central Monticello repository directly.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div>Let's try something different. The issue can also surface with two shared repositories, namely Trunk and Inbox.</div><div>- Say we have a package X and everyone starts from version X-whoever.1.</div><div>- Alice commits a patch of it to the Inbox, X-Alice.2.</div><div>- Bob finds that change interesting and creates another version on top of it in the Inbox, X-Bob.3.</div><div>- Some time passes because nobody looks at the Inbox. Coincidentally, nobody else touches X in the meantime either.</div><div>- 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.</div><div><br></div><div>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.</div><div><br></div><div>- Everything is still fine, until at some point Charlie shows up and finally checks the Inbox.</div><div>- 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.</div><div><br></div><div>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?<br></div><div><br></div><div>X-Charlie.4 --- X-Bob.3 --- X-Alice.2 [from Inbox] --- X-whoever.1</div><div>\-------- X-Alice.2 [from Trunk] -----------------------------/</div><div><br></div><div>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?</div><div><br></div><div>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...</div><div><br></div><div>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?</div><div><br></div><div>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)?</div><div dir="auto"><br></div><div dir="auto">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. :-)</div><div dir="auto"><br></div><div>Kind regards,</div><div>Jakob</div><div dir="auto"><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">Am Mo., 18. Feb. 2019, 20:08 hat Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank" rel="noreferrer">eliot.miranda@gmail.com</a>> geschrieben:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Jakob,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 18, 2019 at 5:54 AM Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" rel="noreferrer noreferrer" target="_blank">forums.jakob@resfarm.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.</div></blockquote><div><br></div><div>Why would one want to confuse oneself by doing this?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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."</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 18. Feb. 2019 um 13:41 Uhr schrieb marcel.taeumel <<a href="mailto:Marcel.Taeumel@hpi.de" rel="noreferrer noreferrer" target="_blank">Marcel.Taeumel@hpi.de</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi, there.<br>
<br>
Can somebody please summarize the problem we want to solve (or address)<br>
here? I still don't understand it... :-( If "uniqueness" is the problem,<br>
just add this new number:<br>
<br>
Monticello-cmm.66240.685<br>
<br>
Best,<br>
Marcel<br>
<br>
<br>
commits-2 wrote<br>
> Chris Muller uploaded a new version of Monticello to project The Inbox:<br>
> <a href="http://source.squeak.org/inbox/Monticello-cmm.66240.mcz" rel="noreferrer noreferrer noreferrer" target="_blank">http://source.squeak.org/inbox/Monticello-cmm.66240.mcz</a><br>
> <br>
> ==================== Summary ====================<br>
> <br>
> Name: Monticello-cmm.66240<br>
> Author: cmm<br>
> Time: 16 February 2019, 4:49:51.685281 pm<br>
> UUID: 435c7c35-3b22-4f66-b733-070ccd48a980<br>
> Ancestors: Monticello-eem.684<br>
> <br>
> Monticello only requires monotonicity and uniqueness for its version<br>
> numbers, not consecutiveness. When saving a new package, generate a<br>
> unique, 6-digit versionNumber. Beginning approximately <br>
> 2020-11-25T10:40:00+00:00, a 7th digit will appear -- no more than a local<br>
> phone number -- which will be good until year 2038.<br>
> <br>
> =============== Diff against Monticello-eem.684 ===============<br>
> <br>
> Item was added:<br>
> + ----- Method: MCAncestry>>hasAncestorNamed: (in category 'ancestry')<br>
> -----<br>
> + hasAncestorNamed: aString<br>
> + self allAncestorsDo:<br>
> + [ : each | aString asMCVersionName = each name ifTrue: [ ^ true ] ].<br>
> + ^ false!<br>
> <br>
> Item was added:<br>
> + ----- Method: MCVersionName class>>newVersionNameFor: (in category<br>
> 'utilities') -----<br>
> + newVersionNameFor: branchName<br>
> + ^ branchName, '-' , Utilities authorInitials , '.' , self<br>
> newVersionNumberString!<br>
> <br>
> Item was added:<br>
> + ----- Method: MCVersionName class>>newVersionNumberString (in category<br>
> 'utilities') -----<br>
> + newVersionNumberString<br>
> + "Answer a unique version number for use in generating the versionNumber<br>
> portion of my name."<br>
> + ^ self versionNumberFor: DateAndTime now!<br>
> <br>
> Item was added:<br>
> + ----- Method: MCVersionName class>>versionNumberFor: (in category<br>
> 'private') -----<br>
> + versionNumberFor: aDateAndTime <br>
> + "Answer a unique version number for use in generating the versionNumber<br>
> portion of my name."<br>
> + | epoch |<br>
> + epoch := '2019-01-01T00:00:00+00:00' asDateAndTime.<br>
> + ^ (aDateAndTime - epoch) days * 24 * 60!<br>
> <br>
> Item was changed:<br>
> MCPackageManager subclass: #MCWorkingCopy<br>
> + instanceVariableNames: 'versionInfo ancestry repositoryGroup<br>
> requiredPackages environment'<br>
> - instanceVariableNames: 'versionInfo ancestry counter repositoryGroup<br>
> requiredPackages environment'<br>
> classVariableNames: ''<br>
> poolDictionaries: ''<br>
> category: 'Monticello-Versioning'!<br>
> <br>
> Item was changed:<br>
> ----- Method: MCWorkingCopy>>nextVersionName (in category 'private')<br>
> -----<br>
> nextVersionName<br>
> | branch oldName |<br>
> ancestry ancestors isEmpty<br>
> ifTrue:<br>
> + [ branch := package name ]<br>
> - [ counter ifNil: [ counter := 0 ].<br>
> - branch := package name ]<br>
> ifFalse:<br>
> [ oldName := ancestry ancestors first versionName.<br>
> + branch := oldName packageAndBranchName ].<br>
> + ^ MCVersionName newVersionNameFor: branch!<br>
> - branch := oldName packageAndBranchName.<br>
> - counter ifNil:<br>
> - [ counter := (ancestry ancestors detectMax:<br>
> - [ : eachVersionInfo | eachVersionInfo versionNumber ])<br>
> - ifNil: [ 0 ]<br>
> - ifNotNil:<br>
> - [ : highestNumbered | highestNumbered versionNumber ] ] ].<br>
> - counter := counter + 1.<br>
> - ^ branch , '-' , Utilities authorInitials , '.' , counter asString!<br>
> <br>
> Item was changed:<br>
> ----- Method: MCWorkingCopy>>uniqueVersionName (in category 'private')<br>
> -----<br>
> uniqueVersionName<br>
> |versionName|<br>
> - counter := nil.<br>
> [versionName := self nextVersionName.<br>
> + (self repositoryGroup includesVersionNamed: versionName) or: [ ancestry<br>
> hasAncestorNamed: versionName ]] whileTrue.<br>
> - self repositoryGroup includesVersionNamed: versionName] whileTrue.<br>
> ^ versionName!<br>
<br>
<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://forum.world.st/Squeak-Dev-f45488.html" rel="noreferrer noreferrer noreferrer" target="_blank">http://forum.world.st/Squeak-Dev-f45488.html</a><br>
<br>
</blockquote></div>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-5988531273306681668m_531145442632505622m_-4806540600731043318gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>
<br>
</blockquote></div>
</div>
<br>
</blockquote></div>