> > 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