Sat, 08 Apr 2017 12:48:20 +0200 tests: update test to match upstreamable version stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 08 Apr 2017 12:48:20 +0200] rev 2268
tests: update test to match upstreamable version Name have been clarified, documentation has been updated and some test-case have been updated to match the intended test.
Sat, 08 Apr 2017 12:45:39 +0200 tests: fix directory names in exchange-D4 test stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 08 Apr 2017 12:45:39 +0200] rev 2267
tests: fix directory names in exchange-D4 test The test is based on another one and the directory name had not been updated.
Sat, 08 Apr 2017 12:43:36 +0200 tests: fix directory names in exchange-D3 test stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 08 Apr 2017 12:43:36 +0200] rev 2266
tests: fix directory names in exchange-D3 test The test is based on another one and the directory name had not been updated.
Sat, 01 Apr 2017 12:45:18 +0200 merge back with default
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 01 Apr 2017 12:45:18 +0200] rev 2265
merge back with default
Fri, 31 Mar 2017 15:51:58 +0200 Added tag 6.0.0 for changeset 165ad227993d stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 15:51:58 +0200] rev 2264
Added tag 6.0.0 for changeset 165ad227993d
Fri, 31 Mar 2017 15:51:27 +0200 packaging: prepare version 6.0.0 stable 6.0.0
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 15:51:27 +0200] rev 2263
packaging: prepare version 6.0.0
Fri, 31 Mar 2017 15:47:31 +0200 merged with future 6.0 mercurial-3.8
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 15:47:31 +0200] rev 2262
merged with future 6.0 No output changed.
Fri, 31 Mar 2017 15:44:10 +0200 test-compat-hg-3.9: merge with future 6.0 mercurial-3.9
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 15:44:10 +0200] rev 2261
test-compat-hg-3.9: merge with future 6.0
Fri, 31 Mar 2017 15:39:20 +0200 merge with future 6.0.0 mercurial-4.0
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 15:39:20 +0200] rev 2260
merge with future 6.0.0
Fri, 31 Mar 2017 15:33:59 +0200 merge with default stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 15:33:59 +0200] rev 2259
merge with default We are getting close to cutting a 6.0.0
Fri, 31 Mar 2017 14:50:50 +0200 readme: mention the fix for issue4354
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 14:50:50 +0200] rev 2258
readme: mention the fix for issue4354
Fri, 31 Mar 2017 15:02:39 +0200 checkheads: add a small debug message in case were we give up fast
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 15:02:39 +0200] rev 2257
checkheads: add a small debug message in case were we give up fast When node is unknown we assume it will stay. Yet, we might have markers to it that are going to be pushed. However, we do not have branch (ancestors) information unless we are very lucky an all of them are pruned. So for now we do not do anything assuming this will be rare. We still add a small debug message to help detecting such situation in the future.
Fri, 31 Mar 2017 13:46:51 +0200 checkheahds: switch algorithm to use pushed markers instead
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 13:46:51 +0200] rev 2256
checkheahds: switch algorithm to use pushed markers instead We now checks if markers involved in the push are relevant to nodes in the branch we try to replace. The approach is simpler and more robust. A test showing the limitation of the previous approach is added.
Fri, 31 Mar 2017 13:47:14 +0200 checkheads: add test where the rewrite of the other branch is not direct
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 13:47:14 +0200] rev 2255
checkheads: add test where the rewrite of the other branch is not direct This will help testing that our logic is properly transitive.
Fri, 31 Mar 2017 13:45:26 +0200 check-heads: add tests about old heads indirectly pruned
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 13:45:26 +0200] rev 2254
check-heads: add tests about old heads indirectly pruned
Wed, 29 Mar 2017 17:50:33 +0200 checkheads: add more complexe case where a branch is split on multiple ones
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 29 Mar 2017 17:50:33 +0200] rev 2253
checkheads: add more complexe case where a branch is split on multiple ones We extend case A-6 and A-7 with partial counterpart. These case are interesting because some of the partial pushing will (rightfully) works and some other won't.
Wed, 29 Mar 2017 17:35:55 +0200 checkheads: add a test of partially pushing a branch spread on multiple other
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 29 Mar 2017 17:35:55 +0200] rev 2252
checkheads: add a test of partially pushing a branch spread on multiple other If a branch is fully obsolete but is result are spread on multiple branch, pushing only one of them should detect we create new branches.
Fri, 31 Mar 2017 13:42:28 +0200 checkheads-tests: add missing parents recording for prune markers
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 31 Mar 2017 13:42:28 +0200] rev 2251
checkheads-tests: add missing parents recording for prune markers It is a bit too easy to forget about theses :/ If they are missing, the markers are not going to be exchanged on push.
Wed, 29 Mar 2017 14:02:46 +0200 checkheads: add some extra tests about "partial push"
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 29 Mar 2017 14:02:46 +0200] rev 2250
checkheads: add some extra tests about "partial push" This adds a couple of test that checks that the head replacement code is properly ignored replacement not relevant to the push.
Wed, 29 Mar 2017 15:48:27 +0200 checkheads: handle partial obsolescence
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 29 Mar 2017 15:48:27 +0200] rev 2249
checkheads: handle partial obsolescence We now properly detects situations were only parts of the remote branch is obsoleted. To do so, we process children in the branch recursively to see if they will be obsolete. The current code has some trouble when the remote branch in unknown locally, or when the prune happened on a successors that is not relevant to the push. These case will be handled later. The processing code is becoming more and more complex, a lighter approach would be to check for the obsolescence markers that are relevant to the pushed set, but I prefer to stick with the current approach until more test cases are written.
Wed, 29 Mar 2017 16:41:42 +0200 test: force a push in inhibit's test
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 29 Mar 2017 16:41:42 +0200] rev 2248
test: force a push in inhibit's test Our checkheads detection code is becoming better and will prevent that push. As we do not care about this for inhibit, we simply force the push.
Tue, 21 Mar 2017 12:30:53 +0100 checkheads: basic handling of pruned heads (and associated tests)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Mar 2017 12:30:53 +0100] rev 2247
checkheads: basic handling of pruned heads (and associated tests) We now detect that heads was pruned and stop warning about it. Note that this has the same shortcoming as the existing code and only looks at the heads.
Wed, 29 Mar 2017 16:28:15 +0200 checkheads: give up on processing locally unknown changeset
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 29 Mar 2017 16:28:15 +0200] rev 2246
checkheads: give up on processing locally unknown changeset There are too many issue with locally unknown changesets, we ignore them for now while we get the core feature of the detection working.
Tue, 21 Mar 2017 23:44:30 +0100 checkheads: import our own copy of the checkheads code
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Mar 2017 23:44:30 +0100] rev 2245
checkheads: import our own copy of the checkheads code I expect enough change and experimental will be made that is it worthwhile having them done in evolution close to the rest of the exchange tests make sense.
Sun, 26 Mar 2017 04:59:36 +0200 compat: work around some filecache bug in 3.8
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 26 Mar 2017 04:59:36 +0200] rev 2244
compat: work around some filecache bug in 3.8 We are still compatible with this version.
Fri, 24 Mar 2017 18:21:48 +0100 obshashrange: have an half descent wireprotocol command
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 18:21:48 +0100] rev 2243
obshashrange: have an half descent wireprotocol command The previous implementation was extremely hacky. The new version is based on the other discovery function and work!
Fri, 24 Mar 2017 18:37:03 +0100 obshashrange: improve message issued during discovery
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 18:37:03 +0100] rev 2242
obshashrange: improve message issued during discovery This is a minor new message that help to understand what is going on.
Fri, 24 Mar 2017 18:28:01 +0100 obshashrange: introduce basic sqlite caching
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 18:28:01 +0100] rev 2241
obshashrange: introduce basic sqlite caching Same as for stablerange, this is far from perfect but already a win. The cache is currently extremely volatile, but that will still be a win when doing multiple consecutive request during discovery. Better cache invalidation will happens "in the future".
Fri, 24 Mar 2017 15:57:54 +0100 stablerange: warm cache before using it server side
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 15:57:54 +0100] rev 2240
stablerange: warm cache before using it server side We make sure the cache is fully up to date before starting to use it. Updating all value is more efficient and this give us a single point where we update and write on disk. Hopefully the cache have been kept up to date as we go anyway.
Fri, 24 Mar 2017 15:57:08 +0100 stablerange: warm cache before using it in findrangemissing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 15:57:08 +0100] rev 2239
stablerange: warm cache before using it in findrangemissing We make sure the cache is fully up to date before starting to use it. Updating all value is more efficient and this give us a single point where we update and write on disk. Hopefully the cache have been kept up to date as we go anyway.
(0) -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip