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.