Tue, 20 Jul 2010 10:05:30 +0200 tests: rename some tests to help grouping
Dirkjan Ochtman <dirkjan@ochtman.nl> [Tue, 20 Jul 2010 10:05:30 +0200] rev 11617
tests: rename some tests to help grouping
Thu, 15 Jul 2010 10:24:31 +0200 keyword: add extra datefilters in a single update call
Christian Ebert <blacktrash@gmx.net> [Thu, 15 Jul 2010 10:24:31 +0200] rev 11616
keyword: add extra datefilters in a single update call
Mon, 19 Jul 2010 00:43:34 +0200 Merge with stable
Martin Geisler <mg@lazybytes.net> [Mon, 19 Jul 2010 00:43:34 +0200] rev 11615
Merge with stable
Mon, 19 Jul 2010 00:43:24 +0200 Merge with main
Martin Geisler <mg@lazybytes.net> [Mon, 19 Jul 2010 00:43:24 +0200] rev 11614
Merge with main
Mon, 19 Jul 2010 00:41:41 +0200 cmdutil: fix accidental name clash with revrange function
Martin Geisler <mg@lazybytes.net> [Mon, 19 Jul 2010 00:41:41 +0200] rev 11613
cmdutil: fix accidental name clash with revrange function The revrange function was used further up, and when a local variable is defined with the same name, the earlier call to revrange becomes a 'local variable used before assignment' error. The clash was introduced in 890ad9d6a169.
Wed, 14 Jul 2010 18:28:12 -0400 commands: fix update's help to be more accurate stable
Steve Losh <steve@stevelosh.com> [Wed, 14 Jul 2010 18:28:12 -0400] rev 11612
commands: fix update's help to be more accurate Branches can have multiple heads, so it doesn't make sense to speak of "the head of the current branch". What update really does is try to update to the *tip* of the current branch.
Sun, 18 Jul 2010 01:06:50 +0900 i18n: use encoding.colwidth() for correct column width stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 18 Jul 2010 01:06:50 +0900] rev 11611
i18n: use encoding.colwidth() for correct column width Some encoding and language combinations (e.g.: UTF-8 and Japanese) cause encoding characters into sequence of bytes more than column width of them. So, encoding.colwidth() should be applied instread of len() on i18n strings. In addition to it, formatting by '%*s'/'%-*s' also uses "number of bytes" to calculate space padding size, and should be fixed, too.
Sun, 18 Jul 2010 18:11:59 +0900 merge with stable
Nicolas Dumazet <nicdumz.commits@gmail.com> [Sun, 18 Jul 2010 18:11:59 +0900] rev 11610
merge with stable
Sun, 04 Jul 2010 18:07:30 +0900 log: slowpath: do not read the full changelog
Nicolas Dumazet <nicdumz.commits@gmail.com> [Sun, 04 Jul 2010 18:07:30 +0900] rev 11609
log: slowpath: do not read the full changelog When in the slowpath, we are examining _all_ changesets in revs. We need to order reads so they happen increasingly for I/O performance. Increasing windows were used to read changelog backwards in a windowed manner, reading the changelog forward inside each window. But since no revision range was specified, it was equivalent to reading the full changelog, even if a single revision was passed to the commandline. When --removed is used, we _need_ to scan all changesets, but if we're only looking for file patterns, this is not necessary and we can stick to the revspec that was given to us.
Sat, 03 Jul 2010 18:11:15 +0900 log: remove increasing windows usage in fastpath
Nicolas Dumazet <nicdumz.commits@gmail.com> [Sat, 03 Jul 2010 18:11:15 +0900] rev 11608
log: remove increasing windows usage in fastpath The purpose of increasing windows is to allow backwards iteration on the filelog at a reasonable cost. But is it needed? - if follow is False, we have no reason to iterate backwards. We basically just want to walk the complete filelog and yield all revisions within the revision range. We can do this forward or backwards, as it only reads the index. - when follow is True, we need to examine the contents of the filelog, and to do this efficiently we need to read the filelog forward. And on the other hand, to track ancestors and copies, we need to process revisions backwards. But is it necessary to use increasing windows for this? We can iterate over the complete filelog forward, stack the revisions, and read the reversed(pile), it does the same thing with a more readable code.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip