On Mon, Jul 16, 2018 at 10:43 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 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 mey 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.

What problem(s)?