Tue, 30 Apr 2013 21:19:56 +0200 push: make locking of source optional (issue3684) stable
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 30 Apr 2013 21:19:56 +0200] rev 19097
push: make locking of source optional (issue3684) Having the permission to lock the source repo on push is now optional. When the repo cannot be locked, phase are not changed locally. A status message is issue when some actual phase movement are skipped: cannot lock source repo, skipping local public phase update A debug message with the exact reason of the locking failure is issued in all case.
Tue, 30 Apr 2013 10:51:25 +0200 push: factorise phase movement in a simple closure stable
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 30 Apr 2013 10:51:25 +0200] rev 19096
push: factorise phase movement in a simple closure Having all phases movement centralised will help to handle special case when the local repo can not be locked as describe in issue 3684.
Mon, 29 Apr 2013 15:58:15 +0900 merge: increase safety of parallel updating/removing on icasefs stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 29 Apr 2013 15:58:15 +0900] rev 19095
merge: increase safety of parallel updating/removing on icasefs "merge.applyupdates()" sorts "actions" in removal first order, and "workeractions" derived from it should be also sorted. If each actions in "workeractions" are executed in serial, this sorting ensures that merging/updating process is collision free, because updating the file in target context is always executed after removing the existing file which causes case-folding collision against the former. In the other hand, if each actions are executed in parallel, updating on a worker process may be executed before removing on another worker process, because "worker.partition()" partitions list of actions regardless of type of each actions. This patch divides "workeractions" into removing and updating, and executes the former first. This patch still scans "actions"/"workeractions" some times for ease of patch review, even though large list may cost much in this way. (total cost should be as same as before) This also changes some tests, because dividing "workeractions" affects progress indication.
Tue, 30 Apr 2013 13:53:49 +0200 hgweb: handle filtered "0" rev in navigation stable
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 30 Apr 2013 13:53:49 +0200] rev 19094
hgweb: handle filtered "0" rev in navigation Before this changeset, navigation generation crashed if revision "0" was filtered. We introduce a `_first` methods on revision navigation that return the lowest unfiltered element and use it in two place were the "0" changeset was explicitly referenced. Test case are introduced.
Tue, 30 Apr 2013 15:11:12 +0200 hgweb: fix empty navigation detection stable
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 30 Apr 2013 15:11:12 +0200] rev 19093
hgweb: fix empty navigation detection For some obscure reason, changelog.node(0) returns nullid if changelog is empty. this break empty navigation detection. We fix this code by using the length of the changelog. Using the length have some issue with revision filtering but this is a small step in the right direction. Proper fix comes in later changeset.
Tue, 30 Apr 2013 14:56:33 +0100 tests: AIX can't handle negative date in test-dirstate.t stable
Jim Hague <jim.hague@acm.org> [Tue, 30 Apr 2013 14:56:33 +0100] rev 19092
tests: AIX can't handle negative date in test-dirstate.t test-dirstate.t fails on AIX in the absurd date test. AIX touch errors on any date prior to 1970. AIX mktime() gives an error on such dates, so the problem is deeper than touch and attempts to work around touch in Python failed. Give up. Add an AIX test to hghave and skip the absurd date test on AIX.
Fri, 26 Apr 2013 01:12:03 +0900 win32: use explicit path to "python.exe" only if it exists stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 26 Apr 2013 01:12:03 +0900] rev 19091
win32: use explicit path to "python.exe" only if it exists Before this patch, "hg.bat" for Windows environment always uses "%~dp0..\python" as explicit path to "python.exe". This path may not be valid in some cases. For example, on the environment using "virtualenv" python package, both "python.exe" and "hg.bat" are placed in the same directory. In this case, "python.exe" should be found on PATH, because virtualenv activation script puts "python.exe" on the PATH. This patch uses explicit path to "python.exe" only if it exists, and expects that "python.exe" can be found on PATH otherwise.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip