Additional note: if it's just for having reacher lists in ui, we could
transmit head information only, that would enable some improvment already...

Le lun. 18 févr. 2019 à 09:50, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> a écrit :

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