MC true ancestors false positive?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

MC true ancestors false positive?

Nicolas Cellier
Still cleaning the inbox...
I see this:

Name: Monticello-bf.540
Author: bf
Time: 3 May 2013, 12:06:01.01 pm
UUID: 759525eb-5ca8-4ab2-9e4a-bddc7d0680dc
Ancestors: Monticello-bf.532, Monticello-fbs.539

This is my allow-partial-commits mod, improved to always diff to the target repository, and merged with the latest fbs.359 trunk version.

It is not signalled as false ancestor, so it means that this ancestor is in history, or another package in history has same UUID (unlikely!).

But in trunk there is a different package:

Name: Monticello-bf.540
Author: bf
Time: 4 May 2013, 8:13:11.165 pm
UUID: b8904753-a5e5-4061-a912-49480229e91a
Ancestors: Monticello-fbs.539

Add MCReorganizationPreloader which can resolve moves between arbitrary packages.

Do we really have two different Monticello-bf.540 in ancestors or what?
Is there a morphic tool to visualize the ancestry graph?



Reply | Threaded
Open this post in threaded view
|

Re: MC true ancestors false positive?

Chris Muller-3
On Wed, Feb 13, 2019 at 10:46 AM Nicolas Cellier
<[hidden email]> wrote:

>
> Still cleaning the inbox...
> I see this:
>
> Name: Monticello-bf.540
> Author: bf
> Time: 3 May 2013, 12:06:01.01 pm
> UUID: 759525eb-5ca8-4ab2-9e4a-bddc7d0680dc
> Ancestors: Monticello-bf.532, Monticello-fbs.539
>
> This is my allow-partial-commits mod, improved to always diff to the target repository, and merged with the latest fbs.359 trunk version.
>
> It is not signalled as false ancestor, so it means that this ancestor is in history, or another package in history has same UUID (unlikely!).
>
> But in trunk there is a different package:
>
> Name: Monticello-bf.540
> Author: bf
> Time: 4 May 2013, 8:13:11.165 pm
> UUID: b8904753-a5e5-4061-a912-49480229e91a
> Ancestors: Monticello-fbs.539
>
> Add MCReorganizationPreloader which can resolve moves between arbitrary packages.
>
> Do we really have two different Monticello-bf.540 in ancestors or what?

Yes.  Playing fast and loose with our trunk commit guidelines has
resulted in some permanent damage to the ancestry.

Monticello repositories don't support duplicate names, but it also
can't easily check against that so it has to be up to the committer
(although I suppose it could try!).

> Is there a morphic tool to visualize the ancestry graph?

No.  We should work toward eliminating duplicate names rather than
supporting them.


 - Chris

Reply | Threaded
Open this post in threaded view
|

Re: MC true ancestors false positive?

David T. Lewis
In reply to this post by Nicolas Cellier
On Wed, Feb 13, 2019 at 05:46:17PM +0100, Nicolas Cellier wrote:

> Still cleaning the inbox...
> I see this:
>
>
> *Name: Monticello-bf.540Author: bfTime: 3 May 2013, 12:06:01.01 pmUUID:
> 759525eb-5ca8-4ab2-9e4a-bddc7d0680dcAncestors: Monticello-bf.532,
> Monticello-fbs.539This is my allow-partial-commits mod, improved to always
> diff to the target repository, and merged with the latest fbs.359 trunk
> version.*
>
> It is not signalled as false ancestor, so it means that this ancestor is in
> history, or another package in history has same UUID (unlikely!).
>
> But in trunk there is a different package:
>
>
> *Name: Monticello-bf.540Author: bfTime: 4 May 2013, 8:13:11.165 pmUUID:
> b8904753-a5e5-4061-a912-49480229e91aAncestors: Monticello-fbs.539Add
> MCReorganizationPreloader which can resolve moves between arbitrary
> packages.*
>
> Do we really have two different Monticello-bf.540 in ancestors or what?
> Is there a morphic tool to visualize the ancestry graph?

No, such a tool does not exist. But I think that it would be very helpful
to have one.

Many years ago, we could use the combination of Connectors and GraphViz,
an external program driven by OSProcess, to make nice interactive graphs
in Squeak. This might be a good way to visualize the ancestry.

In principle, the conflicting names can be moved to treated inbox or
just deleted. But conflicting names do happen, and I think it is helpful
if the tools can help indentify these cases, and to visualize the actual
ancentry graph.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: MC true ancestors false positive?

