Tue, 11 Oct 2016 02:15:23 +0200 checkcopies: move 'movewithdir' initialisation right before its usage
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 11 Oct 2016 02:15:23 +0200] rev 30183
checkcopies: move 'movewithdir' initialisation right before its usage The 'movewithdir' had a lot of related logic all around the 'mergecopies'. However it is actually never containing anything until the very last loop in that function. We move the (simplified) variable definition there for clarity
Fri, 14 Oct 2016 01:53:15 +0200 cmdutil: satisfy expections in dirstateguard.__del__, even if __init__ fails
Mads Kiilerich <madski@unity3d.com> [Fri, 14 Oct 2016 01:53:15 +0200] rev 30182
cmdutil: satisfy expections in dirstateguard.__del__, even if __init__ fails Python "delstructors" are terrible - this one because it assumed that __init__ had completed before it was called. That would not necessarily be the case if the repository was read only or broken and saving the dirstate thus failed in unexpected ways. That could give confusing warnings about missing '_active' after failures. To fix that, make sure all member variables are "declared" before doing anything that possibly could fail. [Famous last words.]
Fri, 14 Oct 2016 01:53:15 +0200 util: increase filechunkiter size to 128k
Mads Kiilerich <madski@unity3d.com> [Fri, 14 Oct 2016 01:53:15 +0200] rev 30181
util: increase filechunkiter size to 128k util.filechunkiter has been using a chunk size of 64k for more than 10 years, also in years where Moore's law still was a law. It is probably ok to bump it now and perhaps get a slight win in some cases. Also, largefiles have been using 128k for a long time. Specifying that size multiple times (or forgetting to do it) seems a bit stupid. Decreasing it to 64k also seems unfortunate. Thus, we will set the default chunksize to 128k and use the default everywhere.
Wed, 12 Oct 2016 12:22:18 +0200 largefiles: always use filechunkiter when iterating files
Mads Kiilerich <madski@unity3d.com> [Wed, 12 Oct 2016 12:22:18 +0200] rev 30180
largefiles: always use filechunkiter when iterating files Before, we would sometimes use the default iterator over large files. That iterator is line based and would add extra buffering and use odd chunk sizes which could give some overhead. copyandhash can't just apply a filechunkiter as it sometimes is passed a genuine generator when downloading remotely.
Fri, 14 Oct 2016 23:33:00 +0900 revset: for x^2, do not take null as a valid p2 revision
Yuya Nishihara <yuya@tcha.org> [Fri, 14 Oct 2016 23:33:00 +0900] rev 30179
revset: for x^2, do not take null as a valid p2 revision Since we don't count null p2 revision as a parent, x^2 should never return null even if null is explicitly populated.
Mon, 10 Oct 2016 22:30:09 +0200 revset: make follow() reject more than one start revisions
Yuya Nishihara <yuya@tcha.org> [Mon, 10 Oct 2016 22:30:09 +0200] rev 30178
revset: make follow() reject more than one start revisions Taking only the last revision is inconsistent because ancestors(set) follows all revisions given, and theoretically follow(startrev=set) == ancestors(set). I'm planning to add a support for multiple start revisions, but that won't fit to the 4.0 time frame. So reject multiple revisions now to avoid future BC. len(revs) might be slow if revs were large, but we don't care since a valid revs should have only one element.
Sat, 15 Oct 2016 17:10:53 -0700 bundle2: only emit compressed chunks if they have data
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 15 Oct 2016 17:10:53 -0700] rev 30177
bundle2: only emit compressed chunks if they have data This is similar to 58467204cac0. Not all calls into the compressor return compressed data, as the compressor may buffer compressed output internally. It is cheaper to check for empty chunks than to send empty chunks through the generator. When generating a gzip-v2 bundle of the mozilla-unified repo, this change results in 50,093 empty chunks not being sent through the generator (out of 1,902,996 total input chunks).
Sat, 15 Oct 2016 15:01:14 -0700 color: add some documentation for custom terminfo codes
Danek Duvall <danek.duvall@oracle.com> [Sat, 15 Oct 2016 15:01:14 -0700] rev 30176
color: add some documentation for custom terminfo codes
Thu, 13 Oct 2016 13:10:01 -0700 color: debugcolor should emit the user-defined colors
Danek Duvall <danek.duvall@oracle.com> [Thu, 13 Oct 2016 13:10:01 -0700] rev 30175
color: debugcolor should emit the user-defined colors This also fixes a long-standing bug that reversed the sense of the color name and the label used to print it, which was never relevant before.
Thu, 13 Oct 2016 12:01:41 -0700 color: ignore effects missing from terminfo
Danek Duvall <danek.duvall@oracle.com> [Thu, 13 Oct 2016 12:01:41 -0700] rev 30174
color: ignore effects missing from terminfo If terminfo mode is in effect, and an effect is used which is missing from the terminfo database, simply silently ignore the request, leaving the output unaffected rather than causing a crash.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip