<div dir="auto"><div>Hi Chris,</div><div dir="auto">Consciously or not, we use these numbers a lot.</div><div dir="auto">For example, when inspecting the versions in inbox, it's very easy to remember and identify the versions, then select them in <a href="http://source.squeak.org">source.squeak.org</a> web interface then move to treated inbox.</div><div dir="auto">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, ...<br><br><div class="gmail_quote" dir="auto"><div dir="ltr">Le dim. 17 févr. 2019 à 21:32, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> > You mean, instead of 5?<br>
><br>
> Yes, 5 is about the length of the longest sequence of digits one will<br>
> recognize and remember in one shot (it's still easy to miss though).<br>
> 7 would be too long and too error prone: Is it 1342578 or 1345278? Hard to<br>
> tell without looking at those numbers thoroughly, isn't it?<br>
<br>
That's fair.  However, you could easily derive the same 5-digit<br>
version of this number by the sum of the #numberOfAncestors count.<br>
How it's done doesn't really concern Monticello.<br>
<br>
I'm really curious how you're using this number, I almost never pay<br>
that number any attention whatsoever.  Obviously, you have a human in<br>
the loop, and it sounds like there's something manual about it..<br><br>
> >> - the version number would lose information about the number of commits of<br>
> >> the given package. You may argue that it's not exact, but it still gives a<br>
> >> good estimate.<br>
> ><br>
> > This is an easy number to calculate when the file is open and include<br>
> > in header descrption of a VersionInfo...  For example:<br>
><br>
> Yes. The problem is that the number would not exists outside the image.<br>
> When you only have a file on your disk, that information is not available.<br>
<br>
Heh, you keep raising your "requirements" to calculate these obscure<br>
metrics, it starts to feel like a game.  :)  Okay, assuming you have a<br>
complete repository, how about:<br>
<br>
    ls -1 PackageName-*.mc? | wc -l<br>
<br>
Without knowing what use-case needs this metric under such conditions,<br>
it's hard to know what the best solution would be...<br>
<br>
Keep in mind, with my proposal you would be able to "eyeball" a<br>
different metric that could be useful -- the age of the version..<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 (684): Monticello-eem.684<br>
> ><br>
> >> - it solves a problem that happens way too infrequently (different<br>
> >> packages with the same name)<br>
> ><br>
> > It's actually not.  Working in Squeak on two separate laptops (i.e.,<br>
> > home vs. work) is very common, but incredibly onerous because it<br>
> > *frequently* results in duplicate package names.<br>
><br>
> Right, but you'll notice it as soon as you try to commit it into your<br>
> repository.<br>
<br>
By then it's too late!  Please tell me what you would do in that<br>
scenario, when you went to merge and found a couple of name conflicts<br>
buried 4 or 5 deep in the ancestry of both chains?  Ignore it and<br>
leave holes in your repository?  Or rewrite history?<br>
<br>
It only takes this scenario to happen once to understand the level of<br>
hassle or compromise it forces one into.<br>
<br>
> > This is more than "solving a problem",  it enables a new power of<br>
> > simultaneous streams of development on the same packages in different<br>
> > images -- with no danger of duplicates.<br>
> ><br>
> > Moreover, it's an elegant way for Monticello to realize its goal of<br>
> > providing a distributed code model.<br>
><br>
> Yes, but if I were to solve this problem, I would just extend the naming<br>
> scheme:<br>
> Instead of Monticello-cmm.684.mcz, it may as well be<br>
> Monticello-cmm.684.435c7c.mcz, which would preserve the version number but<br>
> extend the name with the first few digits of the UUID (which is actually<br>
> not so good, because of how UUID works, and using e.g. the SHA256 has of the<br>
> source file would be superior, but that would require further MC changes).<br>
<br>
Hey, I really appreciate the alternate suggestion!  I'm interested in<br>
a _solution_ more than a particular implementation.  The suggestion<br>
above sounds like it solves duplicates, but doesn't offer the extra<br>
bonus field encoded into the name, and it also introduces a<br>
more-complex name format that doesn't jibe with the legacy of files<br>
out there.  We would want to make sure older Squeak images could<br>
correctly access repositories with those name formats, and that no one<br>
minded seeing a uuid inserted into their names.<br>
<br>
> >> - you can't commit the same package twice within a minute, which is a<br>
> >> something you do when you want to split multiple changes up into different<br>
> >> commits<br>
> ><br>
> > Of course you can.  This is just the default generated name, the user<br>
> > or system can increment the number as needed.<br>
><br>
> So, this is something the suggested change doesn't support yet, isn't it?<br>
<br>
It supports the user entering whatever name they want.<br>
____<br>
<br>
Maybe it would be best if I tried this out in one of my own packages.<br>
I would just need to tweak MC's code to support it whenever it finds a<br>
package number > 66000, otherwise stay with the old consecutive..<br>
<br>
<br>
 - Chris<br>
<br>
</blockquote></div></div></div>