Wed, 08 Jul 2015 18:11:40 +0100 convert: if getting a file from Perforce fails try to get it one more time
Eugene Baranov <eug.baranov@gmail.com> [Wed, 08 Jul 2015 18:11:40 +0100] rev 25775
convert: if getting a file from Perforce fails try to get it one more time When converting a particularly large Perforce changelist (especially with some big files), it is very likely to run into an intermittent network issue (e.g. WSAECONNRESET or WSAETIMEDOUT) getting one of the files, which will result in the entire changelist converting being aborted. Which can be quite unfortunate since you might have waited hours getting all other files. To mitigate this let's attempt to get the file one more time, escalating original exception if that attempt fails.
Mon, 13 Jul 2015 23:34:12 +0900 shelve: keep old backups if timestamp can't decide exact order of them
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 13 Jul 2015 23:34:12 +0900] rev 25774
shelve: keep old backups if timestamp can't decide exact order of them Before this patch, backups to be discarded are decided by steps below at 'hg unshelve' or so: 1. list '(st_mtime, filename)' tuples of each backups up 2. sort list of these tuples, and 3. discard backups other than 'maxbackups' ones at the end of list This doesn't work well in the case below: - "sort by name" order differs from actual backup-ing order, and - some of backups have same timestamp For example, 'test-shelve.t' satisfies the former condition: - 'default-01' < 'default-1' in "sort by name" order - 'default-1' < 'default-01' in actual backup-ing order Then, 'default-01' is discarded instead of 'default-1' unexpectedly, if they have same timestamp. This failure appears occasionally, because the most important condition "same timestamp" is timing critical. To avoid such unexpected discarding, this patch keeps old backups if timestamp can't decide exact order of them. Timestamp of the border backup (= the oldest one of recent 'maxbackups' ones) as 'bordermtime' is used to examine whether timestamp can decide exact order of backups.
Fri, 10 Jul 2015 00:59:51 +0900 subrepo: use vfs.dirname instead of os.path.dirname
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 10 Jul 2015 00:59:51 +0900] rev 25773
subrepo: use vfs.dirname instead of os.path.dirname This patch uses "wvfs of the parent repository" ('pwvfs') instead of 'wvfs' of own repository, because 'self._path' is the path to this subrepository as seen from the parent repository.
Fri, 10 Jul 2015 00:59:51 +0900 vfs: add dirname
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 10 Jul 2015 00:59:51 +0900] rev 25772
vfs: add dirname
Fri, 10 Jul 2015 00:59:51 +0900 subrepo: use vfs.basename instead of os.path.basename
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 10 Jul 2015 00:59:51 +0900] rev 25771
subrepo: use vfs.basename instead of os.path.basename
Fri, 10 Jul 2015 00:59:51 +0900 vfs: add basename
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 10 Jul 2015 00:59:51 +0900] rev 25770
vfs: add basename
Fri, 10 Jul 2015 00:59:51 +0900 subrepo: use repo.pathto instead of util.pathto to simplify invocation
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 10 Jul 2015 00:59:51 +0900] rev 25769
subrepo: use repo.pathto instead of util.pathto to simplify invocation This centralization into 'repo.pathto()' should reduce the cost of vfs migration around 'getcwd()' and so on in the future.
Fri, 10 Jul 2015 00:59:51 +0900 subrepo: prefetch ctx.repo() for efficiency and centralization
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 10 Jul 2015 00:59:51 +0900] rev 25768
subrepo: prefetch ctx.repo() for efficiency and centralization 'subrepo.state()' refers same 'ctx.repo()' in many places and times.
Thu, 02 Jul 2015 21:39:31 +0900 revset: rename getkwargs() to getargsdict()
Yuya Nishihara <yuya@tcha.org> [Thu, 02 Jul 2015 21:39:31 +0900] rev 25767
revset: rename getkwargs() to getargsdict() This function was added recently at 48919d246a47, but its name was misleading because it processes both positional and keyword arguments.
Sun, 28 Jun 2015 16:08:07 +0900 revset: work around x:y range where x or y is wdir()
Yuya Nishihara <yuya@tcha.org> [Sun, 28 Jun 2015 16:08:07 +0900] rev 25766
revset: work around x:y range where x or y is wdir() All revisions must be contiguous in spanset, so we need the special case for the wdir revision.
Mon, 16 Mar 2015 16:17:06 +0900 revset: use integer representation of wdir() in revset
Yuya Nishihara <yuya@tcha.org> [Mon, 16 Mar 2015 16:17:06 +0900] rev 25765
revset: use integer representation of wdir() in revset This is the simplest way to handle wdir() revision in revset. None didn't work well because revset heavily depends on integer operations such as min(), max(), sorted(), x:y, etc. One downside is that we cannot do "wctx.rev() in set" because wctx.rev() is still None. We could wrap the result set by wdirproxyset that translates None to wdirrev, but it seems overengineered at this point. result = getset(repo, subset, tree) if 'wdir' in funcsused(tree): result = wdirproxyset(result) Test cases need the '(all() + wdir()) &' hack because we have yet to fix the bootstrapping issue of null and wdir.
Sat, 16 Aug 2014 13:25:45 +0900 localrepo: provide workingctx by integer revision
Yuya Nishihara <yuya@tcha.org> [Sat, 16 Aug 2014 13:25:45 +0900] rev 25764
localrepo: provide workingctx by integer revision This allows us to use the integer representation in revset. None doesn't work well while computing revset because revset heavily depends on and optimized for integer revisions. Still repo[wdirrev].rev() is None, which means the canonical form of the working-directory revision is None. This patch doesn't add the case for the wdirid because we can't handle short and ambiguous identifiers here. Perhaps, the wdirid will have to be handled in the changelog layer.
(0) -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 +10000 tip