If I call unbundle from the file, which is created with strip, it throws exception. Maybe I'm doing something wrong, so here is a full log: C:\Users\Fed\Documents\Qt>mkdir bug C:\Users\Fed\Documents\Qt>cd bug C:\Users\Fed\Documents\Qt\bug>hg init C:\Users\Fed\Documents\Qt\bug>echo first 1>>text.txt C:\Users\Fed\Documents\Qt\bug>hg add text.txt C:\Users\Fed\Documents\Qt\bug>hg commit -m "first" -u Fed C:\Users\Fed\Documents\Qt\bug>echo second 1>>text.txt C:\Users\Fed\Documents\Qt\bug>hg commit -m "second" -u Fed C:\Users\Fed\Documents\Qt\bug>echo third 1>>text.txt C:\Users\Fed\Documents\Qt\bug>hg commit -m "third" -u Fed C:\Users\Fed\Documents\Qt\bug>hg log changeset: 2:4a2d64180cbd tag: tip user: Fed date: Fri Sep 14 14:54:35 2012 +0400 summary: third changeset: 1:836030e74e9c user: Fed date: Fri Sep 14 14:54:35 2012 +0400 summary: second changeset: 0:0b8ab7606bed user: Fed date: Fri Sep 14 14:54:34 2012 +0400 summary: first C:\Users\Fed\Documents\Qt\bug>echo [extensions] 1>>.hg\hgrc C:\Users\Fed\Documents\Qt\bug>echo mq = 1>>.hg\hgrc C:\Users\Fed\Documents\Qt\bug>hg strip 2 1 files updated, 0 files merged, 0 files removed, 0 files unresolved saved backup bundle to C:\Users\Fed\Documents\Qt\bug\.hg\strip-backup\4a2d64180cbd-backup.hg C:\Users\Fed\Documents\Qt\bug>hg log changeset: 1:836030e74e9c tag: tip user: Fed date: Fri Sep 14 14:54:35 2012 +0400 summary: second changeset: 0:0b8ab7606bed user: Fed date: Fri Sep 14 14:54:34 2012 +0400 summary: first C:\Users\Fed\Documents\Qt\bug>hg unbundle C:\Users\Fed\Documents\Qt\bug\.hg\strip-backup\4a2d64180cbd-backup.hg ** unknown exception encountered, please report by visiting ** http://mercurial.selenic.com/wiki/BugTracker ** Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] ** Mercurial Distributed SCM (version 2.3.1) ** Extensions loaded: mq Traceback (most recent call last): File "hg", line 42, in <module> File "mercurial\dispatch.pyo", line 28, in run File "mercurial\dispatch.pyo", line 65, in dispatch File "mercurial\dispatch.pyo", line 88, in _runcatch File "mercurial\dispatch.pyo", line 740, in _dispatch File "mercurial\dispatch.pyo", line 514, in runcommand File "mercurial\dispatch.pyo", line 830, in _runcommand File "mercurial\dispatch.pyo", line 801, in checkargs File "mercurial\dispatch.pyo", line 737, in <lambda> File "mercurial\util.pyo", line 471, in check File "mercurial\extensions.pyo", line 144, in wrap File "mercurial\util.pyo", line 471, in check File "hgext\mq.pyo", line 3528, in mqcommand File "mercurial\util.pyo", line 471, in check File "mercurial\commands.pyo", line 5759, in unbundle File "mercurial\url.pyo", line 474, in open File "urllib2.pyo", line 400, in open File "urllib2.pyo", line 418, in _open File "urllib2.pyo", line 378, in _call_chain File "urllib2.pyo", line 1310, in file_open File "urllib2.pyo", line 1335, in open_local_file File "mimetypes.pyo", line 294, in guess_type File "mimetypes.pyo", line 355, in init File "mimetypes.pyo", line 259, in read_windows_registry File "mimetypes.pyo", line 249, in enum_types UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128)
The crash here is apparently due to a Python standard library error. The python mimetypes library cannot handle the mimetype configuration on your system. Probably because it gets an encoded string where it expected a unicode string. When it tries to encode the string it first has to decode it - and it can't do that because it doesn't know/use the encoding. The problem might be triggered by some special mime types on your system. You can perhaps workaround the issue by removing some mime registry entry. But it is also seems unfortunate that Mercurial uses url.open for local files - that module is only intended for http. It should probably use some other abstraction that used util.urllocalpath to decide which kind of opener to use.
This is a known Python bug: http://bugs.python.org/issue9291 However, the only reason the MIME database is consulted is that urllib2 wants to add a Content-Type header to local files for us to ignore. So we should fix it on our side as Mads suggests. Affects non-Windows machines too.
Fixed by http://selenic.com/repo/hg/rev/0e2846b2482c Siddharth Agarwal <sid0@fb.com> url: use open and not url.open for local files (issue3624) (please test the fix)
*** Bug 3840 has been marked as a duplicate of this bug. ***
(In reply to comment #3) This code here is a bit bogus, at least when used with non-repo objects as openpath does: http://www.selenic.com/hg/file/c8c3887a24c1/mercurial/hg.py#l83 We should instead be using this code: http://www.selenic.com/hg/file/c8c3887a24c1/mercurial/util.py#l1832 Reopening.
Hi, still having problems with this issue, is there some progress on solving? Currently I'm using Mercurial 2.6.2 64bit for Widnwos.
*** Bug 4115 has been marked as a duplicate of this bug. ***
*** Bug 4125 has been marked as a duplicate of this bug. ***
*** Bug 4159 has been marked as a duplicate of this bug. ***
Fixed by http://selenic.com/repo/hg/rev/b433b43364e4 Siddharth Agarwal <sid0@fb.com> hg.openpath: use url.islocal to tell if the path is local (issue3624) Previously we used hg.islocal, which doesn't work for paths pointing to non-repos, such as patch files. (please test the fix)
*** Bug 4181 has been marked as a duplicate of this bug. ***