On Sat, Jul 14, 2018 at 05:42:32PM -0500, Chris Muller wrote:
> >> So, Levente/Chris/David,
> >> to fix this - do we delete the kks.801 from trunk, or alter kks.803 in the
> >> inbox (which seems to fix the issue) to have both dtl.802 (it's current
> >> parent) and kks.801 as both of its parents, which I believe
> >> would solve the 'multi head' issue.
> >
> > Neither. The proper solution is to create a new version which merges the two
> > branches. If the fix is in kks.803, then xxx.804 will contain the fix and
> > have both kks.803 and kks.801 as ancestors.
> 
> Wow.
> 
> > It is well known that the MC model was not designed for projects of this size.
> 
> Right.
> 
> > But it would save almost nothing if that version were removed form the ancestry.
> 
> Your suggestion above puts "almost nothing" at up to no less than
> three new versions in the ancestry for a one method fix.  It is not
> just about disk space, or memory space, or exacerbating our unscalable
> dimensions, but clutter, too.  Those are my rationale's for deleting.
> I didn't catch any solid rationale for the idea of littering the
> ancestry when we have the opportunity not to.
> 

Levente,

You are right, I should have simply comitted a new version of the package.
I was trying to "bypass" the problem, but that was a mistake because it
caused problems for the update stream. It would have been better (as you
said) to have simply committed a new version.

Chris,

It is good to keep the update stream as clean as possible as you explained,
but overall I think that Levente is right. In most cases, attempting to
rewrite version history causes more problems than it solves.

Dave