Nicolas Cellier
With the small utility that i just added, I did find the merge of the two Monticello-bf.540
It's Monticello-topa.599 from september 2014.
So we effectively have both bf.540 packages as valid ancestors, one in trunk, the other in the inbox, but we cannot have them both in same repository.
We could perform some chirurgy, renaming inbox/Monticello-bf.540 with a branch name => Monticello.partialCommit-bf.540
But then, we will have to apply this chirurgy to every offspring down to working copy, and republish every offspring package...
Since 2014, that's quite some progeny!

I guess that we should also apply this to the inbox offsprings, and let the responsibility of updating any other replication to their owner...
We can as well ignore the problem, move inbox/Monticello-bf.540 to TreatedInbox, since MC is robust to missing packages...
Thoughts?


Le jeu. 14 févr. 2019 à 02:07, David T. Lewis <[hidden email]> a écrit :
On Wed, Feb 13, 2019 at 05:46:17PM +0100, Nicolas Cellier wrote:
> Still cleaning the inbox...
> I see this:
>
>
> *Name: Monticello-bf.540Author: bfTime: 3 May 2013, 12:06:01.01 pmUUID:
> 759525eb-5ca8-4ab2-9e4a-bddc7d0680dcAncestors: Monticello-bf.532,
> Monticello-fbs.539This is my allow-partial-commits mod, improved to always
> diff to the target repository, and merged with the latest fbs.359 trunk
> version.*
>
> It is not signalled as false ancestor, so it means that this ancestor is in
> history, or another package in history has same UUID (unlikely!).
>
> But in trunk there is a different package:
>
>
> *Name: Monticello-bf.540Author: bfTime: 4 May 2013, 8:13:11.165 pmUUID:
> b8904753-a5e5-4061-a912-49480229e91aAncestors: Monticello-fbs.539Add
> MCReorganizationPreloader which can resolve moves between arbitrary
> packages.*
>
> Do we really have two different Monticello-bf.540 in ancestors or what?
> Is there a morphic tool to visualize the ancestry graph?

No, such a tool does not exist. But I think that it would be very helpful
to have one.

Many years ago, we could use the combination of Connectors and GraphViz,
an external program driven by OSProcess, to make nice interactive graphs
in Squeak. This might be a good way to visualize the ancestry.

In principle, the conflicting names can be moved to treated inbox or
just deleted. But conflicting names do happen, and I think it is helpful
if the tools can help indentify these cases, and to visualize the actual
ancentry graph.

Dave




Reply | Threaded
Open this post in threaded view
|

Re: MC true ancestors false positive?

Chris Muller-3
> With the small utility that i just added, I did find the merge of the two Monticello-bf.540
> It's Monticello-topa.599 from september 2014.
> So we effectively have both bf.540 packages as valid ancestors, one in trunk, the other in the inbox, but we cannot have them both in same repository.
> We could perform some chirurgy, renaming inbox/Monticello-bf.540 with a branch name => Monticello.partialCommit-bf.540
> But then, we will have to apply this chirurgy to every offspring down to working copy, and republish every offspring package...
> Since 2014, that's quite some progeny!
>
> I guess that we should also apply this to the inbox offsprings, and let the responsibility of updating any other replication to their owner...
> We can as well ignore the problem, move inbox/Monticello-bf.540 to TreatedInbox, since MC is robust to missing packages...
> Thoughts?

-1 unless you're willing to address the underlying problem of
Monticello generating duplicate names.  Four alphanumeric digits can
get us until 2022...

     36rZZZZ minutes fromNow    " 2022-04-27T03:47:51.947721-06:00"

... after which we'd have to add a fifth, which would last more than a
century.  Please consider it.

In the meantime, I had some thoughts about rectifying this symptom
too.  I think we should make a hack which establishes a variable
somewhere (possibly MCHttpRepository) that can keep an "exceptions
list" for certain versions which will tell it to look in another
repository for the offending version uuid.

 - Chris

Reply | Threaded
Open this post in threaded view
|

Re: MC true ancestors false positive?

Bert Freudenberg
In reply to this post by Chris Muller-3
On Wed, Feb 13, 2019 at 3:45 PM Chris Muller <[hidden email]> wrote:

Monticello repositories don't support duplicate names

... but only because we choose to give way more meaning to the version name than originally intended.

E.g.,  MCDictionaryRepository, which is pretty much untouched since Avi's implementation in 2003, happily stores two versions with the same name.

That's because #versionWithInfo: is the basic interface to a repository. In fact, in an MCRepositoryGroup it should be fine to have have different versions with the same name in two repositories, since it uses the same interface. If this isn't supported anymore, that's a bug.

The only significant identifier of a MCVersion is its MCVersionInfo, and that is identified by its ID, not its version name (cf.  MCVersionInfo>=).

