>> Did you notice that I uploaded ALL interim versions of
>> Monticello-cmm.[552-557]?  Why would I do that when technically I only
>> needed to upload 557?
>
> We try to have a continuous "trunk" of versions in the trunk repository. We named it that way, even. But we do not store copies of all branches, because MC doesn't need them, and we don't need them. So versions that got merged into trunk do not need to be in trunk themselves, and for sure not their ancestors.

Bottom line -- if you want to find the diffs between two old versions
in the ancestry, you'll need them both.  For you to assert "for sure
not their ancestors" is wrong -- you CAN'T be sure.  No one knows what
might be needed in the future.

>> Because MC functions depend on the ancestry model matching what's in
>> the repositories.  Keeping all versions supports incremental
>> development and rollback.  Besides that we should just maintain an MC
>> model that is "whole" and operational rather than broken.  Are you
>> concerned about disk space?
>
> No, I am concerned about putting even more restrictions onto Monticello. We have gradually moved from a system with very few assumptions, over a period of non-enforced conventions, to a rigidly enforced one. Version names are an example of that. And now your adding a requirement to have an internet connection all the time because MC can unpredictably request an ancient version. I do not see that as a good idea.

You know what was restrictive about the version names before?  It was
that they were dumb Strings being treated as a multi-field object,
from 10 different places in the code, all similar but slightly
different, and none commented.  It caused paralysis because changes
could not be made safely.  It's why it took weeks for me to dissect
and do the surgery necessary to reify that crap.

Did you know, Bert, that before I did that work, we were "restricted"
to use only FileBasedRepository's.  Now we we have a unified API
between all repository types.

Or, we DID, until recently when you and Eliot slapped that branch-name
in it.  At least it's no longer hidden like it was before
MCVersionName, but MC has no notion of branches anywhere in its
domain.  Guess what?  Projects using your feature are now stuck back
on only FileBasedRepositories once again.

>>> But as soon as you use MC it needs the ancestry anyway.
>>
>> Not all of it.  We're up to version 600+ of Morphic, when was the last
>> time version 1 of Morphic was needed?  But we continue to carry that
>> around, in and out of the system, forever.
>
> It does not need to load these old versions, but it often needs to their version names, and sometimes the UUID, and having the commit message is useful too at times.

Dodge.  Please explain the use-case where Morphic.1 would need to be
consumed by a human or the system.

> You're not doing anything about that need. You're just hiding it out of sight. That's not a solution.

What need?  Hiding what?  Huh?

>>  It's a gradual decline, unsustainable.
>> Levente and I are interested in addressing this.
>
> A noble goal, and I agree we need to work on it, but you're not addressing it.

You obviously didn't read my note to Levente in this thread which
explained the next-step I want to take with this.

>> We haven't lost clarity or simplicity.  That's the nice thing about
>> this solution, it changes _nothing_ about the MC model.  It's very
>> transient, all-in-memory.  There's no disaster scenario.
>
> Wrong. Now just about anything you do can cause a file read or network access because MC is trying to materialize a proxy that shouldn't have been stubbed out in the first place.  Before, each working copy could access its full ancestry data. That is a very serious change of behavior, in my book.

Look, I'm glad you at least agree it's a noble _goal_.  So please give
us a solution, won't you?  Please share your wildest imagination about
how it would be possible to achieve this goal without needing to be
connected to a repository?

Levente has an alternate solution that does not employ proxies.  I
personally like the Proxy solution because it's just a simple "one
off" solution that makes no changes to the MC model.  But realizing
the goal is more important to me than using Proxies.  Perhaps, Bert,
you would approve of Levente's solution or propose one yourself.

Until then, I'll make the purging of ancestry a separate menu item, so
you don't have to select it and you can stay happy.