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