MC true ancestors false positive?

On Wed, Feb 13, 2019 at 10:46 AM Nicolas Cellier
<[hidden email]> wrote:
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

On Wed, Feb 13, 2019 at 05:46:17PM +0100, Nicolas Cellier wrote:
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

-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

>> 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.

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 -
>
>