The Inbox: Monticello-cmm.1550112371873461.mcz

On Tue, Feb 19, 2019 at 3:08 PM Chris Muller <[hidden email]> wrote:

> I don't understand how Monticello relies on version names to be unique for proper operation?

Because MCDirectoryRepository relies on a single directory in your
filesystem, which can't store any two version with the same name.

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.

Therefore, it currently can't possibly represent a complete
representation of the code model once a duplicate happens.

If you think about how file names and version names relate, it actually is not only possible, but trivial:

'Monticello-bf.540.mcz' asMCVersionName = 'Monticello-bf.540(1).mcz' 

 ==> true

'Monticello-bf.540(1).mcz'  asMCVersionName versionName

==> 'Monticello-bf.540'

> I thought internally it always worked with the UUIDs?

For internal ancestral operations, it does, the names are needed to
know which files to access when, say, you request a diff operation.

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.

- Bert -

 

 - Chris

> 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 <[hidden email]>:
> >
> > 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
> >
>
>

Yes, this solution is amazingly simple. It is interesting that it can
take a lot of discussion and analysis to find something like this!

--Hannes

On 2/20/19, Chris Muller <[hidden email]> wrote:
>>> For internal ancestral operations, it does, the names are needed to
>>> know which files to access when, say, you request a diff operation.
>>
>> 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.
>
> Yo!  You're right!!
>
>       'Monticello-bf.540' asMCVersionName = 'Monticello-bf.540(1).mcz'
> asMCVersionName   "true"
>
> Oh my, what a rabbit-hole of a discussion we had if, all along, all we
> had to do was rename the file!  I'm glad we ultimately identified the
> fix (which was right in front of us all along, lol!) and even more
> delighted that we'll be able to make our repositories whole in spite
> of existing duplicates!
>
> Thanks Bert and all!
>
>  - Chris
>
>