Thu, 22 May 2014 09:53:52 -0700 getbundle: declare type of parameters
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 22 May 2014 09:53:52 -0700] rev 21646
getbundle: declare type of parameters In addition to listing the expected options for ``getbundle``, we also list their types and handle the encoding/decoding automatically. This should make it easier for extensions to transmit additional information to getbundle.
Thu, 22 May 2014 13:31:33 -0700 bundle2: introduce a ``caps20to10`` function
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 22 May 2014 13:31:33 -0700] rev 21645
bundle2: introduce a ``caps20to10`` function This function factors the creation of appropriate entries to use in ``bundlecaps`` argument of ``getbundle``. This cleans up code calling ``getbundle`` and helps its usage in more part of the code.
Sat, 24 May 2014 16:20:09 -0700 bundle2: introduce a bundle2caps function
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 24 May 2014 16:20:09 -0700] rev 21644
bundle2: introduce a bundle2caps function The process of decoding remote bundle2caps blob into a dictionary is cumbersome. We move it into a small helper function. This will clarify code that reads bundle2 capabilities of peers and helps using it in new places.
Thu, 22 May 2014 12:58:07 -0700 exchange: reinsert comment in the right place
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 22 May 2014 12:58:07 -0700] rev 21643
exchange: reinsert comment in the right place Unrelated new code was inserted between the original comment and the related code block.
Thu, 29 May 2014 16:01:39 -0700 docker: check for docker.io first
Matt Mackall <mpm@selenic.com> [Thu, 29 May 2014 16:01:39 -0700] rev 21642
docker: check for docker.io first
Tue, 20 May 2014 04:07:58 +0200 buildrpm: include release version in .tar.gz name
Mads Kiilerich <madski@unity3d.com> [Tue, 20 May 2014 04:07:58 +0200] rev 21641
buildrpm: include release version in .tar.gz name Official releases are fully indentified by the version number, these builds are not. Specs are however traditionally not versioned.
Thu, 15 May 2014 01:48:37 +0200 buildrpm: remove prompt for uncommitted changes - it was a bad idea
Mads Kiilerich <madski@unity3d.com> [Thu, 15 May 2014 01:48:37 +0200] rev 21640
buildrpm: remove prompt for uncommitted changes - it was a bad idea We want a command that is useful in scripts, not an interactive command.
Thu, 15 May 2014 01:48:37 +0200 buildrpm: collect code for building local hg and using it in one place
Mads Kiilerich <madski@unity3d.com> [Thu, 15 May 2014 01:48:37 +0200] rev 21639
buildrpm: collect code for building local hg and using it in one place
Tue, 20 May 2014 03:57:21 +0200 buildrpm: various minor cleanup
Mads Kiilerich <madski@unity3d.com> [Tue, 20 May 2014 03:57:21 +0200] rev 21638
buildrpm: various minor cleanup
Sat, 10 May 2014 14:54:39 -0700 fix_bytes: loosen blacklist matching requirements
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 May 2014 14:54:39 -0700] rev 21637
fix_bytes: loosen blacklist matching requirements On my Linux machine, paths seen by 2to3 include the build directory. We switch from an exact to substring match to allow 2to3 to work in more environments.
Mon, 19 May 2014 22:12:31 +0200 convert: only consider shamap revisions converted if they still exists
Mads Kiilerich <madski@unity3d.com> [Mon, 19 May 2014 22:12:31 +0200] rev 21636
convert: only consider shamap revisions converted if they still exists Rollback or strip could leave a Mercurial repo with a shamap with revisions no longer in the repository. To ensure reliable conversions we now check that the commit actually exists and consider it non-existing if it doesn't exist.
Mon, 19 May 2014 22:12:30 +0200 convert: introduce hascommitfrommap sink method
Mads Kiilerich <madski@unity3d.com> [Mon, 19 May 2014 22:12:30 +0200] rev 21635
convert: introduce hascommitfrommap sink method Mercurial has stable revision identifiers and rollback and strip. Revisions referenced in the shamap are thus not necessarily still present but we can easily check for it. Subversion do not have stable identifiers and no rollback or strip(?). We must thus assume that all revisions referenced from a shamap still must be present. This method is similar to hascommitforsplicemap but different ...
Mon, 19 May 2014 22:11:14 +0200 convert: rename sink hascommit to hascommitforsplicemap
Mads Kiilerich <madski@unity3d.com> [Mon, 19 May 2014 22:11:14 +0200] rev 21634
convert: rename sink hascommit to hascommitforsplicemap The name 'hascommit' sounds like something generic ... but it might also throw exceptions in specific cases and it is thus (apparently) only useful for splicemap.
Mon, 19 May 2014 22:10:50 +0200 tests: better tests for two-way convert
Mads Kiilerich <madski@unity3d.com> [Mon, 19 May 2014 22:10:50 +0200] rev 21633
tests: better tests for two-way convert
Thu, 29 May 2014 12:25:25 -0700 mergetools.hgrc: add minimal configuration for editmerge
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 29 May 2014 12:25:25 -0700] rev 21632
mergetools.hgrc: add minimal configuration for editmerge The ``editmerge`` script is shipped in contrib and opens an editor on every conflicting file. It needs minimal configuration to inject the config marker in the file before opening. Otherwise it behaves the same as ``internal:local`` and bad things happen.
Thu, 29 May 2014 15:41:16 -0700 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 29 May 2014 15:41:16 -0700] rev 21631
merge with stable
Tue, 27 May 2014 21:12:24 -0700 convert: drastically speed up git conversions
David Schleimer <dschleimer@fb.com> [Tue, 27 May 2014 21:12:24 -0700] rev 21630
convert: drastically speed up git conversions We would formerly exec git cat-file once for every commit, plus once for every tree and file we wnated to read. This switches to using git cat-file's batch mode, which is much, much, much faster. Using this new code, converting the git git repo to hg ran in 106 minutes on my machine. Using the stock mercurial, it required 1239 minutes. I believe this to be typical of the speedups we will see form this patch.
Sat, 03 May 2014 19:11:51 +0430 vim: use try catch in vim plugin to avoid conflicts
Ali Vakilzade <ali.vakilzade@gmail.com> [Sat, 03 May 2014 19:11:51 +0430] rev 21629
vim: use try catch in vim plugin to avoid conflicts
Wed, 28 May 2014 15:37:47 -0700 bundle2: raise BundleValueError error for stream level unsupported params
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 28 May 2014 15:37:47 -0700] rev 21628
bundle2: raise BundleValueError error for stream level unsupported params This ensures both consistency and smooth propagation over the wire.
Wed, 28 May 2014 16:46:58 -0700 bundle2: support None parttype in BundleValueError
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 28 May 2014 16:46:58 -0700] rev 21627
bundle2: support None parttype in BundleValueError This will be used for errors at the stream level.
Tue, 27 May 2014 12:16:45 -0700 bundle2: ignore advisory part with unknown parameters
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 27 May 2014 12:16:45 -0700] rev 21626
bundle2: ignore advisory part with unknown parameters Advisory parts are advisory. If a handler exists but does not support the proper parameters, we can safely ignore it. Test has been updated to include this case.
Tue, 27 May 2014 12:01:00 -0700 bundle2: enforce all parameters in a part to be handled
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 27 May 2014 12:01:00 -0700] rev 21625
bundle2: enforce all parameters in a part to be handled Once we picked a handler, we check that all mandatory parameter keys are properly supported. If not we raise an exception. We added a test for this case. The code now fails for any part with unknown mandatory parameters. We will ignore such errors for advisory parts in a later changeset.
Wed, 28 May 2014 11:40:07 -0700 bundle2: declare supported parameters for all handlers
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 28 May 2014 11:40:07 -0700] rev 21624
bundle2: declare supported parameters for all handlers We now update all existing handlers with the supported parameters information.
Tue, 27 May 2014 11:49:48 -0700 bundle2: make it possible to declare params handled by a part handler
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 27 May 2014 11:49:48 -0700] rev 21623
bundle2: make it possible to declare params handled by a part handler If we are to enforce the mandatory aspect of parameter, we need a way to discover what a handler supports. The best option we end up with is this a simple declaration of known parameters at registration time. We simply plug the list of parameters on the function object because Python lets us do that and there is no benefit for a more complicated way. One of the handlers is updated for example and testing.
Wed, 28 May 2014 15:57:23 -0700 bundle2: support transmission of params error over the wire
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 28 May 2014 15:57:23 -0700] rev 21622
bundle2: support transmission of params error over the wire We picked a null character to split each parameter during the transfer. This is fragile if the same character is used in parameter name. However other codes will already behave in a strange way in that case, so we are not introducing any regression. A better format may be picked for the final version of the protocol.
Wed, 28 May 2014 15:53:34 -0700 bundle2: introduce a ``params`` attribute to BundleValueError
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 28 May 2014 15:53:34 -0700] rev 21621
bundle2: introduce a ``params`` attribute to BundleValueError We'll first use it for unsupported mandatory parameters on parts.
Wed, 28 May 2014 15:51:19 -0700 bundle2: introduce a parttype attribute to BundleValueError
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 28 May 2014 15:51:19 -0700] rev 21620
bundle2: introduce a parttype attribute to BundleValueError We will use the Exception for more that just unknown part type.
Tue, 27 May 2014 10:32:07 -0700 bundle2: rename b2x:error:unknownpart to b2x:error:unsupportedcontent
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 27 May 2014 10:32:07 -0700] rev 21619
bundle2: rename b2x:error:unknownpart to b2x:error:unsupportedcontent This is a backward compatibility breakage per se. But bundle2 was explicitly flagged as experimental, and this is one an error path anyway. So the worse possible outcome from this change is to still have a crash but with a different message.
Wed, 28 May 2014 15:31:05 -0700 bundle2: move exception classes into the error module
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 28 May 2014 15:31:05 -0700] rev 21618
bundle2: move exception classes into the error module Exceptions should have known their place.
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.
Thu, 22 May 2014 12:52:09 -0700 bundle2: forbid duplicate parameter keys
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 22 May 2014 12:52:09 -0700] rev 21607
bundle2: forbid duplicate parameter keys No rules were specified about parameter key uniqueness. We document that keys should be unique and document it. This opens the way to a more friendly (read dictionary like) way to access value of parameters in the code.
Fri, 23 May 2014 16:46:30 -0700 bundle2: update part creators to ``addparam`` when relevant
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 23 May 2014 16:46:30 -0700] rev 21606
bundle2: update part creators to ``addparam`` when relevant In some cases, the use of ``addparam`` makes code much clearer.
Thu, 22 May 2014 11:38:40 -0700 bundle2: introduce a ``addparam`` method on part
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 22 May 2014 11:38:40 -0700] rev 21605
bundle2: introduce a ``addparam`` method on part We make it easier to add new parameters after the part creation. As for the ``data`` attribute we make sure the part generation has not begun yet.
Thu, 22 May 2014 11:21:26 -0700 bundle2: the ability to set ``data`` attribute of the part is now official
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 22 May 2014 11:21:26 -0700] rev 21604
bundle2: the ability to set ``data`` attribute of the part is now official We make it safe to set the data attribute after part creation. It is an allowed operation as long as the part has not started to be generated.
Sat, 24 May 2014 16:08:05 -0700 bundle2: introduce a ReadOnlyPartError exception
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 24 May 2014 16:08:05 -0700] rev 21603
bundle2: introduce a ReadOnlyPartError exception As we will introduce functions to alter already created parts, we need a proper exception to raise when code tries to alter a part that cannot be altered anymore.
Fri, 23 May 2014 16:20:30 -0700 bundle2: warn about error during initialization in ``newpart`` docstring
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 23 May 2014 16:20:30 -0700] rev 21602
bundle2: warn about error during initialization in ``newpart`` docstring As we are moving toward being able to alter a part after its creation, we need to make the implication of the part being already part of the bundle2 clear.
Thu, 22 May 2014 11:14:02 -0700 bundle2: track life cycle of parts
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 22 May 2014 11:14:02 -0700] rev 21601
bundle2: track life cycle of parts We introduce a ``_generated`` attribute on parts. Coming changesets will make it easier to update a part's contents after its creation. We need a way to track if the part is still open to modification or if it is currently being generated and should not be touched anymore. As a bonus, we can now detect and crash if someone manages to write bogus code to get a part generated twice.
Fri, 23 May 2014 15:59:19 -0700 bundle2: update all ``addpart`` callers to ``newpart``
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 23 May 2014 15:59:19 -0700] rev 21600
bundle2: update all ``addpart`` callers to ``newpart`` The new method is what we want in all current cases.
Fri, 23 May 2014 15:54:18 -0700 bundle2: have ``newpart`` automatically add the part to the bundle
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 23 May 2014 15:54:18 -0700] rev 21599
bundle2: have ``newpart`` automatically add the part to the bundle The created part is automatically added to the bundle as this is most certainly the intent of the user code.
Fri, 23 May 2014 15:45:46 -0700 bundle2: add a ``newpart`` method to ``bundle20``
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 23 May 2014 15:45:46 -0700] rev 21598
bundle2: add a ``newpart`` method to ``bundle20`` Creating new parts is the most common operation people do when exposed to a bundler. We create a dedicated method on the bundler object for it. This will simplify the code and also avoid having to import the ``mercurial.bundle2`` module in multiple places. One part creators have been updated for testing purpose.
Thu, 22 May 2014 10:48:37 -0700 bundle2: small doc update on the bundler
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 22 May 2014 10:48:37 -0700] rev 21597
bundle2: small doc update on the bundler The `bundle20` class contains methods to help define the content and methods to generate the actual stream. We add small doc headers to help distinguish between the two.
Fri, 25 Apr 2014 15:44:55 -0500 localrepo: replace status method with a shim
Sean Farley <sean.michael.farley@gmail.com> [Fri, 25 Apr 2014 15:44:55 -0500] rev 21596
localrepo: replace status method with a shim The path of the righteous man is beset on all sides by the inequities of the selfish and the tyranny of evil men. Blessed is he, who in the name of charity and good will, shepherds the weak through the valley of darkness, for he is truly Mercurial's keeper and the finder of robust methods. And I will strike down upon thee with great vengeance and furious anger those who would attempt to poison and destroy Mercurial's codebase. And you will know my name is the Lord when I lay my vengeance upon thee.
Tue, 27 May 2014 15:55:35 -0700 workingctx: have status method call super instead of customized code.
Sean Farley <sean.michael.farley@gmail.com> [Tue, 27 May 2014 15:55:35 -0700] rev 21595
workingctx: have status method call super instead of customized code. The old code is unneeded now that basectx has the ability to calculate the status between two context objects. Now, we use the objected oriented pattern called 'super'.
Thu, 24 Apr 2014 18:07:42 -0500 basectx: copy localrepo.status method
Sean Farley <sean.michael.farley@gmail.com> [Thu, 24 Apr 2014 18:07:42 -0500] rev 21594
basectx: copy localrepo.status method Now that all the pieces are in place, we copy the status method from localrepo. In the next few patches, we will remove the old implementation.
Thu, 24 Apr 2014 17:42:53 -0500 committablectx: cache _status in _poststatus
Sean Farley <sean.michael.farley@gmail.com> [Thu, 24 Apr 2014 17:42:53 -0500] rev 21593
committablectx: cache _status in _poststatus A future patch will remove the old workingctx.status which caches the status of the working directory, therefore we now cache this status in the poststatus hook of committablectx.
Thu, 24 Apr 2014 17:31:20 -0500 committablectx: simplify caching the status
Sean Farley <sean.michael.farley@gmail.com> [Thu, 24 Apr 2014 17:31:20 -0500] rev 21592
committablectx: simplify caching the status Previously, workingctx had custom variables for the unknown, ignored, and clean list of files of status. These then got moved to committablectx and, after the refactoring of localrepo.status, are no longer needed. We, therefore, simplify the whole mess. As a bonus, we are able to remove the need for having 'assert'.
Wed, 23 Apr 2014 16:08:20 -0500 localrepo: remove cache code now handled by _prestatus
Sean Farley <sean.michael.farley@gmail.com> [Wed, 23 Apr 2014 16:08:20 -0500] rev 21591
localrepo: remove cache code now handled by _prestatus This patch removes the last of the 'working' variable that was sprinkled throughout localrepo.status which paves the way for future patches to use the object oriented design of contexts to handle calculating the status.
(0) -10000 -3000 -1000 -300 -100 -56 +56 +100 +300 +1000 +3000 +10000 +30000 tip