[PATCH 0 of 2] new log option --tolerant

Jason Harris jason.f.harris at gmail.com
Sat Dec 11 21:19:59 CST 2010


Ok I have come across the following issue in MacHg. (The issue is general to GUI
clients but I will use MacHg in the description below. Substitute your favorite
other GUI client which does things in a multithreaded way.)

I need Mercurial to treat the revision ranges I pass it tolerantly. The
situation arises in MacHg because of its ubiquitous use of multi-threaded-ness
and some history altering operations, like strip, histedit, collapse, rebase
with --collapse, etc. These history editing operations can decrease the number
of changesets after an operation. Now just after the operation the "hg tip"
command might be still loading and yet MacHg might need to also fire off some
"hg log" commands to update the history view of the repository. Ie we might be
issuing in essence a command like hg log --rev "0:23" --template "<stuff>" but
maybe after the operation the repository only has 19 changesets in it. We don't
want this 'hg log' command we just issued to fail with an abort: unknown
revision '23'!

Such an aborted log command is possible to handle in MacHg but it is many times
more difficult than having some flexibility option in Mercurial. I can go into
details but its outside the scope of this patch so if need be I will tackle the
details of why its much harder to clean up post aborted log than it is to have
an option --tolerant here.

Ok so thats the reason for this patch. I have included a test output as well.

So saying all of the above I can think of a number of ways to handle this. 
(a) We could just make this happen automatically for --noninteractive.
(b) Make this happen when we combine --noninteractive and HGPLAIN...
(c) introduce a local --tolerant option for log only.
(d) introduce a global option --tolerant which applies to a lot of commands
(e) Do the right thing but issue a warning that can be suppressed by --quite

I have taken the least invasive approach here and gone with option (c) in this
patch. In any case this will get the ball rolling and then crew members can discuss
from here the best way to go about handling the intent of this patch.


More information about the Mercurial-devel mailing list