, but it also
can't easily check against that so it has to be up to the committer
(although I suppose it could try!).

> Is there a morphic tool to visualize the ancestry graph?

No.  We should work toward eliminating duplicate names rather than
supporting them.

We should try to avoid them (and we are trying - we put that commit warning about same or newer names in a long time ago) but MC being a distributed system there is no way to avoid this completely, so we should support it properly, as originally designed.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: MC true ancestors false positive?

Eliot Miranda-2
On Mon, Feb 18, 2019 at 1:31 PM Bert Freudenberg <[hidden email]> wrote:
On Wed, Feb 13, 2019 at 3:45 PM Chris Muller <[hidden email]> wrote:

Monticello repositories don't support duplicate names

... but only because we choose to give way more meaning to the version name than originally intended.

E.g.,  MCDictionaryRepository, which is pretty much untouched since Avi's implementation in 2003, happily stores two versions with the same name.

That's because #versionWithInfo: is the basic interface to a repository. In fact, in an MCRepositoryGroup it should be fine to have have different versions with the same name in two repositories, since it uses the same interface. If this isn't supported anymore, that's a bug.

The only significant identifier of a MCVersion is its MCVersionInfo, and that is identified by its ID, not its version name (cf.  MCVersionInfo>=).

, but it also
can't easily check against that so it has to be up to the committer
(although I suppose it could try!).

> Is there a morphic tool to visualize the ancestry graph?

No.  We should work toward eliminating duplicate names rather than
supporting them.

We should try to avoid them (and we are trying - we put that commit warning about same or newer names in a long time ago) but MC being a distributed system there is no way to avoid this completely, so we should support it properly, as originally designed.

- Bert -

+1
 
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: MC true ancestors false positive?

Chris Muller-3
In reply to this post by Bert Freudenberg
>> Monticello repositories don't support duplicate names
>
>
> ... but only because we choose to give way more meaning to the version name than originally intended.
> E.g.,  MCDictionaryRepository, which is pretty much untouched since Avi's implementation in 2003, happily stores two versions with the same name.
>
> That's because #versionWithInfo: is the basic interface to a repository. In fact, in an MCRepositoryGroup it should be fine to have have different versions with the same name in two repositories, since it uses the same interface. If this isn't supported anymore, that's a bug.

No, because we aren't enabled by the most-capable Repository type,
we're *constrained* by the limitations of the least-capable ones.  The
_union_ of those limitations even.

In this case, FileBasedRepository was enough from the get-go to blow
up your little domain-utopia where "#versionWithInfo: is the basic
interface to a repository."   In that world, I agree with you, but the
real-world got in the way.  The simplicity of FileBased is what
enabled MC to spread as far and among as many users it has.

Now that its out of control, one of the only ways we can upgrade it
lies in the model or the client, not the infrastructure's relation to
the domain.  It's disappointing to see us be this closed to such
massively-leveraged idea so quickly.

> The only significant identifier of a MCVersion is its MCVersionInfo, and that is identified by its ID, not its version name (cf.  MCVersionInfo>=).

Only in domain-utopia.  In the real-world, the names play a very
important role in the existing infrastructure, serving up the
use-cases we demand from the system.

>> , but it also
>> can't easily check against that so it has to be up to the committer
>> (although I suppose it could try!).
>>
>> > Is there a morphic tool to visualize the ancestry graph?
>>
>> No.  We should work toward eliminating duplicate names rather than
>> supporting them.
>
>
> We should try to avoid them (and we are trying - we put that commit warning about same or newer names in a long time ago)

That's slow and ineffective.  Here's a problem scenario illustrating why:

   - I have multiple Squeak systems at different client sites.
   - I do some work at one site.  Make an improvement and save Collections-123.
   - I do some work at a another site.  Totally different application
with different needs for Collections.
   - I make an improvement and save Collections-123.
   - Both improvements are generally useful.
   - Repeat the above several times, get up to Collections-127 and -125.
   - The changes are generally useful, so now a week later I wish to
merge them into trunk.
   - BOOM.  Now I have a big mess and forced to choose between
rewriting history at least one company, or suffer a duplicates in the
ancestry and holes in the repository.

> but MC being a distributed system there is no way to avoid this completely,

Unless I'm missing something, the six-digit proposal essentially
solves it.  With readability essentially fixed, it's hard to know what
the issue still is.

Thankfully I still have one more idea for another, totally different,
solution, which you may like better given your stated expectation for
MC to handle duplicate names..



 - Chris

> so we should support it properly, as originally designed.
>
> - Bert -
>
>