> So, you would rather break the images of everyone who had updated before
> the suggested removal of the verions?

It doesn't break anything.  The original commit is what broke the
images of the very few who updated, and only for a very short period
of time, because Dave got it removed quickly.  So, what would be nice
now would be for it not to incur a permanent cost on top of that, for
every image for everyone, forever.  I know three more versions seems
like not much, but they add up.

 - Chris

> Thanks for doing it that way, since it's only a temporary minor
> inconvenience for trunk developers to remove the unwanted ancestor
> (assuming they've already updated) vs. making a permanent record of an
> unintended commit.

> >>> 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.
>
> So, you would rather break the images of everyone who had updated before
> the suggested removal of the verions?
>
> Levente
>
> >
> > - Chris