> The basic unit we deal with in MC is the MCZ file (or MC version if it's not in a file). With proper branching, this basic unit *carries the information* of which branch it's from.

Agreed.  As, it does, its full ancestry.

> By only putting a version in a different repo, the branch info is not attached to the version itself, it cannot be acted
 upon properly without utmost care by the user. Which *did* lead to a
version getting submitted to the wrong repo.

What do you mean by "wrong repo"?  Someone submitted something to the
Inbox for Spur, _because_ there was no SpurInbox repository for him to
put it.  If there were, then that's where it would have been saved --
because anyone developing Spur will have set up their Monticello UI
with the Spur repositories, making it very hard to accidently commit
to the wrong repository.

If we want to clone all the abilities of Trunk _including_ the Inbox
submission, then we gotta give Eliot all the same resources, e.g., a
SpurInbox too.

> And there is *no way to tell*, unless stuff randomly breaking when you load that version is considered fine.

C'mon Bert, even in a single-repository ecosystem, I'm not buying
that.  This whole event is pretty low-impact, wouldn't you say?  How
often do you go loading an Inbox package without saving your image
first?  Plus, there _is_ a way to tell -- if something is worth
documenting in a version-name, then worth documenting in the
version-comments.  We're talking about 2-4 clicks to check the
ancestry.

But that's moot anyway because we're discussing a correct clone of the
trunk ecosystem for Spur, one that includes a SpurInbox.  Copying
select versions between the two could be set up to be automatic or
deliberate, as needed, but the key is that it's using **existing** MC
code and infrastructure to do that.

> If Eliot had used proper branch names, this would not have happened. It's partly my fault because he asked me weeks ago if using multiple repos was the way to go and I did not foresee the problems this would cause.

By contrast, the "Branches" approach wants to stuff everything into
one big repository, and then employ some obscure, "implicit" filtering
mechanism, known as "branches", to serve as the partition between the
two projects.  It's an additional concept whose implementation has
extended its tendrils into many classes in the form of redundant case
tests, and very much complicated the ability for tools to remain
simple and Repository-independent.

What do you think of Eliot's recently introduced preference,
"Secondary Update URL"?  Consider that it will be empty for 99% of
Squeak users and, even for Eliot after he's long transitioned to Spur.
When will this ever be used or ripped out in the future?  Probably
never to both questions.  So I consider this as another example of
low-value infrastructure (but at least harmless unlike the branches).
I bet even Eliot would agree its hacky tacky, but it was considered a
necessary evil at the time because we couldn't / didn't think hard
enough for a way to avoid doing it.  Separate repository anyone?

Fewer parts and concepts is better than more, isn't it?

> With the evidence we have available now we can conclude that relying on separate repos is not enough. Being explicit about the branch is a Good Idea.

We should collect evidence when its set up properly -- the same as trunk.

PS -- instead of just responding with "why we can't", I really hope
you'll give this proposal a fair shake.  I have zero ego about this
and I hope you do too.