Sun, 09 Mar 2014 01:03:28 +0900 repair: make "strip()" treat bundle files via vfs
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 09 Mar 2014 01:03:28 +0900] rev 20979
repair: make "strip()" treat bundle files via vfs This patch makes "repair.strip()" treat bundle files via vfs. This patch also avoids applying "vfs.join()" on the value returned by "changegroup.writebundle()", to get relative path from "_bundle()".
Sun, 09 Mar 2014 01:03:28 +0900 changegroup: add "vfs" argument to "readbundle()" to pass relative filename
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 09 Mar 2014 01:03:28 +0900] rev 20978
changegroup: add "vfs" argument to "readbundle()" to pass relative filename
Sun, 09 Mar 2014 01:03:28 +0900 repair: make paths in "_bundle()" relative to ".hg"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 09 Mar 2014 01:03:28 +0900] rev 20977
repair: make paths in "_bundle()" relative to ".hg" This patch makes paths below in "_bundle()" relative to ".hg": - backup directory ("strip-backup"), and - bundle file under backup directory "vfs" is passed to "changegroup.writebundle()" to use relative path directly. This patch applies "vfs.join()" on the value returned by "_bundle()", because the caller expect it to return absolute path. This will be changed by succeeding patch changing the caller side.
Sun, 09 Mar 2014 01:03:28 +0900 changegroup: add "vfs" argument to "writebundle()" for relative access via vfs
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 09 Mar 2014 01:03:28 +0900] rev 20976
changegroup: add "vfs" argument to "writebundle()" for relative access via vfs Before this patch, filename specified to "changegroup.writebundle()" should be absolute one. In some cases, they should be relative to repository root, store and so on (backup before strip, for example). This patch adds "vfs" argument to "writebundle()", and makes "writebundle()" open (and unlink) "filename" via vfs for relative access, if both filename and vfs are specified.
Sun, 09 Mar 2014 01:03:28 +0900 localrepo: make "undofiles()" return list of tuples "(vfs, relative filename)"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 09 Mar 2014 01:03:28 +0900] rev 20975
localrepo: make "undofiles()" return list of tuples "(vfs, relative filename)" Before this patch, "localrepository.undofiles()" returns list of absolute filename of undo files. This patch makes it return list of tuples "(vfs, relative filename)" to access undo files via vfs. This patch also changes "repair.strip()", which is the only user of "localrepository.undofiles()".
Fri, 11 Apr 2014 17:20:15 -0400 exchange: fix pyflakes import complaint
Matt Mackall <mpm@selenic.com> [Fri, 11 Apr 2014 17:20:15 -0400] rev 20974
exchange: fix pyflakes import complaint
Thu, 10 Apr 2014 15:12:12 +0800 hgweb: override the charset attribute in the http request
Wei, Elson <elson.wei@gmail.com> [Thu, 10 Apr 2014 15:12:12 +0800] rev 20973
hgweb: override the charset attribute in the http request The default http request character set is UTF-8. If the message is not encoded in UTF-8, such as big5, it cannot be shown correctly. The 'charset' is overridden by the root document's, such that the user can select the proper encoding in the browser.
Fri, 11 Apr 2014 16:38:55 -0400 diff: use second filename for --stat reporting on git patches (issue4221)
Matt Mackall <mpm@selenic.com> [Fri, 11 Apr 2014 16:38:55 -0400] rev 20972
diff: use second filename for --stat reporting on git patches (issue4221)
Fri, 11 Apr 2014 13:43:41 -0400 exchange: drop useless line break
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 11 Apr 2014 13:43:41 -0400] rev 20971
exchange: drop useless line break
Fri, 11 Apr 2014 15:38:18 -0400 subrepo: check return code for git push (issue4223)
Matt Mackall <mpm@selenic.com> [Fri, 11 Apr 2014 15:38:18 -0400] rev 20970
subrepo: check return code for git push (issue4223)
Fri, 04 Apr 2014 17:50:44 -0700 localrepo: add unbundle support
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 04 Apr 2014 17:50:44 -0700] rev 20969
localrepo: add unbundle support Localrepo now supports the unbundle method of pushing changegroups. We plan to use the unbundle call for bundle2 so it is important that all peers supports it. The `peer.unbundle` and `peer.addchangegroup` code path have small difference so cause some test output changes. None of those changes seems problematic.
Fri, 04 Apr 2014 17:28:59 -0700 unbundle: extract the core logic in another function
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 04 Apr 2014 17:28:59 -0700] rev 20968
unbundle: extract the core logic in another function The `exchange` module now contains an `unbundle` function that holds the core unbundle logic. The wire protocol keeps its own unbundle function. It enforces wireprotocol-specific logic and then calls the extracted function. This aims at implementing unbundle for localrepo.
Fri, 04 Apr 2014 17:15:25 -0700 unbundle: extract checkheads in its own function
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 04 Apr 2014 17:15:25 -0700] rev 20967
unbundle: extract checkheads in its own function We are going to refactor the unbundle function to have it working on a local repository too. Having this function extracted will ease the process. In the case of non-matching heads, the function now directly raises an exception. The top level of the function is catching it.
Mon, 07 Apr 2014 18:10:50 -0700 phase: apply publishing enforcement for "serve" source
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 07 Apr 2014 18:10:50 -0700] rev 20966
phase: apply publishing enforcement for "serve" source When a changegroup is added by a push on a publishing server, we ensure they are added as public. This is used to enforce publishing on server when the client is not aware of phases. It also prevents race conditions where a reader could see the changesets as draft before they get turned public by the client. Finally, this save rounds trip as the client does not need additional request to turn them public. However, this logic was only enforced when the changegroup was from a "push" source. And "push" is used for local pushes only. Wireprotocol push uses "serve" as source since Mercurial 1.9. We now enforce this logic for both "push" and "serve" sources. One could note that this logic was mainly useful during wireprotocol exchanges. So this code is finally put into good use, 9 versions after its introduction.
Thu, 10 Apr 2014 12:41:39 -0400 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 10 Apr 2014 12:41:39 -0400] rev 20965
merge with stable
Fri, 20 Dec 2013 14:56:05 +0100 http: reuse authentication info after the first failed request (issue3567)
Stéphane Klein <contact@stephane-klein.info> [Fri, 20 Dec 2013 14:56:05 +0100] rev 20964
http: reuse authentication info after the first failed request (issue3567) [This was applied in 181108726ea5 but backed out again in af02783dea65 because of Python 2.4 issues. This edition and test-http.t works with Python 2.4.] Context: mercurial access to repository server with http access, and this server is protected by basic auth. Before patch: * mercurial try an anonymous access to server, server return 401 response and mercurial resend request with login / password information After patch: * mercurial try an anonymous access to server, server return 401 response. For all next requests, mercurial keep in memory this information (this server need basic auth information). This patch reduce the number of http access against mercurial server. Example, before patch: 10.10.168.170 - - [25/Oct/2013:15:44:51 +0200] "GET /hg/testagt?cmd=capabilities HTTP/1.1" 401 260 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:44:52 +0200] "GET /hg/testagt?cmd=capabilities HTTP/1.1" 200 147 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:00 +0200] "GET /hg/testagt?cmd=capabilities HTTP/1.1" 401 260 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:01 +0200] "GET /hg/testagt?cmd=capabilities HTTP/1.1" 200 147 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:03 +0200] "GET /hg/testagt?cmd=batch HTTP/1.1" 401 260 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:04 +0200] "GET /hg/testagt?cmd=batch HTTP/1.1" 200 42 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:06 +0200] "GET /hg/testagt?cmd=getbundle HTTP/1.1" 401 260 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:07 +0200] "GET /hg/testagt?cmd=getbundle HTTP/1.1" 200 61184 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:09 +0200] "GET /hg/testagt?cmd=listkeys HTTP/1.1" 401 260 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:10 +0200] "GET /hg/testagt?cmd=listkeys HTTP/1.1" 200 15 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:12 +0200] "GET /hg/testagt?cmd=listkeys HTTP/1.1" 401 260 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:12 +0200] "GET /hg/testagt?cmd=listkeys HTTP/1.1" 200 - "-" "mercurial/proto-1.0" Example after patch: 10.10.168.170 - - [28/Oct/2013:11:49:14 +0100] "GET /hg/testagt?cmd=capabilities HTTP/1.1" 401 260 "-" "mercurial/proto-1.0" 10.10.168.170 - - [28/Oct/2013:11:49:15 +0100] "GET /hg/testagt?cmd=capabilities HTTP/1.1" 200 147 "-" "mercurial/proto-1.0" 10.10.168.170 - - [28/Oct/2013:11:49:17 +0100] "GET /hg/testagt?cmd=batch HTTP/1.1" 200 42 "-" "mercurial/proto-1.0" 10.10.168.170 - - [28/Oct/2013:11:49:19 +0100] "GET /hg/testagt?cmd=getbundle HTTP/1.1" 200 61184 "-" "mercurial/proto-1.0" 10.10.168.170 - - [28/Oct/2013:11:49:22 +0100] "GET /hg/testagt?cmd=listkeys HTTP/1.1" 200 15 "-" "mercurial/proto-1.0" 10.10.168.170 - - [28/Oct/2013:11:49:24 +0100] "GET /hg/testagt?cmd=listkeys HTTP/1.1" 200 - "-" "mercurial/proto-1.0" In this last example, you can see only one 401 response.
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.
Fri, 04 Apr 2014 17:47:19 -0500 tests: fix test output typo
Matt Mackall <mpm@selenic.com> [Fri, 04 Apr 2014 17:47:19 -0500] rev 20951
tests: fix test output typo
Mon, 24 Mar 2014 19:37:59 -0700 bundle2: first crude version of bundling changeset with bundle2
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 24 Mar 2014 19:37:59 -0700] rev 20950
bundle2: first crude version of bundling changeset with bundle2 The current changegroup format is put in a "changegroup" part and processed by an appropriate handlers. This is not production ready code, but let us start smoke testing.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 +30000 tip