Wed, 20 Aug 2014 18:11:23 -0700 obsolete: rename `allmarkers` to `getmarkers`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 20 Aug 2014 18:11:23 -0700] rev 22273
obsolete: rename `allmarkers` to `getmarkers` This function is going to gain a "nodes" argument to filter the markers to the ones relevant to <nodes> only.
Wed, 20 Aug 2014 00:43:08 -0700 debugobsolete: add a way to record parent information
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 20 Aug 2014 00:43:08 -0700] rev 22272
debugobsolete: add a way to record parent information We add a ``--record-parents`` flag to debugobsolete. This can be used to record parent information in the marker when the precursors are known locally. This will be useful to test the "relevant markers" computation.
Tue, 19 Aug 2014 17:03:10 -0700 obsstore: add relevantmarkers method
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 19 Aug 2014 17:03:10 -0700] rev 22271
obsstore: add relevantmarkers method We add a ``relevantmarkers`` method to fetch all markers that seem relevant to a set of nodes. See function documentation about how this set is computed. This will let us exchange only the markers that seem "relevant" to the set of changesets related to a push or a pull. The approach used to define "relevant" has been successfully tested in evolve for 6 months.
Tue, 19 Aug 2014 16:53:53 -0700 obsstore: keep track of children information
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 19 Aug 2014 16:53:53 -0700] rev 22270
obsstore: keep track of children information We use the new `parents` field to build a dictionary of markers that touch children of a node. This will be used to link prune markers to a set of exchanged nodes.
Wed, 20 Aug 2014 17:36:54 -0700 push: check if local and remote support evolution during discovery
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 20 Aug 2014 17:36:54 -0700] rev 22269
push: check if local and remote support evolution during discovery We can now directly prevent any evolution-related operation from happening by using an empty set for outgoing markers. So we detect if no transfers should occur and use an empty set in this case.
Tue, 19 Aug 2014 16:46:17 -0700 obsstore: drop outdated comment
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 19 Aug 2014 16:46:17 -0700] rev 22268
obsstore: drop outdated comment This comment was associated with a now-defunct line.
Thu, 21 Aug 2014 10:07:30 -0400 cvsps: add two more tiebreakers in cscmp
Augie Fackler <raf@durin42.com> [Thu, 21 Aug 2014 10:07:30 -0400] rev 22267
cvsps: add two more tiebreakers in cscmp test-convert-cvs.t has been a little flaky for a while now. Add an extra tiebreaker in cscmp so that all the cases in the test will sort reliably. Without this patch, test-convert-cvs.t failed after 346 runs. With this patch, I stopped trying to get it to fail after 615 runs. While not conclusive, that makes me pretty optimistic that this is a working fix.
Sat, 16 Aug 2014 17:59:26 +0900 annotate: abort early if no file is specified
Yuya Nishihara <yuya@tcha.org> [Sat, 16 Aug 2014 17:59:26 +0900] rev 22266
annotate: abort early if no file is specified This change is intended to move the getdate function near the opmap table.
Wed, 20 Aug 2014 15:07:25 -0700 purge: avoid full walks when directories aren't purged
Siddharth Agarwal <sid0@fb.com> [Wed, 20 Aug 2014 15:07:25 -0700] rev 22265
purge: avoid full walks when directories aren't purged If match.traversedir is not None, we're forced to do full walks. However when we aren't purging directories we don't need to set match.traversedir to anything. This speeds up non-full walks such as the one hgwatchman makes possible. For mozilla-central with hgwatchman enabled, 'hg purge --files' goes from 0.88 seconds to 0.22.
Thu, 21 Aug 2014 16:05:29 -0700 clone: for local clones, copy over filtered branchcaches as well (issue4286)
Siddharth Agarwal <sid0@fb.com> [Thu, 21 Aug 2014 16:05:29 -0700] rev 22264
clone: for local clones, copy over filtered branchcaches as well (issue4286) Local clones copy/hardlink over files directly, so the branchcaches should all be valid. There's a slight chance that a read operation would update one of the branchcaches, but we hold a lock over the source repo so they shouldn't cause an invalid branchcache to be copied over, just a different, valid one.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip