<div dir="auto">Hi Jakob,<div dir="auto">All the information (name id commit message) are available in ancestry.</div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Changing the model is not that obvious. Each package retains a copy of whole history.</div><div dir="auto">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!</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">It means that the server should carry an analysis of available package and ancestry relationship before transmitting these data... Not ideal!</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr">Le lun. 18 févr. 2019 à 00:08, Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de">forums.jakob@resfarm.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_attr">Hi,</div><div dir="ltr" class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">Am So., 17. Feb. 2019 um 22:53 Uhr schrieb Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank" rel="noreferrer">nicolas.cellier.aka.nice@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Hi Chris,</div><div dir="auto">Consciously or not, we use these numbers a lot.</div><div dir="auto">For example, when inspecting the versions in inbox, it's very easy to remember and identify the versions, then select them in <a href="http://source.squeak.org/" target="_blank" rel="noreferrer">source.squeak.org</a> web interface then move to treated inbox.</div><div dir="auto">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, ...<br></div></div></blockquote></div><div dir="ltr"><br></div><div dir="ltr">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?<div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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...</div><div><br></div><div>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.</div></div><div><br></div><div>Kind regards,</div><div>Jakob</div></div><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr">Le dim. 17 févr. 2019 à 21:32, Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank" rel="noreferrer">asqueaker@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> > You mean, instead of 5?<br>
><br>
> Yes, 5 is about the length of the longest sequence of digits one will<br>
> recognize and remember in one shot (it's still easy to miss though).<br>
> 7 would be too long and too error prone: Is it 1342578 or 1345278? Hard to<br>
> tell without looking at those numbers thoroughly, isn't it?<br>
<br>
That's fair.  However, you could easily derive the same 5-digit<br>
version of this number by the sum of the #numberOfAncestors count.<br>
How it's done doesn't really concern Monticello.<br>
<br>
I'm really curious how you're using this number, I almost never pay<br>
that number any attention whatsoever.  Obviously, you have a human in<br>
the loop, and it sounds like there's something manual about it..<br><br>
> >> - the version number would lose information about the number of commits of<br>
> >> the given package. You may argue that it's not exact, but it still gives a<br>
> >> good estimate.<br>
> ><br>
> > This is an easy number to calculate when the file is open and include<br>
> > in header descrption of a VersionInfo...  For example:<br>
><br>
> Yes. The problem is that the number would not exists outside the image.<br>
> When you only have a file on your disk, that information is not available.<br>
<br>
Heh, you keep raising your "requirements" to calculate these obscure<br>
metrics, it starts to feel like a game.  :)  Okay, assuming you have a<br>
complete repository, how about:<br>
<br>
    ls -1 PackageName-*.mc? | wc -l<br>
<br>
Without knowing what use-case needs this metric under such conditions,<br>
it's hard to know what the best solution would be...<br>
<br>
Keep in mind, with my proposal you would be able to "eyeball" a<br>
different metric that could be useful -- the age of the version..<br>
<br>
> > Name: Monticello-cmm.66240<br>
> > Author: cmm<br>
> > Time: 16 February 2019, 4:49:51.685281 pm<br>
> > UUID: 435c7c35-3b22-4f66-b733-070ccd48a980<br>
> > Ancestors (684): Monticello-eem.684<br>
> ><br>
> >> - it solves a problem that happens way too infrequently (different<br>
> >> packages with the same name)<br>
> ><br>
> > It's actually not.  Working in Squeak on two separate laptops (i.e.,<br>
> > home vs. work) is very common, but incredibly onerous because it<br>
> > *frequently* results in duplicate package names.<br>
><br>
> Right, but you'll notice it as soon as you try to commit it into your<br>
> repository.<br>
<br>
By then it's too late!  Please tell me what you would do in that<br>
scenario, when you went to merge and found a couple of name conflicts<br>
buried 4 or 5 deep in the ancestry of both chains?  Ignore it and<br>
leave holes in your repository?  Or rewrite history?<br>
<br>
It only takes this scenario to happen once to understand the level of<br>
hassle or compromise it forces one into.<br>
<br>
> > This is more than "solving a problem",  it enables a new power of<br>
> > simultaneous streams of development on the same packages in different<br>
> > images -- with no danger of duplicates.<br>
> ><br>
> > Moreover, it's an elegant way for Monticello to realize its goal of<br>
> > providing a distributed code model.<br>
><br>
> Yes, but if I were to solve this problem, I would just extend the naming<br>
> scheme:<br>
> Instead of Monticello-cmm.684.mcz, it may as well be<br>
> Monticello-cmm.684.435c7c.mcz, which would preserve the version number but<br>
> extend the name with the first few digits of the UUID (which is actually<br>
> not so good, because of how UUID works, and using e.g. the SHA256 has of the<br>
> source file would be superior, but that would require further MC changes).<br>
<br>
Hey, I really appreciate the alternate suggestion!  I'm interested in<br>
a _solution_ more than a particular implementation.  The suggestion<br>
above sounds like it solves duplicates, but doesn't offer the extra<br>
bonus field encoded into the name, and it also introduces a<br>
more-complex name format that doesn't jibe with the legacy of files<br>
out there.  We would want to make sure older Squeak images could<br>
correctly access repositories with those name formats, and that no one<br>
minded seeing a uuid inserted into their names.<br>
<br>
> >> - you can't commit the same package twice within a minute, which is a<br>
> >> something you do when you want to split multiple changes up into different<br>
> >> commits<br>
> ><br>
> > Of course you can.  This is just the default generated name, the user<br>
> > or system can increment the number as needed.<br>
><br>
> So, this is something the suggested change doesn't support yet, isn't it?<br>
<br>
It supports the user entering whatever name they want.<br>
____<br>
<br>
Maybe it would be best if I tried this out in one of my own packages.<br>
I would just need to tweak MC's code to support it whenever it finds a<br>
package number > 66000, otherwise stay with the old consecutive..<br>
<br>
<br>
 - Chris<br>
<br>
</blockquote></div></div></div>
<br>
</blockquote></div>
</div>
<br>
</blockquote></div>