[squeak-dev] The Inbox: Monticello-cmm.66240.mcz
cunningham.cb at gmail.com
Sun Feb 17 23:42:14 UTC 2019
Chris is still proposing a max 5 digit version number for a file -
reasonable if not ideal
the much longer number they diverged to talking about is the squeak image
version number which is used but much less often. that is the sum of all
loaded package versions + the hard code number representing older unloaded
packages. this would grow much larger.
On Sun, Feb 17, 2019, 13:52 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com wrote:
> 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
>> > 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
>> 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
>> > 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
>> 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
>> > >> 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 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...
More information about the Squeak-dev