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


>
> - 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190219/f55c138c/attachment.html>