[PATCH] Sort removes first when applying updates (fixes issues 750 and 912)

[Paul Moore]

On 07/07/2008, Patrick Mézard <pmezard at gmail.com> wrote:
> > I've merged in the test change and resent, but haven't run the tests
> > on Windows. The Windows testing patch queue doesn't apply cleanly to
> > current crew tip, and I'm afraid I don't have time to rebase it
> > tonight.
>
> Done, as of b599557f0347.
>
> I will take a look at this patch as soon as I can.

Thanks (for both of these). I'll try the test suite sometime soon, but
this week is looking really busy, so your help is greatly appreciated.

> > PS Are the Windows testing patches ever likely to be merged into
> > Mercurial, so there's no need for this rigmarole of rebasing and
> > applying the patch series? It's not hard, but I often find it takes
> > more (manual) effort than I have time for, as compared to simply
> > firing off a test run.
>
> Yes and no. The inclusion of these fixes is made on a test basis (and when I am
> in the mood of doing so. Do not hesitate to tell me you feel such or such fix
> could reasonably go in mainline). When I feel the fix is simple enough and
> unlikely to be broken by a Unix committer, I try to commit it. The other approach
> is to change Mercurial or the test suite (including pysh) to make the
> discrepancies disappear. For instance, I embedded paths rewriting code in pysh,
> called on selected mercurial commands. I agree it makes Windows test more
> painful to run.

I see. Thanks for the explanation. Next time I get some free time
(ha!) I'll take a look at how the patch suite is set up, and see if I
can find some way of improving things.

One possibility is that I could try to set up a job to automatically
rebase the patch series. It very rarely seems to need any real
thought, it's just a tedious exercise of pulling the right revision of
crew, applying the patches, then going through the rebasing rigmarole
as described in the wiki. (And it's that first step, of identifying
the right crew revision *before* you start applying the patches, that
always trips me up!) Would that be helpful?

> What is even more annoying is they cannot be run in parallel because the --job
> argument is implemented on top of spawnvpe() and os.wait(). Replacing it (in the
> win32 patch queue) with subprocess does not seem simple. I will take a look at
> the "processing" module, maybe it can solve this.

That would be useful, at the moment the test suite takes too long on
my PC for me to run it as often as I should. Again, I'll look at this
when I get some time and see if I can offer some suggestions.

Paul.