homepage

I got bored of manually changing the svn status command to hg status when testing my patch for #8912, so I made a proper patch once and for all. (Did I already say yay for Mercurial Queues?)

Adding nosy from the other patchcheck bug, hope it doesn’t annoy anyone.

In the absence of formal testing, a few comments on my patch to help
reviewers.
1) If the code is both an svn and hg checkout, hg wins, since it’s not unheard of to use hg on top of svn, whereas the contrary does not make sense to me.
2) The hg status command does not need post-processing like the svn one, since hg status --added --modified will already filter the output, and --no-status means "don’t print A or M at the start of each line".
3) I changed a list comp for a genexp, and used startswith instead of getitem+contains+eq; does not change behavior.
4) I suppressed the unneeded shell=True argument to subprocess.Popen (and made the command string into a list); does not change behavior since there were no globbing or path expansion of any kind.
Testing is easy: Apply the patch, add bad indentation in a Python file, run make patchcheck (./python Tools/scripts/patchcheck.py on OSes without make), profit.

A small suggestion: rather than having bool hg which means Mercurial if true and SVN if false, consider a string valued vc variable with 'svn' for SVN and 'hg' for Mercurial. This way it will be straightforward to add support for other VC systems in the future.

Updated. I also changed two sets to lists, to retain usage. I’m sure that Mercurial won’t print the same filename twice, and I’m nearly sure Subversion won’t either. Retaining order will make the report a bit more readable.

s/usage/order/ *sigh*

The purpose of patchcheck.py is not obvious to me. If it's meant to be used by committers (rather than contributors), than we should wait for the actual hg migration and the definition of our new workflow. Also, we might "need" two separate scripts: one for individual changesets and one for pushes.
("need" is in quotes because I'm not sure anyone actually uses patchcheck.py)

So patchcheck is meant for both contributors and committers. I originally wrote it for me, but it helps make sure the patch is in a reasonable state before someone submits a patch.
As for Hg support, enough people seem to run mq on top of svn to make this a reasonable thing to add now and to change once the transition occurs.

> As for Hg support, enough people seem to run mq on top of svn to make
> this a reasonable thing to add now and to change once the transition
> occurs.
Yes, but the question is what workflow it should assume. If you are
running mq for example (or pbranch, or doing local named branches),
using a simple "hg status" of the working copy will not do the right
thing.
(and, by the way, you can't assume mq is the favourite workflow out of
there: I for example use clones + local named branches instead)

Good point, Antoine. Then I might leave this patch for now and come back to it when we do the Hg transition.

> [...] using a simple "hg status" of the working copy will not do the right thing
I think all of these workflows share a step where you have edits in your working directory that are not in the working dir’s parent changeset. Thus, I argue that hg status is helpful in a majority of cases.
In the long term, it may be better to make patchcheck work on diffs rather than $vcs status (that will be an interesting challenge for me), or something else depending on the future dev policy. That is explicitly what I’m not doing here: I’m doing a straightforward patch to add support for Mercurial in a way that just mimics Subversion, doesn’t mandate one workflow, and doesn’t cost anything.
Now it’s up to you to commit this or set resolution to "later", I won’t argue further or complain. :)

Applied in r85767.

Great, thanks!