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 <asqueaker at gmail.com> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190217/20b3ed8a/attachment.html>