store: remove pointless pathjoiner parameter We can stop pretending that we have to support anything else than '/' for concatenating path elements anywhere. Windows deals just fine with '/' in file paths and we already have plenty of places which produce paths containing '/' anyway when running on Windows.

bookmarks: forbid \0 \r \n : in bookmark names (BC) We restrict : to 1. make it easer to convert bookmarks to git branches, 2. use : later for a syntax to push a local bookmark to a remote bookmark of a different name. \0, \n, \r are fobbidden they are used to separate bookmarks in the bookmark file. This change breaks backward compatbility as ':' was an allowed character in previous versions.

url: merge BetterHTTPS with httpsconnection to get some proxy https validation

tests: test https through http proxy These tests fails for me with Python 2.6(.nothing)

url: always create BetterHTTPS connections the same way

url: refactor BetterHTTPS.connect

url: refactor _gen_sendfile

url: remove test for self.ui in BetterHTTPS We use self.ui unconditionally anyway so we would have noticed if it in some cases wasn't set.

tests: update ssl requirement for test-https.t hgweb requires OpenSSL for serving https.

subrepos: prompt on conflicts on update with dirty subrepos Consider a repository with a single subrepository. The changesets in the main repository reference the subrepository changesets like this: m0 -> s0 m1 -> s1 m2 -> s2 Starting from a state (m1, s0), doing 'hg update m2' in the main repository will yield a conflict: the subrepo is at revision s0 but the target revision says it should be at revision s2. Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus ignore the conflict between the working copy and the target revision. With this change, the user is prompted to resolve the conflict by choosing which revision he wants. This is consistent with 'hg merge', which also prompts the user when it detects conflicts in the merged .hgsubstate files. The prompt looks like this: $ hg update tip subrepository sources for my-subrepo differ use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?

bookmarks: make track.current=True default behaviour and remove option (BC)

update: preserve possible bookmark name to set current bookmark correctly

test-i18n: test translations

subrepo: remove argument introduced by mistake in c19b9282d3a7

remove unnecessary list comprehensions These result lists were only built for the side effects, and so a normal loop is just as good and more straight-forward.

commit: abort if a subrepo is modified and ui.commitsubrepos=no The default behaviour is to commit subrepositories with uncommitted changes. In my experience this is usually undesirable: - Changes to dependencies are often debugging leftovers - Real changes should generally be applied on the source project directly, tested then committed. This is not always possible, subversion subrepos may include only a small part of the source project, without the tests. Setting ui.commitsubrepos=no will now abort commits containing such modified subrepositories like: $ hg --config ui.commitsubrepos=no ci -m msg abort: uncommitted changes in subrepo sub I ruled out the hook solution because it does not easily take --include/exclude options in account. Also, my main concern is whether this flag could cause problems with extensions. If there are legitimate reasons for callers to override this behaviour (I could not find any), they might either override at ui level, or we could add an argument to localrepo.commit() later. v2: - Renamed ui.commitsubs to ui.commitsubrepos - Mention the configuration entry in hg help subrepos