Tue, 08 Apr 2014 13:05:29 -0700 bundle2: use discard to remove bundle2 cap
Durham Goode <durham@fb.com> [Tue, 08 Apr 2014 13:05:29 -0700] rev 20963
bundle2: use discard to remove bundle2 cap caps.remove('bundle2') was throwing an exception if bundle2 wasn't present in the capabilities. This was causing test-static-http.t to hang. Let's just use discard, so we don't get an exception.
Mon, 07 Apr 2014 11:45:50 -0700 statichttp: respect localrepo _restrictcapabilities
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 07 Apr 2014 11:45:50 -0700] rev 20962
statichttp: respect localrepo _restrictcapabilities The static http repository was doing his own filtering of capability ignoring the filtering done in the local repo main class. This led to static http using the current draft of bundle2. We now apply both.
Mon, 07 Apr 2014 23:10:20 +0200 tests: make unshelve tests more tricky - don't depend on size change
Mads Kiilerich <madski@unity3d.com> [Mon, 07 Apr 2014 23:10:20 +0200] rev 20961
tests: make unshelve tests more tricky - don't depend on size change One reason shelve and largefiles doesn't work could be rapidly changing standin files. Prove that shelve in general doesn't have problems with that.
Mon, 07 Apr 2014 23:10:20 +0200 shelve: introduce secret option for using fixed date for temporary commit
Mads Kiilerich <madski@unity3d.com> [Mon, 07 Apr 2014 23:10:20 +0200] rev 20960
shelve: introduce secret option for using fixed date for temporary commit Using a fixed date makes hashes stable and makes debugging simpler. The date and hashes of this changeset are normally not exposed.
Mon, 07 Apr 2014 23:10:20 +0200 mq: repo['.'] is not a wctx, repo[None] is
Mads Kiilerich <madski@unity3d.com> [Mon, 07 Apr 2014 23:10:20 +0200] rev 20959
mq: repo['.'] is not a wctx, repo[None] is The parameters passed to subrepo.submerge are confusing anyway.
Mon, 07 Apr 2014 23:10:20 +0200 shelve: repo['.'] is not a wctx but a pctx
Mads Kiilerich <madski@unity3d.com> [Mon, 07 Apr 2014 23:10:20 +0200] rev 20958
shelve: repo['.'] is not a wctx but a pctx Don't confuse hackers!
Mon, 07 Apr 2014 14:18:10 -0500 revlog: deal with chunk ranges over 2G on Windows (issue4215) stable
Matt Mackall <mpm@selenic.com> [Mon, 07 Apr 2014 14:18:10 -0500] rev 20957
revlog: deal with chunk ranges over 2G on Windows (issue4215) Python uses a C long (32 bits on Windows 64) rather than an ssize_t in read(), and thus has a 2G size limit. Work around this by falling back to reading one chunk at a time on overflow. This approximately doubles our headroom until we run back into the size limit on single reads.
Fri, 04 Apr 2014 16:41:51 -0700 exchange: pass bundlecaps through to changegroup
Durham Goode <durham@fb.com> [Fri, 04 Apr 2014 16:41:51 -0700] rev 20956
exchange: pass bundlecaps through to changegroup The bundlecaps passed to exchange.getbundle were being dropped completely. We should pass them on through to the changegroup. This affected the remotefilelog extension, since it relies on those bundlecaps.
Tue, 01 Apr 2014 23:41:32 -0700 bundle2: allow pulling changegroups using bundle2
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 01 Apr 2014 23:41:32 -0700] rev 20955
bundle2: allow pulling changegroups using bundle2 This changeset refactors the pull code to use a bundle2 when available. We keep bundle2 disabled by default. The current code is not ready for prime time. Ultimately we'll want to unify the API of `bunde10` and `bundle20` to have less different code. But for now, testing the bundle2 exchange flow is an higher priority.
Fri, 04 Apr 2014 01:51:54 -0700 bundle2: add an exchange.getbundle function
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 04 Apr 2014 01:51:54 -0700] rev 20954
bundle2: add an exchange.getbundle function This function can return a `HG10` or `HG20` bundle. It uses the `bundlecaps` parameters to decides which one to return. This is a distinct function from `changegroup.getbundle` for two reasons. First the APIs of `bundle10` and `bundle20` are not compatible yet. The two functions may be reunited in the future. Second `exchange.getbundle` will grow parameters for all kinds of data (phases, obsmarkers, ...) so it's better to keep the changegroup generation in its own function for now. This function will be used it in the next changesets.
Fri, 04 Apr 2014 01:33:20 -0700 localpeer: propagate bundlecaps in getbundle call
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 04 Apr 2014 01:33:20 -0700] rev 20953
localpeer: propagate bundlecaps in getbundle call Best arguments are the ones in use...
Wed, 02 Apr 2014 23:56:49 -0700 bundle2: make it possible have a global transaction for the unbundling
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 02 Apr 2014 23:56:49 -0700] rev 20952
bundle2: make it possible have a global transaction for the unbundling We use the `gettransaction` method approach already used for pull. We need this because we do not know beforehand if the bundle needs a transaction to be created. And (1) we do not want to create a transaction for nothing. (2) Some bundle2 bundles may be read-only and do not require any lock or transaction to be held.
(0) -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 +10000 +30000 tip