there's only one trunk, there should be only one inbox.
branches is right.

-- 
Tobias Pape
sent from a mobile device

Am 18.06.2014 um 05:05 schrieb Chris Muller <asqueaker at gmail.com>:

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