Wed, 28 May 2014 14:22:24 -0700 bundle2: rename UnknownPartError to BundleValueError
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 28 May 2014 14:22:24 -0700] rev 21617
bundle2: rename UnknownPartError to BundleValueError We are going to raise exceptions for a wider range of cases: unsupported mandatory stream and part parameters. We rename the exception with a wider name.
Tue, 27 May 2014 17:04:48 -0500 context: explicitly return a tuple
Sean Farley <sean.michael.farley@gmail.com> [Tue, 27 May 2014 17:04:48 -0500] rev 21616
context: explicitly return a tuple In the refactoring of removing localrepo.status, 2edb8648c500, we accidentally changed the return type from a tuple to a list. Philosophically, this is incorrect so we explicitly return a tuple again.
Thu, 22 May 2014 01:49:12 -0700 wireproto: expose the list of getbundle arguments to extensions stable
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 22 May 2014 01:49:12 -0700] rev 21615
wireproto: expose the list of getbundle arguments to extensions For now, getbundle accepts a fixed number of arguments: ``heads``, ``common`` and ``bundlecaps``. We make this list exposed at the module level to let extensions add content there. This is important for extensions that wish to use bundle2 for other contents than changegroup.
Tue, 27 May 2014 19:21:12 -0700 run-tests: write .err files earlier
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 27 May 2014 19:21:12 -0700] rev 21614
run-tests: write .err files earlier Earlier refactoring of run-tests.py accidentally broke --interactive and external diff generation by not having .err files written before they are consulted. This patch fixes that.
Tue, 27 May 2014 19:10:22 -0700 run-tests: exit with non-0 exit code when tests fail or warn
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 27 May 2014 19:10:22 -0700] rev 21613
run-tests: exit with non-0 exit code when tests fail or warn As part of the run-tests.py refactor, run-tests.py accidentally started exiting with 0 for most test runs. This patch restores the expected behavior.
Fri, 23 May 2014 20:23:54 -0700 bundle2: expose mandatory params in a mandatorykeys attribute
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 23 May 2014 20:23:54 -0700] rev 21612
bundle2: expose mandatory params in a mandatorykeys attribute We expose all keys that MUST be processed in ``part.mandatorykeys``. This makes it much easier to access the information. Enforcement of the mandatory parameters is coming in later changesets.
Mon, 26 May 2014 18:45:43 -0700 bundle2: use the new ``part.params`` dictionary
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 26 May 2014 18:45:43 -0700] rev 21611
bundle2: use the new ``part.params`` dictionary We use the new ``part.params`` dictionary to access the value of parameters instead of creating one from the part's attributes.
Fri, 23 May 2014 17:26:57 -0700 bundle2: introduce a ``params`` dictionary on unbundled parts
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 23 May 2014 17:26:57 -0700] rev 21610
bundle2: introduce a ``params`` dictionary on unbundled parts This exposes all parameters the part received into a ``part.params`` dictionary. This should be much easier to use. This dictionary itself does not expose the mandatory or advisory aspect of parameters, but no current users of bundle2 actually enforce any of this logic. Coming changesets will improve this aspect.
Fri, 23 May 2014 17:17:39 -0700 bundle2: make sure unbundled part param are read-only
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 23 May 2014 17:17:39 -0700] rev 21609
bundle2: make sure unbundled part param are read-only My old uncle Robert once trusted an API user. We never saw him again.
Wed, 28 May 2014 10:04:02 -0700 bundle2: introduce an ``_initparams`` method
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 28 May 2014 10:04:02 -0700] rev 21608
bundle2: introduce an ``_initparams`` method The handling of parameters will become much more sophisticated in the coming changesets. So we extract the logic in a function to not pollute the generic logic.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip