<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hi Jakob,<br><div dir="ltr"><br></div><div dir="ltr"><br>On Feb 14, 2019, at 2:12 PM, Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de">forums.jakob@resfarm.de</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Curious that few people in the Git community complain about unmemorable hashes as the commit identifiers. I suppose the difference is in the tools: in Monticello you always see a list of version names, wheras in Git each entry in the log is always accompanied with the headline of the commit message. The hashes are usually shortened to the first seven digits for human consumption. Actually it is the same in Subversion already: you never get a list of the revision numbers alone when you have to select or find some revisions.<div><br></div><div>Concerning local directory repositories (and maybe the HTTP ones): again in Git and Subversion, hardly anybody ever looks at the illegible internal data structures in the .git and .svn directories or the Subversion repository folder and everybody is perfectly fine with that (and sending patches via email if they must). In ENVY you can use whatever you like as the version names, the true version identifier is a timestamp (and the name of the object being versioned), and all of it is hidden in the repository blob. But in Monticello and especially its "file-based" repositories the version names have been made so prominent that they must meet the additional requirement of looking nice in a directory listing. How unfortunate.<br></div></div></div></blockquote><div><br></div>That’s not the use case.  I think the directory listing is a straw man.  The use cases that I have most often are<div>- telling someone which version to load or which version contained a specific change.  Being able to say “1234”, which I can remember and repeat accurately, instead of 4163820683965, which I cannot, is a key difference</div><div>- writing down in a git commit for generated sources from which MC version a particular set of sources were generated from.  I want that information to be easy to write abc easy to read.</div><div><br></div><div><br><blockquote type="cite"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Do., 14. Feb. 2019 um 22:40 Uhr schrieb Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@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 dir="ltr"><br></div><div dir="ltr"><br>On Feb 14, 2019, at 1:07 AM, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Hi Chris,</div><div>i don't like this change because it looses a very important thing: READABILITY</div></div></div></blockquote><div><br></div>+1.  And memorability; impossible to remember these accurately.  And writability, for the same reason.<div><br></div><div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Monotonicity doesn't count as long as you have a tool that can sort out the ancestry.</div><div>Since we always browse the versions thru some MC tools it's superfluous.</div><div>Monotonicity is mainly for helping us poor humans to quckly identify the relationship between two packages in the graph.</div><div><br></div><div>This is only going to work with 3 to 5 figures in version number.</div><div>With 10 figures, this is ruining our brain and just does not work.</div><div>Please revert or put in inbox purgatory while we have a chance to discuss it.</div><div><br></div><div>As for uniqueness, this is a small problem.</div><div>As long as we have unique ID, then we should use that for storing and retrieving a package.</div><div>The ID is stored in the ancestry, so it's just a matter of using the ID as filename in the backend rather than the ambiguous package name.</div><div>It's more complex because we have to change our servers and protocols, but it would be the right thing to do.<br></div><div>I think that you are doing the easy but and not the right one with your quick and clever hack.<br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 14 févr. 2019 à 05:23, Chris Muller <<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@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">HI Eliot,<br>
<br>
> > On Feb 13, 2019, at 7:13 PM, Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> wrote:<br>
> ><br>
> > What are the two most-important properties we want from our<br>
> > versionNumber?  Monotonicity and uniqueness.  The current scheme only<br>
> > provides the former, this uses DateAndTime now utcMicroseconds to<br>
> > provide the latter, too.  As a bonus it also happens to encode the<br>
> > save timestamp into the VersionName, so available without having to<br>
> > open the file.<br>
> ><br>
> > I admit it looks intimidating given what we're used to seeing, but<br>
> > what of the added safety and utility?<br>
><br>
> It is trumped by the illegibility.<br>
<br>
Not as bad as it appears, since the high-order digits will be the same<br>
between version #'s, plus, second-resolution should be sufficient, so<br>
versions in a list would actually look like this:<br>
<br>
    Monticello-cmm-1550203798<br>
    Monticello-cmm-1550117398<br>
    Monticello-cmm-1550030998<br>
<br>
Whilst still retaining all of the utility.  Maybe even a setting in<br>
the tools could hide the high-order digits in the UI if we wanted...<br>
We're already into 4 digits in our version #'s anyway so....<br>
<br>
> When was the discussion around this change?<br>
<br>
You're participating in it now.   :)<br>
<br>
There was another change to earlier today that you may be interested<br>
in asking that question about too, since it changed 19-year old<br>
SequenceableCollection>>#= with a one-day old replacement and actually<br>
went into trunk.  This one is in the Inbox.<br>
<br>
> I’ve been out if things (apologies) but I find this change quite horrible.<br>
<br>
I understand this initial gut reaction, but I hope you'll think and<br>
sleep on it, and help think about the problem and some alternative<br>
solutions you like better.  VersionName uniqueness is important for<br>
the Monticello model.<br>
<br>
Best,<br>
  Chris<br>
<br>
</blockquote></div></div>
</div></blockquote><blockquote type="cite"><div dir="ltr"><span></span><br></div></blockquote></div></div><br>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div dir="ltr"><span></span><br></div></blockquote></div></body></html>