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.
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.
Matt Mackall <mpm@selenic.com> [Thu, 29 May 2014 16:01:39 -0700] rev 21642
docker: check for docker.io first
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.
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.
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
Mads Kiilerich <madski@unity3d.com> [Tue, 20 May 2014 03:57:21 +0200] rev 21638
buildrpm: various minor cleanup
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.
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.
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 ...
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.
Mads Kiilerich <madski@unity3d.com> [Mon, 19 May 2014 22:10:50 +0200] rev 21633
tests: better tests for two-way convert
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.
Matt Mackall <mpm@selenic.com> [Thu, 29 May 2014 15:41:16 -0700] rev 21631
merge with stable
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.