graph: in hgrc specify line color for main branch You can specify color to visually distinguish main branch (trunk) on hgweb's graph page. If color specified, all branch heads will share same color. Settings format is branch_name.color = value, where color is six hexadecimal digits e.g.: [graph] default.color = FF0000

graph: in hgrc specify line width for main branch You can specify width to visually distinguish main branch (trunk) on hgweb's graph page. Settings format is branch_name.width = value, where width in px e.g.: [graph] default.width = 3

merge with stable

filemerge: remove some redundancy in decorators/docstrings

filemerge: create detail of internal merge tools from documentation string this patch introduces 'internaltoolsmarker' which creates detail of each internal merge tools from documentation string for 'hg help merge-tools'.

filemerge: refactoring of 'filemerge()' current 'filemerge.filemerge()' implementation is verfy complicated. - it is not easy to add new internal merge tools (only by patching on 'filemerge()', or replacing it completely) - cleanup of temporary files is unsatisfactory ('internal:dump' does not, in fact) this is patch for refactoring of 'filemerge()' to isolate each internal merge tool implementations from 'filemerge()', and clean up common part in it.

patch: fuzz more aggressively to match patch(1) behaviour The previous code was assuming a default context of 3 lines. When fuzzing, it would take this value in account to reduce the amount of removed line from hunks top or bottom. For instance, if a hunk has only 2 lines of bottom context, fuzzing with fuzz=1 would do nothing and with fuzz=2 it would remove one of those lines. A hunk with one line of bottom context could not be fuzzed at all. patch(1) has apparently no such restrictions and takes the fuzz level at face value. - test-import.t: fuzz/offset changes at the beginning of file are explained by the new fuzzing behaviour and match patch(1) ones. Patching locations are different but those of my patch(1) do not make a lot of sense right now (patched output are the same) - test-import-bypass.t: more agressive fuzzing makes a patching supposed to fail because of context, succeed. Change the diff to avoid this. - test-mq-merge.t: more agressive fuzzing would allow the merged patch to apply with fuzz, but fortunately we disallow this behaviour. The new output is kept. I have not enough experience with patch(1) fuzzing to know whether aligning our implementation on it is a good or bad idea. Until now, it has been the implementation reference. For instance, "qpush" tolerates fuzz (test-mq-merge.t runs the special case of pushing merge revisions where fuzzing is forbidden).

patch: fix fuzzing of hunks without previous lines (issue3264) When applying hunks such as: @@ -2,1 +2,2 @@ context +change fuzzing would empty the "old" block and make patchfile.apply() traceback. Instead, we apply the new block at specified location without testing. The "bottom hunk" test was removed as patch(1) has no problem applying hunk with no context in the middle of a file.

patch: make hunk.fuzzit() compute the fuzzed start locations - It moves hunks processing weirdness where it belongs - It helps reusing said weirdness whenever fuzzit() is called, like during the actual hunk fuzzing.

patch: fuzz old and new lines at the same time In theory, the fuzzed offsets for old and new lines should be exactly the same as they are based on hunk parsing. Make it true in practice.

largefiles: optimize update speed by only updating changed largefiles Historically, during 'hg update', every largefile in the working copy was hashed (which is a very expensive operation on big files) and any largefiles that did not have a hash that matched their standin were updated. This patch optimizes 'hg update' by keeping track of what standins have changed between the old and new revisions, and only updating the largefiles that have changed. This saves a lot of time by avoiding the unecessary calculation of a list of sha1 hashes for big files. With this patch, the time 'hg update' takes to complete is a function of how many largefiles need to be updated and what their size is. Performance tests on a repository with about 80 largefiles ranging from a few MB to about 97 MB are shown below. The tests show how long it takes to run 'hg update' with no changes actually being updated. Mercurial 2.1 release: $ time hg update 0 files updated, 0 files merged, 0 files removed, 0 files unresolved getting changed largefiles 0 largefiles updated, 0 removed real 0m10.045s user 0m9.367s sys 0m0.674s With this patch: $ time hg update 0 files updated, 0 files merged, 0 files removed, 0 files unresolved real 0m0.965s user 0m0.845s sys 0m0.115s The same repsoitory, without the largefiles extension enabled: $ time hg update 0 files updated, 0 files merged, 0 files removed, 0 files unresolved real 0m0.799s user 0m0.684s sys 0m0.111s So before the patch, 'hg update' with no changes was approximately 9.25s slower with largefiles enabled. With this patch, it is approximately 0.165s slower.

mq: make qimport --push push all imported patches (issue3130) Only the first imported one was pushed.

convert: tolerate spaces between splicemap parent ids (issue3203) Splicemap lines are documented in hg help convert like: key parent1, parent2 but parsed like: key, parents = line.strip().rsplit(' ', 1) parents = parents.replace(',', ' ').split() The rsplit() call was introduced to handle spaces in keys for the generic mapfile format. Spaces can appear in svn identifiers since they contain path components. This logic makes less sense with splicemap since svn identifiers can also appear on the right side, even if it is a bit less likely. Given the parsing is theorically broken, I would rather follow what is documented already and is correct in the main case where all identifiers are hg hashes. Also, using svn identifiers in a splicemap sounds difficult as they are not easily accessible.

test-commandserver: flush stdout