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?

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

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
>