>> I'm having trouble understanding the contexts of those examples.  What
>> am I going to do with my package-cache that has branches saving the
>> day for me?  Sending a version in an e-mail?  I would probably send a
>> link to a config or a repository.  Even if I did send a MCZ Version in
>> an email, the email would state what its for, any branch tag would be
>> redundant..
>>
>> PS -- And, heck, even just the _contextual_ info (e.g., time and
>> author) kinda gives it away anyway!  Frank already said if there's
>> more than 2 branches going on simultaneously, that's a problem.  So,
>> KNOWING what Eliot is working on these last months, if you see
>> "Collections-cmm.521" and "Collections-eem.523", which one do you
>> suppose is for Spur?
>
> That's the issue.  If we have two repositories, trunk & spur, then they will
> be for Spur if they're in the spur repository and for trunk if they're in
> the trunk repository.  If they're in your package-cache you haven't a hope
> in hell of telling which is which, except if one has been patched by the
> Spur bootstrap, in which case the checkin comment will say
> "Collections-cmm.521 patches by SpurBootstrapMonticelloPackagePatcher
> Cog-eem.158", which isn't very obvious.

But you never answered --  What does the package-cache have to do with
anything?  Why is it so important to even be a factor in this
discussion?

Y'all keep coming up with these "non-problems" and then "solving" them
with "branches".  Its crazy.

Another thing I was never clear about -- the output of your
patch-utilities -- does it produce a NEW version with the old one as
an ancestor (as it should!)?  Or are you actually modifying the
original but keeping the same UUID, same author, same version?  I
think destroying the original is very bad idea -- but I can see that,
if you are, why it would make you want to employ "branches" to bail
you out...  OMG, hacking MC with even more unnecessary precedents?!
(shudder) Please tell me I'm wrong!  Eliot, there's a _reason_
something is a *Version* -- it should never ever be modified.

> If we go with branches, which I'm finally accepting is the only sane way to
> go, we'll know they're both for trunk, and their duals are
> "Collections.spur-cmm.521" and "Collections.spur-eem.523".  So I'll modify
> the bootstrap to produce branched packages, and modify the update process to
> upload these to trunk.  We can nuke the spur repository.  It was a useful
> learning experiment.  We can nuke the primary/secondary repository support.
> It was an uninformed attempt at a fix.
>
> Agreed?

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

And no one but me has acknowledged the costs of branches.  Are you
actually "weighing the cost" or do you think branches are "free"?

>> So, the value of branch-tag seems really really
>> low -- practically non-existent.  Please enlighten me, what use-case
>> do branches save the day and pay for their forever-cost?
>
> I have to say they're hugely valuable.  They've allowed me to develop Cog
> (in VMMaker.oscog).  They provide me a way of placing branched versions of
> Kernel, Collections and System alongside their trunk siblings.

Again, you stated the obvious "what" it does, above, but not _why_
it's valuable, and why it couldn't be done another way..  Sad.