sshrepo: don't quote obviously safe strings (
issue2983)
This restores compatibility with hg-over-ssh servers that don't parse
commandlines as sh does but works ok in the most common cases.
bookmarks: update and updatecurrentbookmark return status
This makes bookmarks.update() and bookmarks.updatecurrentbookmark() return
True or False to indicate whether the bookmark was updated or not. This allows
callers to e.g. abort if the update failed.
merge: make 'nothing to merge' aborts consistent
Makes the 'nothing to merge' abort messages in commands.py consistent with
those in merge.py. Also makes commands.merge() and merge.update() use hints.
The tests show the changes.
largefiles: optimize performance of status on largefiles repos (
issue3136)
util: fix url.__str__() for windows file URLs
Before:
>>> str(url('file:///c:/tmp/foo/bar'))
'file:c%3C/tmp/foo/bar'
After:
>>> str(url('file:///c:/tmp/foo/bar'))
'file:///c%3C/tmp/foo/bar'
The previous behaviour had no effect on mercurial itself (clone command for
instance) because we fortunately called .localpath() on the parsed URL.
hgsubversion was not so lucky and cloning a local subversion repository on
Windows no longer worked on the default branch (it works on stable because
de7e2fba4326 defeats the hasdriveletter() test in url class).
I do not know if the %3C is correct or not but svn accepts file:// URLs
containing it. Mads fixed it in
de7e2fba4326, so we can always backport should
the need arise.
convert: tolerate trailing spaces on map files
A convert run with a branchmap made with
echo default namedbranch > branchmap
on Windows fails silently and surprisingly; it actually
adds a space after 'namedbranch', so it ends up mapping
"default namedbranch" to "".
This also affects splicemaps, since the same parser is used
for both.
test-svn-subrepo: fix reference output for svn 1.7
I modified check-code.py "$?" detection because I thought my use was legit, we
cannot test exit status of pipelines commands except for the last one without
this. So it now tolerates "[$?" which is unlikely to be added by mistake.
Tested on:
- OSX + svn 1.7.1
- Linux + svn 1.6.12