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

Chris Muller ma.chris.m at gmail.com
Sat Feb 16 23:25:08 UTC 2019

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

More information about the Squeak-dev mailing list