[squeak-dev] The Inbox: Monticello-cmm.1550112371873461.mcz
Tobias Pape
Das.Linux at gmx.de
Wed Feb 20 07:57:33 UTC 2019
> On 20.02.2019, at 03:50, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Tue, Feb 19, 2019 at 3:27 PM Bert Freudenberg <bert at freudenbergs.de> wrote:
> On Tue, Feb 19, 2019 at 3:08 PM Chris Muller <asqueaker at gmail.com> 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.
>
> <3
>
> +1000. KISS
>
>
That's not even hacky.
I like it!
Best regards
-Tobias
> - 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 <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
More information about the Squeak-dev
mailing list
|