Re: [Gnu-arch-users] Sub-optimal ordering of rev-building in star-merge

[Tom Lord]

    > From: Charles Duffy <address@hidden>

    > On Mon, 2004-03-08 at 21:42, Stefan Monnier wrote:
    > > - Aha the latest is 142, so let's built that.
    > > - Aha the common ancestor is 135 so let's build that.

    > > Since the second came after the first, 142 was build from 59 by applying
    > > patches 60->142, while 135 was built from 59 as well by applying patch
    > > 60->135.

    > Ouch.

Right, but don't forget that in the pipeline are abently's changes
for bidirectional building which should wind up helping considerably
with this.

It's isn't, btw, just mindless stupidity that causes the out of order
build.   Arch needs to see 142[*] in order to figure out that 135 is
what's needed.


    > A non-sparse library would have kept its copy of 135 made while building
    > 142, so this issue wouldn't have come up -- which is probably why it
    > hasn't been noticed by other folks previously.

No, it's a well known issue.  You're correct that typical usage
patterns with suitably configured revlibs don't invoke the problem but
every now and again, even with well-managed revlibs, it comes up and
is annoying.

-t



[*] "needs to see 142"

    Strictly speaking, perhaps not.   It could figure out that 135 is
    needed just by looking at log files -- but that would have
    performance issues of it's own.   The bidirectional build stuff
    is the correct general solution -- it keeps the higher-level code
    simpler by making it not matter so much in what order the two
    revisions are requested.