<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 19, 2019 at 3:27 PM Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">On Tue, Feb 19, 2019 at 3:08 PM Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> I don't understand how Monticello relies on version names to be unique for proper operation?<br>
<br>
Because MCDirectoryRepository relies on a single directory in your<br>
filesystem, which can't store any two version with the same name.<br></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">It happily stores two versions with the same version name, just not with the same filename. E.g. as mcc and mcd. Or multiple mcd with different bases even.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Therefore, it currently can't possibly represent a complete<br>
representation of the code model once a duplicate happens.<br></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">If you think about how file names and version names relate, it actually is not only possible, but trivial:</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">'Monticello-bf.540.mcz' asMCVersionName = 'Monticello-bf.540(1).mcz' </div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"> ==> true</div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">'Monticello-bf.540(1).mcz'  asMCVersionName versionName</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">==> 'Monticello-bf.540'</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> I thought internally it always worked with the UUIDs?<br>
<br>
For internal ancestral operations, it does, the names are needed to<br>
know which files to access when, say, you request a diff operation.<br></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">If I read the code correctly, then all we need to do is upload the second version of 'Monticello-bf.540' as 'Monticello-bf.540(1).mcz' to trunk. Then MC should find both files when looking up the ancestry, it should parse the actual version ID, and use the right one.</div></div></div></div></div></div></div></blockquote><div><br></div><div><3</div><div><br></div><div>+1000.  KISS</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- Bert -</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
 - Chris<br>
<br>
> In other words what are simplest possible steps to reproduce the problem (problems?) which is solved by the proposed change?<br>
><br>
> Bernhard<br>
><br>
> > Am 17.02.2019 um 00:25 schrieb Chris Muller <<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>>:<br>
> ><br>
> > Hi Dave and all,<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>
> >><br>
> >> Hi Chris,<br>
> >><br>
> >> I like the idea of having valid version histories, but I'm not sure<br>
> >> that working with the version number is the best approach. Here's my<br>
> >> take on it overall:<br>
> >><br>
> >> I am reminded of Craig's "Name and Identity are Distinct" approach in<br>
> >> Naiad (<a href="http://wiki.squeak.org/squeak/5618" rel="noreferrer" target="_blank">http://wiki.squeak.org/squeak/5618</a>).<br>
> >><br>
> >> An instance of MCVersionInfo has both a name and an identity. There is<br>
> >> an instance variable for each (#name and #id in class MCVersionInfo),<br>
> >> and they serve different purposes. The name is for human consumption,<br>
> >> and the identity is a UUID for identity. It is probably not a good<br>
> >> idea to conflate the two.<br>
> >><br>
> >> Our file based repositories cheat by assuming that the naming convention<br>
> >> will align with the actual history. This is simple and it works most of<br>
> >> the the time, but not always.<br>
> >><br>
> >> If we want to make this better, then we should invent some new way of<br>
> >> indexing the repositories such that the claimed history matches the<br>
> >> actual (UUID identity based) ancestry.<br>
> ><br>
> > We're all familiar with the model and understand the limitations of<br>
> > names.  But the fact is that the Monticello model has names, and it<br>
> > expects them to be unique for proper operation.  Because of how<br>
> > pervasive it has spread throughout the Squeak ecosystem, you have to<br>
> > work within the constraints of that legacy.  It's not enough that<br>
> > MCFileBasedRepository is expected to work transparently with<br>
> > MCHttpRepository in the future, it has to remain comatible with past<br>
> > files and clients, too.<br>
> ><br>
> > The approach of Monticello-cmm.66240 I just put into the Inbox does<br>
> > that, whilst addressing the readability concerns that were expressed earlier.<br>
> ><br>
> >> I do not know how to do this, and I don't know if it is really even<br>
> >> worth the trouble.<br>
> ><br>
> > If we have a way to fix it so easily, we should responsibly evaluate<br>
> > the potential benefit to Monticello and the community.  "Not worth the<br>
> > trouble" is not a reason, since its already done in<br>
> > Monticello-cmm.66240 -- all you have to do is say "yes"!    :)<br>
> ><br>
> > It's not just about inconvenience,but an inelegant flaw in<br>
> > Monticello's model.  It wants to be "distributed," but it can't handle<br>
> > the most simple use case of working on two different laptops.<br>
> ><br>
> >> But I am sure that it can be done, and I expect<br>
> >> that any such solution should be based on #id and not on #name.<br>
> ><br>
> > No, this is the only solution that maintains Monticellos distribution<br>
> > AND compatibility with the existing legacy.<br>
> ><br>
> > - Chris<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > - Chris<br>
> ><br>
><br>
><br>
<br>
</blockquote></div></div></div></div></div>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>