Thu, 27 Sep 2012 13:54:47 +0200 histedit: move `continue` logic into a dedicated function
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 27 Sep 2012 13:54:47 +0200] rev 17666
histedit: move `continue` logic into a dedicated function When histedit "continue", there is several complicated logic to apply in order to detect intermediate changeset and concluded pending operation. This changeset extract this logic in a dedicated function to lighten the main one. No alteration to the logic is done.
Wed, 26 Sep 2012 18:13:00 +0200 histedit: rename `tip` to `topmost`
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Sep 2012 18:13:00 +0200] rev 17665
histedit: rename `tip` to `topmost` I expected `tip` to be repo's tip when it was the rewritten set tip. I rename the variable to the less ambiguous `topmost`.
Wed, 26 Sep 2012 14:46:08 +0200 histedit: factorise node stripping logic
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Sep 2012 14:46:08 +0200] rev 17664
histedit: factorise node stripping logic Create a function dedicated to stripping a group of node. All existing duplicated code is replaced by call to this function. This new function take care of stripping known and relevant node only.
Wed, 26 Sep 2012 14:19:19 +0200 histedit: extract bookmark logic in a dedicated function
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Sep 2012 14:19:19 +0200] rev 17663
histedit: extract bookmark logic in a dedicated function This lighten the main function and will help to see future changes to this bookmark logic.
Wed, 26 Sep 2012 12:57:23 +0200 histedit: remove all usages of hex[:12]
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 26 Sep 2012 12:57:23 +0200] rev 17662
histedit: remove all usages of hex[:12] - `node.hex(n)[:12]` is the same as `node.short(n)` - `ctx.hex()[:12]` is the same as `str(ctx)`
Thu, 27 Sep 2012 15:51:14 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 27 Sep 2012 15:51:14 -0500] rev 17661
merge with stable
Thu, 27 Sep 2012 15:50:14 -0500 merge with i18n stable
Matt Mackall <mpm@selenic.com> [Thu, 27 Sep 2012 15:50:14 -0500] rev 17660
merge with i18n
Mon, 30 Jul 2012 20:56:41 -0400 largefiles: enable islfilesrepo() prior to a commit (issue3541) stable
Matt Harbison <matt_harbison@yahoo.com> [Mon, 30 Jul 2012 20:56:41 -0400] rev 17659
largefiles: enable islfilesrepo() prior to a commit (issue3541) Previously, even if a file was added with --large, 'hg addremove' or 'hg ci -A' would add all files (including the previously added large files) as normal files. Only after a commit where a file was added with --large would subsequent adds or 'ci -A' take into account the minsize or the pattern configuration. This change more closely follows the help for largefiles, which mentions that 'add --large' is required to enable the configuration, but doesn't mention the previously required commit. Also, if 'hg add --large' was performed and then 'hg forget <file>' (both before a largefile enabling commit), the forget command would error out saying '.hglf/<file> not tracked'. This is also fixed. This reports that a repo is largefiles enabled as soon as a file is added with --large, which enables 'add', 'addremove' and 'ci -A' to honor the config settings before the first commit. Note that prior to the next commit, if all largefiles are forgotten, the repository goes back to reporting the repo as not largefiles enabled. It makes no sense to handle this by adding a --large option to 'addremove', because then it would also be needed for 'commit', but only when '-A' is specified. While this gets around the awkwardness of having to add a largefile, then commit it, and then addremove the other files when importing an existing codebase (and preserving that extra commit in permanent history), it does still require finding and manually adding one of the files as --large. Therefore it is probably desirable to have a --large option for init as well.
Mon, 30 Jul 2012 20:56:41 -0400 largefiles: handle commit -A properly, after a --large commit (issue3542) stable
Matt Harbison <matt_harbison@yahoo.com> [Mon, 30 Jul 2012 20:56:41 -0400] rev 17658
largefiles: handle commit -A properly, after a --large commit (issue3542) Previous to this, 'commit -A' would add as normal files, files that were already committed as largefiles, resulting in files being listed twice by 'status -A'. It also missed when (only) a largefile was deleted, even though status reported it as '!'. This also has the side effect of properly reporting the state of the affected largefiles in the post commit hook after a remove that also affected a normal file (the largefiles used to be 'R', now are properly absent). Since scmutil.addremove() is called both by the ui command (after some trivial argument validation) and during the commit process when -A is specified, it seems like a more appropriate method to wrap than the addremove command. Currently, a repo is only enabled to use largefiles after an add that explicitly identifies some file as large, and a subsequent commit. Therefore, this patch only changes behavior after such a largefile enabling commit. Note that in the test, if the final commit had a '-v', 'removing large8' would be printed twice. Both of these originate in removelargefiles(). The first print is in verbose mode after traversing remove + forget, the second is because the '_isaddremove' attr is set and 'after' is not.
Tue, 25 Sep 2012 16:01:08 +0400 i18n-ru: synchronized with 6e2ab601be3f stable
Alexander Sauta <demosito@gmail.com> [Tue, 25 Sep 2012 16:01:08 +0400] rev 17657
i18n-ru: synchronized with 6e2ab601be3f
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip