Fri, 28 Feb 2014 13:38:19 -0800 exchange: pull markers relevant to the pulled subset only
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 28 Feb 2014 13:38:19 -0800] rev 824
exchange: pull markers relevant to the pulled subset only With the command recently introduced we can select to pull only markers relevant to some nodes. We are now pull all markers for all node in the relevant subset. We'll try to pull less (just markers for node where local and remote marker diverge) later, but we need some marker discovery mechanism for that. which are not easy.
Fri, 28 Feb 2014 13:25:34 -0800 exchange: add a new method to pull markers
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 28 Feb 2014 13:25:34 -0800] rev 823
exchange: add a new method to pull markers It has both local and wire protocol implementation. This command does not requires escaping of the marker and are expecting to me highly faster than the pushkey method. The other main point is that command is to accept a `heads` and `common` argument to select to pull changeset only relevant to a set a of node. We are not using this capability yet but we'll do it soon
Fri, 28 Feb 2014 00:55:34 -0800 exchange: add the pushmarker wireproto command to simple4server
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 28 Feb 2014 00:55:34 -0800] rev 822
exchange: add the pushmarker wireproto command to simple4server This will allow simple server side support. (yes, code duplication is bad, I won't do it too much mom)
Fri, 28 Feb 2014 00:40:29 -0800 exchange: introduce a wireprotocol command to push markers
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 28 Feb 2014 00:40:29 -0800] rev 821
exchange: introduce a wireprotocol command to push markers Pushkey is not adapted to transmit a stream of binary data. We used it as a hack so far. We add a new wire protocol command to speed the things up (and also push all the markers in a single transaction). The proper way to do it is to introduce bundle2 in core, but this will already help in the mean time.
Fri, 28 Feb 2014 10:30:10 -0800 exchange: actually use _pushkeyescape fallback
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 28 Feb 2014 10:30:10 -0800] rev 820
exchange: actually use _pushkeyescape fallback The code was still calling `obsolete._pushkeyescape` therefore never calling the fallback we defined. Now that we call it, it had to be fixed to actually work too.
Mon, 03 Mar 2014 19:28:43 -0800 merge with stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 03 Mar 2014 19:28:43 -0800] rev 819
merge with stable
Mon, 03 Mar 2014 19:27:42 -0800 prune: accept '0 0' as a valide --date value stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 03 Mar 2014 19:27:42 -0800] rev 818
prune: accept '0 0' as a valide --date value I 've no idea why 4c0f6d555032 introduced it with this check.
Thu, 27 Feb 2014 19:58:08 -0800 exchange: only push the set of marker relevant to want we push
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 27 Feb 2014 19:58:08 -0800] rev 817
exchange: only push the set of marker relevant to want we push We now compute all markers relevant to pushed set. And just send just those one. So you are no longer pushing markers that point to changeset your are not pushing. See the in line comment for details about what "relevant" is. Multiple nice output have been added in the process.
Thu, 27 Feb 2014 18:30:55 -0800 evolve: add relevant marker exchange machinery
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 27 Feb 2014 18:30:55 -0800] rev 816
evolve: add relevant marker exchange machinery This is going to be needed for obsolescence marker exchange.
Thu, 27 Feb 2014 17:20:34 -0800 fastobs: rename var from `node` to `rev`
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 27 Feb 2014 17:20:34 -0800] rev 815
fastobs: rename var from `node` to `rev` It contains revision (from repo.revs not node).
Thu, 27 Feb 2014 17:11:09 -0800 fastobs: move the extension to the hgext dir
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 27 Feb 2014 17:11:09 -0800] rev 814
fastobs: move the extension to the hgext dir
Wed, 26 Feb 2014 15:25:33 -0800 test-prune: update test with a prune output compatible with newest hg
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 26 Feb 2014 15:25:33 -0800] rev 813
test-prune: update test with a prune output compatible with newest hg Newest hg can record the parent information in the marker. This change the debugobsstorestate output a lot.
Tue, 25 Feb 2014 11:14:37 -0800 drophack: major speedup to marker stripping
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 25 Feb 2014 11:14:37 -0800] rev 812
drophack: major speedup to marker stripping It appear that each call to obsstore.add have a significant overhead (in particular the creation of a set form the list of markers and file system operation to the obsstore file. We now compute the marker we need to store and write them in a single call.
Mon, 24 Feb 2014 19:01:12 -0800 evolve: add a cmddebugrecordpruneparents command
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 24 Feb 2014 19:01:12 -0800] rev 811
evolve: add a cmddebugrecordpruneparents command This command can be used to create prune marker with parent information from prune marker on changeset known locally.
Mon, 24 Feb 2014 17:44:12 -0800 debugobsstorestat: add test for pruning
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 24 Feb 2014 17:44:12 -0800] rev 810
debugobsstorestat: add test for pruning There is multiple prune specific code in this command. So we test it in the presence of prun marker too.
(0) -300 -100 -15 +15 +100 +300 +1000 +3000 tip