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.
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 01 Apr 2017 12:45:18 +0200] rev 2265
merge back with default
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
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
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.
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 10:12:02 +0100] rev 2231
stablerange: add a proper debugstablerange commands
This commands allows to inspect the standard stable range of a range. That
should come handy.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:49:03 +0100] rev 2230
debugobshashrange: add a --subranges option
We stop displaying -everything- by default, since is is usually very large. This
will help getting better timing when measuring cache effect too, since we won't
need to dig out deep cache value that real life usage would not touch.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:42:39 +0100] rev 2229
debug: rename 'debugstablerange' to 'debugobshashrange'
The command is more about the 'obshashrange' computation.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:40:50 +0100] rev 2228
debugstablerange: improve output spacing
On repo with a descent amount of changeset the number where overflowing in all
directions. We give use more room now.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:21:05 +0100] rev 2227
subranges: add a utility function to set the cache
This is preparing on disk persistence for the value in this cache.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:18:50 +0100] rev 2226
subranges: add a utility function to access the cache
This is preparing on disk persistence for the value in this cache.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:15:18 +0100] rev 2225
depth: add a utility function to set the cache
This is preparing on disk persistence for the value in this cache.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:01:25 +0100] rev 2224
depth: add a utility function to access the cache
This is preparing on disk persistence for the value in this cache.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 03:20:29 +0100] rev 2223
stablerange: add warming of the subrange
Note that this means we build standard stable subrange for all changesets in the
repository this is significantly more than what we were computing before and
result is significantly more ranges being computed.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 11:04:38 +0100] rev 2222
stablerange: fix merge slicing when range has multiple roots
The first element in the bottom set is not necessarly the one with the lowest
revision. We now properly compute and use the minimum value.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:04:34 +0100] rev 2221
stablerange: small style fix
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 08:16:00 +0100] rev 2220
merge-slicing: introduce and use "inheritance point" for merge
The first part of the stable sorted list of revision of a merge will shared with
the one of others. This means we can reuse subranges computed from that point to
compute some of the subranges from the merge.
That point is latest point in the stable sorted list where the depth of the
revisions match its index (that means all revision earlier in the stable sorted
list are its ancestors, no dangling unrelated branches exists). This is a bit
expensive to find since we have to walk all the revision, but being able to
reuse subranges in all case (not just regular changesets) provide a massive
speedup so the cost is worth it.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 08:31:10 +0100] rev 2219
stablerange: rearrange the code picking subrange to warm
Same logic, as the previous changesets, we prepare the code before adding merge
support.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 08:20:36 +0100] rev 2218
stablerange: rearrange the reusing logic to prepare to merge
We'll soon be able to reuse some lower range when dealing with merge too. So we
prepare the code for this in advance for clarity.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 06:24:02 +0100] rev 2217
merge-slicing: explain an alternative implementation in a comments
It has a better time complexity so a C implementation would likely out perform
the current implementation
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 06:36:12 +0100] rev 2216
merge-slicing: use reachable roots to filter the various branches
Reachable roots does what we want and have a quite fast C implementation.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 05:51:20 +0100] rev 2215
merge-slicing: simplify various aspect of the code
Especially the case were the bottom have single heads is not more efficiently
handled.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 14:17:15 +0100] rev 2214
stablerange: soon it will not provide any benefit and it gets in the way
This was a bit strange and memory consuming anyway.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 06:31:32 +0100] rev 2213
revsfromrange: reuse information from the stablesort
We collaborate with the stablesort to store the order that led to a merge. That
way, when we needs to retrieve revision from that merge we can reuse that order.
We might need to filter to only retains ancestors of the merge we care about but
skipping the stablesort safe a large amount of time.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 03:22:56 +0100] rev 2212
stablesort: allow a callback to be triggered on merge
Storing some information as we sort is going to be useful to avoid performing
multiple sort while computing the stablerange.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 03:33:36 +0100] rev 2211
minor simplification around rangelength
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 03:30:14 +0100] rev 2210
more explicite name in revsfromrange
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 05:15:25 +0100] rev 2209
stablerange: cache parents
We happens to be doing and awful amount of parent call. We cache them locally
for efficiency.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 12:53:39 +0100] rev 2208
merge-slicing: avoid doing the same work twice
We have already computed the list of revision in that bottom slice as 'hrevs' so
we do not need to compute it a second time.