mergecopies: rename 'ca' to 'base' This variable was named after the common ancestor. It is actually the merge base that might differ from the common ancestor in the graft case. We rename the variable before a larger refactoring to clarify the situation. Similar rename was also applied to 'checkcopies' in a prior changeset.

copies: move variable document from checkcopies to mergecopies It appears that 'mergecopies' is the function consuming these data so we move the documentation there.

checkcopies: pass data as a dictionary of dictionaries more are coming

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

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.]

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.

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.

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.

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.

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).