Hi,

Am So., 17. Feb. 2019 um 22:53 Uhr schrieb Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

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

Sounds like the inbox treating tools also only show the version name and
not the commit message, at least not until you select a particular
version... is that correct?

When I seek a version anywhere else but in Monticello, I look for the
commit message. I don't have to deal with many pull requests, but I am
regularly reluctant to remember even the three digits of them. ;-) I always
look them up by browsing the pull requests where I see their titles, or I
use the helpful issue reference autocompletion of GitHub that displays the
titles next to the numbers and allows to search them by typing text. In my
opinion, titles and commit messages are far more recognizable than any kind
of number or identifier.

I read that one generalized use case is to take the version name to
somewhere else for reference (as Nicolas and Eliot wrote). I just
re-checked the Monticello repository browser: to copy a version name, you
have to select (and download) the version, highlight the name in the text
box below and press copy. Might be better to have a "copy version name"
command in the pop-up menu of the version list. And a text box in the inbox
treating UI where you can paste it... Going to a particular version in the
repository browser currently requires you to scroll and look for the
version number, or typing its name to filter the list. Both ways really
require you to run the number through your mind, and using the filtering is
awkward on top because after each keystroke, another version gets selected
and downloaded, interrupting your typing. Also, longer numbers with low
variance in the most-significant digits would increase that pain. What
about a go-to text box above or below the list where you can paste a
version name (or UUID in the future?), press enter, and be taken to it, if
present? It could even take you to a different package than the one you
have selected.

Just to be clear: my point is not to criticize your habits and ways to use
the version numbers. But I suspect that the "humanly" requirements imposed
on the numbers and version names indicates that there is a lack in the tool
chain. Or the design, since you currently have to download a version wholly
to get its message and UUID. Improving that might turn out to be better in
the long term than sticking with the status quo. And it might solve more
problems than just the one Chris is trying to solve here.

How much effort would it be to extend the server side of a Monticello HTTP
repository such that it allows to query for the names, UUIDs and message
headlines (and cache that information)? Like back in the days before IMAP,
when you could opt to just fetch the headers of your emails...

Unfortunately extending the tools does not resolve the compatibility issue
with older Squeak images. Or the brevity of the update number, although I
am not yet sure whether this one is really worth saving.

Kind regards,
Jakob


>
> 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/20190218/7a9bd959/attachment.html>