>> Why not tell me what you learned so I can learn too?  I really want to
>> know why the separate spur repository was so bad it has you wanting to
>> hack version-names so they can act as a string-filter "partition" in
>> one big slow repository instead of simply using two repositories (two
>> ecosystems).  I'm not seeing any sanity in that..
>
> OK.
>
> First, making the update scheme handle two repositories is non-trivial.  The
> code needs rewriting, and that is too complex for me.

With simply a temporary ecosystem for spur, I don't see why we
couldn't simply throw it out.  A cron or whatever uses your conversion
utility to regularly convert/copy new submissions from trunk to spur.
A clean separation-along-the-physical-seams rather than making
domain-soup like we're doing.

> Second, the non-branch scheme is at best confusing or at worst clashes in
> places like the package cache.

Yes, I acknowledge that loading stuff from the package-cache would
require a few extra clicks to identify what you wanted to load..  I
guess dedicated local file directory repositories (<-- plurality
important) would be the "normal" way to work offline?

> Third, the branch scheme does all we need already, because it was my
> misunderstanding that a branch name would prevent me removing the branch
> name once we're ready to switch to spur.  That's not the case.  The ancestry
> apparently doesn't include the branch name.

Doesn't it?  See below the ancestry of VMMaker, the transition from
the mainline to the "oscog" branch (54-55) followed by the next
descendant (55-56).  Including the branched-name in the ancestry
actually makes sense to me; since that's the only way a FileBased
repository would be able to efficiently find the ancestral record..

"54-->55 transition into oscog branch."
Name: VMMaker.oscog-eem.55
Author: eem
Time: 26 April 2011, 11:47:29.937 am
UUID: 315353fc-7f75-4b5b-8a43-3a636cb1aa0b
Ancestors: VMMaker-oscog.54

"55-->56 first branched node is ancestor of the next descendant."
Name: VMMaker.oscog-eem.56
Author: eem
Time: 26 April 2011, 5:49:36.229 pm
UUID: fbf17bd2-ddbc-488f-b70d-3b9ba8906430
Ancestors: VMMaker.oscog-eem.55

I'm sure you can still remove the branch-name at some point, but the
record of it having gone through that branch will always be in the
ancestry for posterity.

It seems that I'm the only one who thinks MC branches are not worth
their costs.  Our tools have bugs and limitations w.r.t. branch
support (like the selection-issue you mentioned in the meeting).  That
means we can either put our energy into fixing them, or put energy
into transitioning to something simpler (or, of course, do nothing,
which means we live with the bugs).  I, of course, prefer to simplify,
but since we are already this deep into them, I guess we'll just have
to manage it..