Sun, 14 Dec 2014 12:29:28 -0800 namespaces: introduce a generic way to map between names and nodes
Sean Farley <sean.michael.farley@gmail.com> [Sun, 14 Dec 2014 12:29:28 -0800] rev 23553
namespaces: introduce a generic way to map between names and nodes This patch begins the work to provide a way to register a namespace to handle 'names'. Benefits of this would be, - improved templating: This would provide {name} which could output any branch, bookmark, tag, or any extension registered namespace all without having the extension doing any extra work - improved tab completion: Since this provides a single source of all 'names', tab completion would not need to know of each namespace - changeset lookup: Similar to before, a unified place to get all 'names' will allow finding changesets without any extension code having to reimplement this Also, d226fe36e362 has shown us that for internal code which expects a certain type of method or behavior, we should provide an easy way for extensions to check this behavior.
Sun, 14 Dec 2014 19:27:58 +0100 statichttprepo: update profile of __call__ in mock vfs object
Mads Kiilerich <madski@unity3d.com> [Sun, 14 Dec 2014 19:27:58 +0100] rev 23552
statichttprepo: update profile of __call__ in mock vfs object New code paths could fail because the old statichttprepo profile couldn't handle the usual parameters. Instead, reuse a more generic profile also used in readonlyvfs.
Sun, 14 Dec 2014 21:00:58 +0100 tests: avoid git diffstat singular/plural output difference
Mathias De Maré <mathias.demare@gmail.com> [Sun, 14 Dec 2014 21:00:58 +0100] rev 23551
tests: avoid git diffstat singular/plural output difference 'git diff --stat' output changed with regard to the amount of changes/insertions/deletions shown. In older git versions (1.7.7.6), output was shown as: 2 files changed, 2 insertions(+), 1 deletions(-) In newer versions, output is shown as: 2 files changed, 2 insertions(+), 1 deletion(-) This patch uses a regex to handle both cases.
Sun, 14 Dec 2014 11:34:51 +0100 subrepo: add revert support without backup for git subrepos
Mathias De Maré <mathias.demare@gmail.com> [Sun, 14 Dec 2014 11:34:51 +0100] rev 23550
subrepo: add revert support without backup for git subrepos Previously, git subrepos did not support reverting. This change adds basic support for reverting when '--no-backup' is specified. A warning is given (and the current state is kept) when a revert is done without the '--no-backup' flag.
Sat, 01 Nov 2014 22:56:49 -0700 match: make 'always' and 'exact' functions, not classes
Martin von Zweigbergk <martinvonz@google.com> [Sat, 01 Nov 2014 22:56:49 -0700] rev 23549
match: make 'always' and 'exact' functions, not classes There is no reason for classes 'always' and 'exact' not to be just functions that return instances the plain 'match' class.
Sat, 13 Dec 2014 14:31:55 -0800 share: implement shared bookmark functionality
Ryan McElroy <rmcelroy@fb.com> [Sat, 13 Dec 2014 14:31:55 -0800] rev 23548
share: implement shared bookmark functionality This does not cause any behavioral change unless a 'bookmarks.shared' marker file exists. A future change will add UI to create this file when a repository is shared.
Sat, 13 Dec 2014 13:56:05 -0800 debugindex: respect --debug flag to show full nodeids
Kyle Lippincott <spectral@google.com> [Sat, 13 Dec 2014 13:56:05 -0800] rev 23547
debugindex: respect --debug flag to show full nodeids
Fri, 12 Dec 2014 14:06:36 -0800 localrepo.clone: add a way to override server preferuncompressed
Siddharth Agarwal <sid0@fb.com> [Fri, 12 Dec 2014 14:06:36 -0800] rev 23546
localrepo.clone: add a way to override server preferuncompressed Without this patch, if the server sets preferuncompressed, there's no way for clients to override that and force a non-streaming clone. With this patch, we extend the meaning of --pull to also override preferuncompressed and force a non-streaming clone.
Fri, 12 Dec 2014 14:02:56 -0800 hg.clone: set 'stream' depending on whether --pull was requested or not
Siddharth Agarwal <sid0@fb.com> [Fri, 12 Dec 2014 14:02:56 -0800] rev 23545
hg.clone: set 'stream' depending on whether --pull was requested or not In an upcoming patch we'll differentiate between the two in localrepo.
Fri, 14 Nov 2014 05:53:04 -0800 merge: perform case-collision checking on final set of actions
Martin von Zweigbergk <martinvonz@google.com> [Fri, 14 Nov 2014 05:53:04 -0800] rev 23544
merge: perform case-collision checking on final set of actions When there are multiple common ancestors, we should check for case collisions only on the resulting actions after bid merge has run. To do this, move the code until after bid merge. Move it past _resolvetrivial() too, since that might update actions. If the remote changed a file and then reverted the change, while the local side deleted the file and created a new file with a name that case-folds like the old file, we should fail before this patch but not after. Although the changes to the actions caused by _forgetremoved() should have no effect on case collisions, move it after that, too, so the next person reading the code won't have to think about it. Moving it past these blocks of code takes it to the end of calculateupdates(), so let's even move it outside of the method, so we also check collisions in actions produced by extensions overriding the method.
Thu, 17 Apr 2014 22:47:38 +0200 spelling: fixes from proofreading of spell checker issues
Mads Kiilerich <madski@unity3d.com> [Thu, 17 Apr 2014 22:47:38 +0200] rev 23543
spelling: fixes from proofreading of spell checker issues
Sat, 13 Dec 2014 09:45:00 +0100 tests: allow more flexibility in git diffstat output
Mathias De Maré <mathias.demare@gmail.com> [Sat, 13 Dec 2014 09:45:00 +0100] rev 23542
tests: allow more flexibility in git diffstat output The output of 'git diff --stat' changed in git 1.7.10 and 1.7.11. To ensure the tests work with earlier versions of git as well, the output is now wrapped with a whitespace regex.
Thu, 11 Dec 2014 21:21:21 -0800 merge: move cd/dc prompts after largefiles prompts
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Dec 2014 21:21:21 -0800] rev 23541
merge: move cd/dc prompts after largefiles prompts By moving the cd/dc prompts out of calculateupdates(), we let largefiles' overridecalculateupdates() so the unresolved values (i.e. 'cd' or 'dc' rather than 'g', 'r', 'a' and missing). This allows overridecalculateupdates() to ask the user whether to keep the normal file or the largefile before the user gets the cd/dc prompt. Whichever answer the user gives, we make overridecalculateupdates() replace 'cd' or 'dc' action, saving the user one annoying (and less clear) question.
Sun, 30 Nov 2014 22:47:53 -0500 addremove: automatically process a subrepository's subrepos
Matt Harbison <matt_harbison@yahoo.com> [Sun, 30 Nov 2014 22:47:53 -0500] rev 23540
addremove: automatically process a subrepository's subrepos Since addremove on the top of a directory tree will recursively handle sub directories, it should be the same with deep subrepos, once the user has explicitly asked to process a subrepo. This really only has an effect when a path that is a subrepo (or is in a subrepo) is given, since -S causes all subrepos to be processed already. An addremove without a path that crosses into a subrepo, will still not enter any subrepos, per backward compatibility rules.
Sun, 09 Nov 2014 23:46:25 -0500 addremove: support addremove with explicit paths in subrepos
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Nov 2014 23:46:25 -0500] rev 23539
addremove: support addremove with explicit paths in subrepos Git and svn subrepos are currently not supported.
Mon, 24 Nov 2014 23:51:26 -0500 addremove: add support for the -S flag
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Nov 2014 23:51:26 -0500] rev 23538
addremove: add support for the -S flag Git and svn subrepos are currently not supported. It doesn't look like git or svn have these commands natively, so that's an area for a git or svn expert.
Mon, 24 Nov 2014 22:27:49 -0500 commit: propagate --addremove to subrepos if -S is specified (issue3759)
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Nov 2014 22:27:49 -0500] rev 23537
commit: propagate --addremove to subrepos if -S is specified (issue3759) The recursive addremove operation occurs completely before the first subrepo is committed. Only hg subrepos support the addremove operation at the moment- svn and git subrepos will warn and abort the commit.
Wed, 26 Nov 2014 16:13:38 -0500 subrepo: store the ui object in the base class
Matt Harbison <matt_harbison@yahoo.com> [Wed, 26 Nov 2014 16:13:38 -0500] rev 23536
subrepo: store the ui object in the base class This will be used in the next patch to print a warning from the base class. It seems better than having to explicitly pass it to a new method, since a lot of existing methods also require it.
Wed, 26 Nov 2014 15:16:22 -0500 commit: abort if --addremove is specified, but fails
Matt Harbison <matt_harbison@yahoo.com> [Wed, 26 Nov 2014 15:16:22 -0500] rev 23535
commit: abort if --addremove is specified, but fails This will be required when subrepo support is added, in order to ensure consistent commits when a subrepo flavor doesn't support addremove.
Wed, 26 Nov 2014 14:27:36 -0500 addremove: warn when addremove fails to operate on a named path
Matt Harbison <matt_harbison@yahoo.com> [Wed, 26 Nov 2014 14:27:36 -0500] rev 23534
addremove: warn when addremove fails to operate on a named path It looks like a bad path is the only mode of failure for addremove. This warning is probably useful for the standalone command, but more important for 'commit -A'. That command doesn't currently abort if the addremove fails, but it will be made to do so prior to adding subrepo support, since not all subrepos will support addremove. We could just abort here, but it looks like addremove has always silently ignored bad paths, except for the exit code.
Sun, 09 Nov 2014 19:57:02 -0500 scmutil: pass a matcher to scmutil.addremove() instead of a list of patterns
Matt Harbison <matt_harbison@yahoo.com> [Sun, 09 Nov 2014 19:57:02 -0500] rev 23533
scmutil: pass a matcher to scmutil.addremove() instead of a list of patterns This will make it easier to support subrepository operations.
Wed, 10 Dec 2014 23:46:47 -0500 tests: fix a typo in test-walkrepos.py
Enrique A. Tobis <enrique@tobis.com.ar> [Wed, 10 Dec 2014 23:46:47 -0500] rev 23532
tests: fix a typo in test-walkrepos.py
Wed, 03 Dec 2014 13:50:28 -0800 merge: extract _resolvetrivial() function
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Dec 2014 13:50:28 -0800] rev 23531
merge: extract _resolvetrivial() function We would eventually like to move the resolution of modify/delete and delete/modify conflicts to the resolve phase. However, we don't want to move the checks for identical content that were added in 902554884335 (merge: before cd/dc prompt, check that changed side really changed, 2014-12-01). Let's instead move these out to a new _resolvetrivial() function that processes the actions from manifestmerge() and replaces any false cd/dc conflicts. The function will also provide a natural place for us to later add code for resolving false 'm' conflicts.
Tue, 09 Dec 2014 22:10:51 -0800 largefiles: start by finding files of interest
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 22:10:51 -0800] rev 23530
largefiles: start by finding files of interest Instead of iterating over 'g' action, first find the set of all files that are largefiles in p1. Then iterate over these files. This prepares for considering actions other than 'g'.
Tue, 09 Dec 2014 22:03:53 -0800 largefiles: rewrite merge code using dictionary with entry per file
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 22:03:53 -0800] rev 23529
largefiles: rewrite merge code using dictionary with entry per file In overridecalculateupdates(), we currently only deal with conflicts that result in a 'g' action for either the largefile or a standin. We will soon want to deal cases with 'cd' and 'dc' actions here. It will be easier to reason about such cases if we rewrite it using a dict from filename to action. A side-effect of this change is that the output can only have one action per file (which should be a good change). Before this change, when one of the tests in test-issue3084 received this input (the 'a' in the input was a result of 'cd' conflict resolved in favor of the modified file): 'g': [('.hglf/f', ('',), 'remote created')], 'a': [('f', None, 'prompt keep')], and the user chose to keep the local largefile, it produced this output: 'g': [('.hglf/f', ('',), 'remote created')], 'r': [('f', None, 'replaced by standin')], 'a': [('f', None, 'prompt keep')], Although 'a' actions are processed after 'r' actions by recordupdates(), it still worked because 'a' actions have no effect on merges (only on updates). After this change, the output is: 'g': [('.hglf/f', ('',), 'remote created')], 'r': [('f', None, 'replaced by standin')], Similarly, there are several tests in test-largefiles-update that get inputs like: 'a': [('.hglf/large2', None, 'prompt keep')], 'g': [('large2', ('',), 'remote created')], and when the user chooses to keep the local largefile, they produce this output: 'a': [('.hglf/large2', None, 'prompt keep'), ('.hglf/large2', None, 'keep standin')], 'lfmr': [('large2', None, 'forget non-standin largefile')], In this case, it was not a merge but an update, so the 'a' action does have an effect. However, since dirstate.add() is idempotent, it still has no obserable effect. After this change, the output is: 'a': [('.hglf/large2', None, 'keep standin')], 'lfmr': [('large2', None, 'forget non-standin largefile')],
Tue, 09 Dec 2014 09:53:26 -0800 largefiles: put same 'action' object back in 'newglist'
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 09:53:26 -0800] rev 23528
largefiles: put same 'action' object back in 'newglist' The items we put in 'newglist' are always the same as what we found in actions['g'], so let's just put the same item into the list instead of creating a new one.
Mon, 08 Dec 2014 15:20:42 -0800 largefiles: don't unnecessarily sort merge action lists
Martin von Zweigbergk <martinvonz@google.com> [Mon, 08 Dec 2014 15:20:42 -0800] rev 23527
largefiles: don't unnecessarily sort merge action lists The action lists returned from calculateupdates() (in merge.py) are not required to be sorted. In fact, since they result from iteration over the unordered manifest, they are unlikely to be sorted. Moreover, some of the lists are appended to after they are returned from manifestmerge(). The lists are instead sorted in applyupdates(). Therefore, let's not sort the lists generated in largefiles' overridecalculateupdates().
Tue, 09 Dec 2014 16:49:55 -0800 merge: don't treat 'diverge' and 'renamedelete' like actions
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 16:49:55 -0800] rev 23526
merge: don't treat 'diverge' and 'renamedelete' like actions See earlier patch for motivation.
Tue, 09 Dec 2014 14:18:31 -0800 merge: move dr/rd warning messages out of applyupdates()
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 14:18:31 -0800] rev 23525
merge: move dr/rd warning messages out of applyupdates() As preparation for making 'dr' and 'rd' actions no longer actions, move the reporting from applyupdates() to its caller update(). This way we won't have to pass additonal arguments to applyupdates() when they are no longer actions. Also, the warnings are equally unrelated to applyupdates() as they are to recordupdates(), as they don't result in any changes to either the working copy or the dirstate. See earlier patch for additional motivation.
Fri, 05 Dec 2014 16:13:26 -0800 merge: don't report progress for dr/rd actions
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Dec 2014 16:13:26 -0800] rev 23524
merge: don't report progress for dr/rd actions It is easier to reason about certain algorithms in terms of a file->action mapping than the current action->list-of-files. Bid merge is already written this way (but with a list of actions per file), and largefiles' overridecalculateupdates() will also benefit. However, that requires us to have at most one action per file. That requirement is currently violated by 'dr' (divergent rename) and 'rd' (rename and delete) actions, which can exist for the same file as some other action. These actions are only used for displaying warnings to the user; they don't change anything in the working copy or the dirstate. In this way, they are similar to the 'k' (keep) action. However, they are even less action-like than 'k' is: 'k' at least describes what to do with the file ("do nothing"), while 'dr' and 'rd' or only annotations for files for which there may exist other, "real" actions. As a first step towards separating these acitons out, stop including them in the progress output, just like we already exclude the 'k' action.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip