rename: properly report removed and added file as modified (issue4458) The result of 'hg rm' + 'hg rename' disagreed with the one from 'hg rename --force'. We align them on 'hg move --force' because it agrees with what 'hg status' says after the commit. Stopping reporting a modified file as added puts an end to the hg revert confusion in this situation (issue4458). However, reporting the file as modified also prevents revert from restoring the copy source. We fix this in a later changeset. Git diff also stop reporting the add in the middle of the chain as add. Not sure how important (and even wrong) it is.

manifest: fix a bug where working copy file 'add' mark was buggy Because the same dictionary was used to (1) get node from parent and (2) store annotated version, we could end up with buggy values. For example with a chain of renames: $ hg mv b c $ hg mv a b The value from 'b' would be updated as "<old-a>a", then the value of c would be updated as "<old-b>a'. With the current dictionary sharing this ends up with: '<new-c>' == '<old-a>aa' This value is double-wrong as we should use '<old-b>' and a single 'a'. We now use a read-only value for lookup. The 'test-rename.t' test is impacted because such a chained added file is suddenly detected as such.

merge: be precise about what merged into what in short desc

docker: add Docker files for running an Apache mod_wsgi server I frequently find myself wanting to run hgweb in a production-like environment, with a real HTTP server and multiple WSGI workers. This patch introduces a Docker environment for running Mercurial under Apache + mod_wsgi. With just a few command executions, it is possible to spin up a Docker container running hgweb. The container is tailored for Mercurial developers wanting to run Mercurial from a source checkout. It is **not** meant to be something suitable for production use. The container provides a default hgweb environment with an empty repository that allows pushes. You can thus start a container and push your favorite repository there for quick testing. The container is designed to allow customizations. Users can provide their own hgweb configurations and mount existing directories containing repositories into the container. The behavior of the container and how to control things is documented in the README.rst file.

merge: use None as filename for base in 'both created' conflicts Instead of using a file that we know is not in the common ancestor's maniffest, let's use None. This is safe as the only place that cares about the value (applyupdates) already checks if the item exists in the ancestor.

merge: break out "both renamed a -> b" case We can further limit the scope of the 2-way merge case by breaking out the case where the file was not created from scratch on both sides but rather renamed in the same way (and is therefore a 3-way merge). This involves copying some code, but it makes it clearer which case the "Note:" in the code refers to.

merge: separate out "both created" cases When 'f' is not in 'ma', 'a' will be 'nullid' and all the if/elif conditions that check whether some one nodeid is equal to 'a' will fail, and the else-clause will instead apply. We can make that more explicit by creating a separate 'm' action for the case where 'a' is 'nullid'. While it does mean copying some code, perhaps it makes it a little clearer which codepaths are possible, and which cases the "Note:" in the code refers to. It also lets us make the debug action messages a little more specific.

merge: indent to prepare for next patch

merge with stable

factotum: convert Plan 9 quoted string to Python string

plan9: setup check for current python build

add: check for the existence of a file matched inexactly before adding it The change in 10697f29af2b created a problem on Windows and OS X: --- /usr/local/mercurial/tests/test-issue660.t +++ /usr/local/mercurial/tests/test-issue660.t.err @@ -47,6 +47,8 @@ Should succeed - shadow removed: $ hg add b + adding b/b + b/b does not exist! Prior to the failing 'hg add', the file 'b/b' was added and committed, then 'b' was recursively deleted from the filesystem, file 'b' was created and the delete was recorded with 'hg rm --after'. This add is attempting to record the existence of file 'b'. A filesystem that is not case sensitive prevents dirstate.walk() from skipping its step 3, and step 3 has the effect of inserting removed files into the walk list. The Linux code doesn't run through step 3, and didn't exhibit the problem. It's not clear why a non case sensitive filesystem triggers step 3, given that the path normalization occurs in step 2. Prior to 10697f29af2b, part of the check here was 'f not in repo.dirstate' instead of 'f not in wctx'. Files in the 'r' state are filtered out of context.__contains__() but not dirstate.__contains__(). Therefore the removed file name wasn't added to the list of files to add when checking against dirstate. That change was to allow removed files to be readded, but adding a file that doesn't exist is nonsensical. If the user specifies a missing file, it will be an exact match and will still fail.

tests: choose the proper environment variable style for the platform Windows was printing out 'commit $HG_NODE' instead of the actual hash.

tests: fix another multi-statement hook for Windows The double quotes are necessary, otherwise it tries to pipe into a program named 'short'. An '&' could serve as a command separator on Windows instead of ';', but I don't see any obvious way to swap these depending on the platform. In this case though, there really wasn't a need for multiple statements.

run-tests: set a default largefiles usercache in the default hgrc file This fixes a test failure introduced in 4be754832829 on Windows and OS X, where the cached largefile wasn't being deleted because the named .cache directory didn't exist. It only existed on Linux because the test suite sets $HOME to the directory of the test being run, and Linux uses $HOME/.cache by default. Most of the other largefiles tests explicitly set this value at the top of their scripts, but test-largefiles-update.t didn't pick that up when it was created. Those scripts that do set a value will override this. We could just set the parameter in the test-largefiles-update.t script, but there are a few other non obvious tests that exercise largefiles too. These largefiles end up being cached in the user's real cache, so proper hygiene dictates that this not be left to each individual test script.