[squeak-dev] Monticello and version names and numbers (was: The Inbox: Monticello-cmm.66240.mcz)

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Feb 18 08:50:03 UTC 2019

Hi Jakob,
All the information (name id commit message) are available in ancestry.
Unfortunately, when browsing a remote repository we only get the names,
until we load each individual mcz. This is what is most limiting the
possible ui improvment. That's also why we rely a bit more on name than
others. Also note that we rarely use branch names and don't have GUI
showing the ancestor graph; the ancestry is approximately encoded in
version number (fork is a few versions ahead). We can't remove name feature
without first adding replacement in servers and that's why we reject Chris
proposals: we loose something more important than what we gain.

Changing the model is not that obvious. Each package retains a copy of
whole history.
This redundancy confer the robustness of MC to missing ancestors and
partial history. Note that Pharo did erase this ancestry in each release,
which is really aggressive... you then can't find common ancestors when
porting changes!

If we wan't the server to list more than names, either we pass many
redundant information, wasting bandpass and response time, or we pass only
head information for each mcz, but then loose history chain at each missing
mcz. There are a lot of missing mcz (It's equivalent to a squash, except
that the ancestry keeps track of intermediate commits).

It means that the server should carry an analysis of available package and
ancestry relationship before transmitting these data... Not ideal!

Le lun. 18 févr. 2019 à 00:08, Jakob Reschke <forums.jakob at resfarm.de> a
écrit :

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

More information about the Squeak-dev mailing list