push: move push return value in the push object The return code convey information about the success of changeset push. This is used by phases to compute the new common set between local and remote. So we need to move it into the object to extract the phase sync from the god function. Note that this information will be used by obsolescence markers too.

push: move local phase move in a normal function We now have the modularity for simpler approach `localphasemove`.

push: explicitly feed pushop to localphasemove Now that pushop is holding all the push related data, we do not really need a closure anymore. So we start feeding the object to `localphasemove` and will make it a normal function in the next commit.

push: move local lock logic in pushoperation During push, we try to lock the local repo to move local phase according to what we saw/pushed on the remote repo. Locking the repo may fail, in that case we let the push proceed without local phase movement (printing warning). This mean we have code in phase synchronisation that will check if the local repo is locked or not. we need to move this information in the push object to be able to extract the phase synchronisation in its own function. This is done as a boolean because putting reference to the actual lock outside of the main function sounded a bad idea.

push: move obsolescence related message into _pushobsolescence function No good reason to have them in the main fonction.

push: drop now outdated comment This `_pushobsolete` now exist for modularity purpose.

push: feed pushoperation object to _pushobsolete function This will allow the obsolete marker synchronisation to have full information on the ongoing push and pass information to other operation.

push: move obsolescence marker exchange in the exchange module The obsolescence marker exchange code was already extracted during a previous cycle. We are moving the extracted functio in this module. This function will read and write data in the `pushoperation` object and I prefer to have all core function collaborating through this object in the same place. This changeset is pure code movement only. Code change for direct consumption of the `pushoperation` object will come later.

push: feed pushoperation object to _pushbookmark function This will able the bookmark synchronisation to have full information on the ongoing push and pass information to other operation.

merge with stable

revset: added operations to duck type baseset Added more operations which are not lazy but only used so far to duck type baseset. Their implementations will be changed in future patches.

revset: added basic operations to lazyset Added methods __add__, __sub__ and __and__ to duck type more methods in baseset

revset: added lazyset class with basic operations This class allows us to return values from large revsets as soon as they are computed instead of having to wait for the entire revset to be calculated.

tests: test that the pid returned by `hg serve` looks reasonable This failed on windows before win32.spawndetached has been fixed. The process name was "cmd.exe" and not "hg.exe" or "python.exe".

win32: spawndetached returns pid of detached process and not of cmd.exe win32.spawndetached starts the detached process by `cmd.exe` (or COMSPEC). The pid it returned was the one of cmd.exe and not the one of the detached process. When this pid is used to kill the process, the detached process is not killed, but only cmd.exe. With this patch the pid of the detached process is written to the pid file. Killing the process works as expected. The pid is only evaluated on writing the pid file. It is unnecessary to search the pid when it is not needed. And more important, it probably does not yet exist right after the cmd.exe process was started. When the pid is written to the file, waiting for the start of the detached process has already happened. Use this functionality instead of writing a 2nd wait function. Many tests on windows will not fail anymore, all those with the first failing line "abort: child process failed to start". (The processes still hanging around from previous test runs have to be killed first. They still block a tcp port.) A good test for the functionality of this patch is test-treediscovery.t, because it starts and kills `hg serve -d` several times.

revset: minor changes adding baseset to revsets Changed bits of code to work with baseset implementations.

tests: rewrite path in test-shelve.t for not being mangled on msys msys (on windows) converets '-R bundle:.XX/XX' to '-R bundle:;.XX/XX'. Avoid this by writing '-R bundle://.XX/XX'. This is used more often than the alternative work arounds like '-Rbundle://.XX/XX' or '-R bundle:Y/../.XX/XX'.

hooks: only disable/re-enable demandimport when it's already enabled This fixes an issue introduced in d7c28954d901 where, when disabling demandimport while running hooks, it's inadvertently re-enabled even when it was never enabled in the first place. This doesn't affect normal command line usage of Mercurial; it only matters when Mercurial is run with demandimport intentionally disabled.

merge with stable

convert: secret config option for disabling debugsvnlog Subversion issues involving svn log such as d54467c1a198 can be tricky to debug when it is run in an 'hg debugsvnlog' sub process. Debugging is simpler when convert only uses one process. With this change convert will invoke the svn log directly when setting [convert] svn.debugsvnlog = False This is intentionally not documented.

convert: make subversion revsplit more stable when meeting revisions without @ revsplit would crash for instance if given a subversion string without @ ... and that could somehow happen when playing around with convert.

revset: minor changes adding baseset to revsets Changed bits of code to work with baseset implementations.

revset: added __add__ method to baseset class

revset: added docstring to baseset class

merge: don't overwrite file untracked after remove, abort with 'untracked files' Merge could overwrite untracked files and cause data loss. Instead we now handle the 'local side removed file and has untracked file instead' case as the 'other side added file that local has untracked' case: FILE: untracked file exists abort: untracked files in working directory differ from files in requested revision It could perhaps make sense to create .orig files when overwriting, either instead of aborting or when overwriting anyway because of force ... but for now we stay consistent with similar cases.

shelve: better (and slightly redundant) test coverage for unshelve conflicts

shelve: status messages from unshelve It was hard for the user to know what was going on when unshelving - especially if the user had to resolve conflicts and thus got to see the intermediate states. Seeing that pending changes was gone could scare the user, make him panic, and do stuff that really made him lose data. Merging (both when rebasing and with pending changes) also requires some understanding of where in the process you are and what you are merging. To help the user we now show a couple of status messages (when relevant): temporarily committing pending changes (restore with 'hg unshelve --abort') rebasing shelved changes

shelve: be quiet when unshelve pulls from the shelve bundle unshelve was quite verbose and it was hard for a user to follow what really was going on. It ended up saying 'added 1 changesets' ... but the user just expected and got pending changes and never saw any changeset. The use of bundles is an implementation detail that we don't have to leak here. Pulling is quite verbose, optimized for pulling many changesets from remote repos - that is not the case here. Instead, set the quiet flag when pulling the bundle - not only when temporarily committing pending changes. The 'finally' restore of ui.quiet is moved to the outer try/finally used for locking.

shelve: add 'changes to' prefix to default shelve message The shelved changes _could_ perhaps be amended to the parent changeset but it _is_ not the parent changeset. Using the description from the parent changeset is thus wrong and confusing. Instead, add a 'changes to' prefix.

shelve: mention FILE options in help Shelve do normally take a list of files or patterns to shelve and the command summary should thus show [FILE]... Note: --delete is a bit special and interpret the parameters as a list of shelve names. This change makes that even less obvious from the help. Too bad - we can't please everyone.