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
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
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
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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".
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.
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 15:56:57 +0100] rev 2238
stablerange: warm cache on transaction (if obshashrange is enabled)
If we plan to use it (obshashrange is enabled) we better keep it up to date. If
a transaction adds node, we update the cache (this should also update the on
disk version).
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 16:05:28 +0100] rev 2237
stablerange: introduce ondisk caching through sqlite
There is many short cut and limitation with this first version of a cache but
this allow use to envision some actual usage of the stablerange thingy so let us
got for it.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 18:41:55 +0100] rev 2236
stablerange: drop the cache on 'destroyed'
if the repository have been strip, the cache is not usable as is. We could be
smarter in the invalidation but that is a prototype anyway.
G: changed hgext3rd/evolve/stablerange.py
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 11:27:56 +0100] rev 2235
stablerange: support loading the cache iteratively
We record how far we loaded so that we can resume from this point.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 11:20:42 +0100] rev 2234
stablerange: add some basic documentation about the cache
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 11:18:01 +0100] rev 2233
stablerange: warmup all upto a revision
Let us start doing more systemic warming of the cache before we start writing
things out. This prepare on disk caching.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 10:22:38 +0100] rev 2232
debugstablerange: add a --verify flag to the command
This should help us finding bugs.