[squeak-dev] The Inbox: Monticello-cmm.1550112371873461.mcz

Eliot Miranda eliot.miranda at gmail.com
Tue Feb 19 17:26:09 UTC 2019


Hi Bernhard,

On Tue, Feb 19, 2019 at 9:13 AM Bernhard Pieber <bernhard at pieber.com> wrote:

> Hi all,
>
> I don't understand how Monticello relies on version names to be unique for
> proper operation? I thought internally it always worked with the UUIDs?
>

You are right.  See Bert's message
http://forum.world.st/MC-true-ancestors-false-positive-tp5095206p5095649.html


>
> In other words what are simplest possible steps to reproduce the problem
> (problems?) which is solved by the proposed change?
>

Jakob posted this:
http://forum.world.st/The-Inbox-Monticello-cmm-66240-mcz-tp5095396p5095647.html


> Bernhard
>
> > Am 17.02.2019 um 00:25 schrieb Chris Muller <ma.chris.m at gmail.com>:
> >
> > Hi Dave and all,
> >
> >>> What are the two most-important properties we want from our
> >>> versionNumber?  Monotonicity and uniqueness.  The current scheme only
> >>> provides the former, this uses DateAndTime now utcMicroseconds to
> >>> provide the latter, too.  As a bonus it also happens to encode the
> >>> save timestamp into the VersionName, so available without having to
> >>> open the file.
> >>>
> >>> I admit it looks intimidating given what we're used to seeing, but
> >>> what of the added safety and utility?
> >>>
> >>
> >> Hi Chris,
> >>
> >> I like the idea of having valid version histories, but I'm not sure
> >> that working with the version number is the best approach. Here's my
> >> take on it overall:
> >>
> >> I am reminded of Craig's "Name and Identity are Distinct" approach in
> >> Naiad (http://wiki.squeak.org/squeak/5618).
> >>
> >> An instance of MCVersionInfo has both a name and an identity. There is
> >> an instance variable for each (#name and #id in class MCVersionInfo),
> >> and they serve different purposes. The name is for human consumption,
> >> and the identity is a UUID for identity. It is probably not a good
> >> idea to conflate the two.
> >>
> >> Our file based repositories cheat by assuming that the naming convention
> >> will align with the actual history. This is simple and it works most of
> >> the the time, but not always.
> >>
> >> If we want to make this better, then we should invent some new way of
> >> indexing the repositories such that the claimed history matches the
> >> actual (UUID identity based) ancestry.
> >
> > We're all familiar with the model and understand the limitations of
> > names.  But the fact is that the Monticello model has names, and it
> > expects them to be unique for proper operation.  Because of how
> > pervasive it has spread throughout the Squeak ecosystem, you have to
> > work within the constraints of that legacy.  It's not enough that
> > MCFileBasedRepository is expected to work transparently with
> > MCHttpRepository in the future, it has to remain comatible with past
> > files and clients, too.
> >
> > The approach of Monticello-cmm.66240 I just put into the Inbox does
> > that, whilst addressing the readability concerns that were expressed
> earlier.
> >
> >> I do not know how to do this, and I don't know if it is really even
> >> worth the trouble.
> >
> > If we have a way to fix it so easily, we should responsibly evaluate
> > the potential benefit to Monticello and the community.  "Not worth the
> > trouble" is not a reason, since its already done in
> > Monticello-cmm.66240 -- all you have to do is say "yes"!    :)
> >
> > It's not just about inconvenience,but an inelegant flaw in
> > Monticello's model.  It wants to be "distributed," but it can't handle
> > the most simple use case of working on two different laptops.
> >
> >> But I am sure that it can be done, and I expect
> >> that any such solution should be based on #id and not on #name.
> >
> > No, this is the only solution that maintains Monticellos distribution
> > AND compatibility with the existing legacy.
> >
> > - Chris
> >
> >
> >
> >
> > - Chris
> >
>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190219/d720a9c1/attachment.html>


More information about the Squeak-dev mailing list