Wed, 01 May 2013 00:38:43 +0900 i18n-ja: synchronized with f01a351db791 stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 01 May 2013 00:38:43 +0900] rev 19100
i18n-ja: synchronized with f01a351db791
Mon, 29 Apr 2013 14:14:42 -0700 dispatch: add support for --option=value to _earlygetopt stable
Bryan O'Sullivan <bryano@fb.com> [Mon, 29 Apr 2013 14:14:42 -0700] rev 19099
dispatch: add support for --option=value to _earlygetopt This fixes a very confusing error message: $ hg --config=pager.enabled=off st abort: option --config may not be abbreviated!
Mon, 29 Apr 2013 14:14:41 -0700 dispatch: add doctests for _earlygetopt stable
Bryan O'Sullivan <bryano@fb.com> [Mon, 29 Apr 2013 14:14:41 -0700] rev 19098
dispatch: add doctests for _earlygetopt
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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip