Tue, 09 May 2017 17:43:39 +0200 obshistory: add some color
Boris Feld <boris.feld@octobus.net> [Tue, 09 May 2017 17:43:39 +0200] rev 2337
obshistory: add some color
Wed, 10 May 2017 12:26:33 +0200 obshistory: add a debugobshistory command to show obs history of a revs
Boris Feld <boris.feld@octobus.net> [Wed, 10 May 2017 12:26:33 +0200] rev 2336
obshistory: add a debugobshistory command to show obs history of a revs Add the debugobshistory command that accept a revision range and display the obsolescence containing each revision in the range. For the moment, it only displays the predecessors.
Wed, 10 May 2017 12:16:01 +0200 tests: add the commit style checker from Mercurial
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 10 May 2017 12:16:01 +0200] rev 2335
tests: add the commit style checker from Mercurial
Tue, 09 May 2017 19:13:12 +0200 obscache: update the cache key in place
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 09 May 2017 19:13:12 +0200] rev 2334
obscache: update the cache key in place Instead of computing the key in place, we update the existing one using the data used for the incremental update of the content. This will help reaching purely incremental cache eventually. The 'getcachekey' function is dropped as it is no longer used.
Tue, 09 May 2017 19:02:04 +0200 obscache: distinct 'clear' and 'reset'
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 09 May 2017 19:02:04 +0200] rev 2333
obscache: distinct 'clear' and 'reset' We make a difference between basic invalidatiton (or lack of loading) and 'reset' (current cache data are invalid). We can now ensure a non-None key when we start the update. This will allow us to "update" the existing key instead of recomputing one from scratch. This is more efficient and less racy.
Thu, 04 May 2017 21:24:02 +0200 merge with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 04 May 2017 21:24:02 +0200] rev 2332
merge with stable
Thu, 04 May 2017 21:21:59 +0200 serveronly: also enable the obscache for server only setting stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 04 May 2017 21:21:59 +0200] rev 2331
serveronly: also enable the obscache for server only setting The obscache is useful and speeds things up. So we also enable for server only setting.
Thu, 04 May 2017 14:02:30 +0200 obscache: document a possible way forward to skipping obsstore parsing
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 04 May 2017 14:02:30 +0200] rev 2330
obscache: document a possible way forward to skipping obsstore parsing We document a possibly viable idea for updating the cache on new revs without having to fully parse the obsstore.
Wed, 03 May 2017 23:07:01 +0200 obscache: update some documentation
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 23:07:01 +0200] rev 2329
obscache: update some documentation Update some data and do some proof reading.
Wed, 03 May 2017 21:47:06 +0200 obscache: Only access the new obsmarkers for marker update
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 21:47:06 +0200] rev 2328
obscache: Only access the new obsmarkers for marker update Since we know what what is the part of the file with "new" markers we can just access these. If the cache was up to date before the transaction, we'll re-parse data we just wrote. See the inline comment for details. This is good enough for now.
Wed, 03 May 2017 20:56:26 +0200 obscache: extract _updatemarkers code into its own function
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 20:56:26 +0200] rev 2327
obscache: extract _updatemarkers code into its own function This split the update logic from the bit retrieving markers. That cannot be bad.
Wed, 03 May 2017 18:46:48 +0200 obscache: extract code to update from new revision
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 18:46:48 +0200] rev 2326
obscache: extract code to update from new revision Code cleanup and prepare upstreaming. The make the code more likely to work with the key validation returning an iterator of revs to update the cache with.
Wed, 03 May 2017 18:33:53 +0200 obscache: move assert earlier in the code
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 18:33:53 +0200] rev 2325
obscache: move assert earlier in the code If we are to crash, let us crash earlier.
Wed, 03 May 2017 13:58:32 +0200 merge back with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 13:58:32 +0200] rev 2324
merge back with stable
Wed, 03 May 2017 13:58:06 +0200 Added tag 6.1.0 for changeset 8510d3fd7c3b stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 13:58:06 +0200] rev 2323
Added tag 6.1.0 for changeset 8510d3fd7c3b
Wed, 03 May 2017 13:57:55 +0200 packaging: prepare version 6.1.0 stable 6.1.0
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 13:57:55 +0200] rev 2322
packaging: prepare version 6.1.0
Wed, 03 May 2017 13:54:12 +0200 meta: update tested version to 4.1.2 stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 13:54:12 +0200] rev 2321
meta: update tested version to 4.1.2 We tested against the latest 4.1 too.
Wed, 03 May 2017 13:52:19 +0200 merge with future 6.1.0 mercurial-3.8
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2017 13:52:19 +0200] rev 2320
merge with future 6.1.0 No extra adjustment needed from hg-3.9 result
Wed, 03 May 2017 13:23:36 +0200 merge with future 6.1.0 mercurial-3.9
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 13:23:36 +0200] rev 2319
merge with future 6.1.0 No extra adjustment needed from hg-4.0 result
Wed, 03 May 2017 13:18:08 +0200 merge with future 6.1.0 mercurial-4.0
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 13:18:08 +0200] rev 2318
merge with future 6.1.0 In addition to the output reverted for 4.1, we also drop the "troubles:" entry from the standard log.
Wed, 03 May 2017 13:12:39 +0200 merge with future 6.1.0 mercurial-4.1
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 13:12:39 +0200] rev 2317
merge with future 6.1.0 test pass fine except for the removal of the extra data when accessing hidden revision. The better message are 4.2+ only.
Wed, 03 May 2017 13:27:26 +0200 compat: drop the context manager used to write the cache file stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 13:27:26 +0200] rev 2316
compat: drop the context manager used to write the cache file Mercurial 3.8 does not supports context manager on atomic temporary file.
Wed, 03 May 2017 12:54:11 +0200 compat: make obscache code compatible with Mercurial version prior to 4.2 stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 12:54:11 +0200] rev 2315
compat: make obscache code compatible with Mercurial version prior to 4.2 the phasecache.getrevset method is new in 4.2.
Wed, 03 May 2017 12:41:54 +0200 evolve: record testing with 4.2 stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 12:41:54 +0200] rev 2314
evolve: record testing with 4.2 4.2 is now a things and tests pass fine.
Wed, 03 May 2017 12:31:40 +0200 merge with default for 6.1.0 stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 12:31:40 +0200] rev 2313
merge with default for 6.1.0
Wed, 03 May 2017 12:31:11 +0200 packaging first step toward 6.1.0
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 12:31:11 +0200] rev 2312
packaging first step toward 6.1.0
Wed, 03 May 2017 12:25:53 +0200 auto-push: move config help in the extension help
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 03 May 2017 12:25:53 +0200] rev 2311
auto-push: move config help in the extension help That is a better spot than the extension itself.
Mon, 01 May 2017 06:17:44 +0200 opening mercurial 4.1 compat branch mercurial-4.1
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 06:17:44 +0200] rev 2310
opening mercurial 4.1 compat branch This branch will receive test update implied by the 4.2 → 4.1 changes.
Tue, 02 May 2017 17:43:34 +0200 obscache: skip writing to disk if the data did not changed
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 17:43:34 +0200] rev 2309
obscache: skip writing to disk if the data did not changed This will avoid rewriting the cache for every single transaction.
Tue, 02 May 2017 16:19:05 +0200 obscache: skip writing if the cache is empty
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 16:19:05 +0200] rev 2308
obscache: skip writing if the cache is empty if the cache is empty, we can just skip writing to disk.
Tue, 02 May 2017 16:17:03 +0200 obscache: set a valid "empty" cache key if the cache is missing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 16:17:03 +0200] rev 2307
obscache: set a valid "empty" cache key if the cache is missing This avoid detecting bad cache when it just happens to be no cache.
Tue, 02 May 2017 16:10:14 +0200 obscache: have the obsstore fix empty file cachekey
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 16:10:14 +0200] rev 2306
obscache: have the obsstore fix empty file cachekey Before this change, the missing file and empty file returned different value.
Tue, 02 May 2017 17:44:12 +0200 obscache: log case where the cache is not up to date
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 17:44:12 +0200] rev 2305
obscache: log case where the cache is not up to date This will help track performance issue
Tue, 02 May 2017 16:13:04 +0200 obscache: still update and use the cache during transaction
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 16:13:04 +0200] rev 2304
obscache: still update and use the cache during transaction Other code might access the obsolete set in the middle of a transaction. It is better to use the case in that case since the update will eventually be written when the transaction is committed.
Tue, 02 May 2017 16:15:01 +0200 obscache: warm the cache in all cases
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 16:15:01 +0200] rev 2303
obscache: warm the cache in all cases There are case when the obsstore have been invalidated, but we still need to update the cache.
Tue, 02 May 2017 16:11:43 +0200 obscache: update the format to allow negative tiprev
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 16:11:43 +0200] rev 2302
obscache: update the format to allow negative tiprev If the changelog is empty (but the obsstore is not) the 'tiprev' will be -1.
Tue, 02 May 2017 16:09:03 +0200 obscache: load the disk data before checking is the cache is up to date
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 16:09:03 +0200] rev 2301
obscache: load the disk data before checking is the cache is up to date This is actually required since non-loaded cache will never be up to date...
Tue, 02 May 2017 02:13:33 +0200 obscache: skip the cache entirely if not up to date
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 02 May 2017 02:13:33 +0200] rev 2300
obscache: skip the cache entirely if not up to date The current update code has some race condition windows around updating. But we also ensure the cache are up to date with every transaction. So outdated cache mean another client have been mudding the repository but things will get back in place at the next transaction. So we just skip using the cache when not up to date. This is not the best we could do. But this is good enough for now.
Mon, 01 May 2017 15:49:36 +0200 readme: mention that some improvement are enabled for 4.2 only
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 15:49:36 +0200] rev 2299
readme: mention that some improvement are enabled for 4.2 only
Mon, 01 May 2017 08:12:26 +0200 perf: use the cache to compute the obsolete set.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 08:12:26 +0200] rev 2298
perf: use the cache to compute the obsolete set. The official "obsolete" computation is switch to using the cache. This provide noticable speed for operation that does not need to actually access the obs markers. The part relating to obsolete changeset computation disappear from the execution profile when it is used.
Mon, 01 May 2017 08:14:00 +0200 perf: warm the cache after all transactions
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 08:14:00 +0200] rev 2297
perf: warm the cache after all transactions This is the simplest way to ensure the data are up to date.
Mon, 01 May 2017 08:13:24 +0200 perf: adds a cache to know if obsmarkers might affect a revision
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 08:13:24 +0200] rev 2296
perf: adds a cache to know if obsmarkers might affect a revision Phase information still needs to be thrown in the mix to compute the final information, but skipping reading the obsstore for most operation is a large win. Usage of this cache arrives in the next changeset.
Mon, 01 May 2017 08:07:05 +0200 perf: adds cachekey utility to validate changelog+obsstore content
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 08:07:05 +0200] rev 2295
perf: adds cachekey utility to validate changelog+obsstore content We adds more helper about cache key to prepare the arrival of a cache that can be updated iteratively (similar to branchmap cache)
Mon, 01 May 2017 08:05:45 +0200 perf: adds some cache key helper on the obsstore class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 08:05:45 +0200] rev 2294
perf: adds some cache key helper on the obsstore class This will be useful to allow validating cache depending on obsstore without parsing the whole obsstore.
Mon, 01 May 2017 06:06:41 +0200 compat: only install the better filtered message for mercurial 4.2 and above
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 01 May 2017 06:06:41 +0200] rev 2293
compat: only install the better filtered message for mercurial 4.2 and above The helper function does not exist in earlier version.
Sat, 29 Apr 2017 05:35:01 +0200 evolve: update extension help
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 29 Apr 2017 05:35:01 +0200] rev 2292
evolve: update extension help I'm pretty sure there are some missing bits, but this cannot be worse than before.
Sat, 29 Apr 2017 05:44:07 +0200 merge with stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 29 Apr 2017 05:44:07 +0200] rev 2291
merge with stable
Fri, 28 Apr 2017 16:56:09 +0200 ui: change the hidden revision error message
Boris Feld <boris.feld@octobus.net> [Fri, 28 Apr 2017 16:56:09 +0200] rev 2290
ui: change the hidden revision error message It now display the same details than the warning when the working directory parent become obsolete like: $ hg update 0 abort: hidden revision '0' (successor: f301a99bd857)! $ hg up 1 abort: hidden revision '1' (pruned)! $ hg update 0 abort: hidden revision '0' (successors: 91311af6da10, 70653776ec4c)!
Fri, 28 Apr 2017 16:57:41 +0200 ui: add better messages when the working copy become obsolete.
Boris Feld <boris.feld@octobus.net> [Fri, 28 Apr 2017 16:57:41 +0200] rev 2289
ui: add better messages when the working copy become obsolete.
Fri, 28 Apr 2017 15:29:32 +0200 topic: directly use "super" call
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 28 Apr 2017 15:29:32 +0200] rev 2288
topic: directly use "super" call That is how one is supposed to do it.
Thu, 27 Apr 2017 20:52:09 +0200 repo: properly progate "destroyed" call to super class stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 27 Apr 2017 20:52:09 +0200] rev 2287
repo: properly progate "destroyed" call to super class The propagation of the 'destroyed' call was dropped. I'm not certain of the consequences of having a partially broken "destroyed" call, but this can't be good.
Tue, 25 Apr 2017 10:56:55 +0200 safeguard: add an option to disable automatic publishing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 25 Apr 2017 10:56:55 +0200] rev 2286
safeguard: add an option to disable automatic publishing Pushing to publishing server by mistake is a bit too common in the current state of evolve. Especially when the lack of good feature branch story make the use of -f a bit too common. So we add a very simple experimental option to allow warning (or abort) when changeset are pushed to a publishing server. This is unlikely to survive as is, but this is useful now.
Thu, 20 Apr 2017 13:05:45 +0200 merge back with stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 13:05:45 +0200] rev 2285
merge back with stable
Thu, 20 Apr 2017 13:04:31 +0200 Added tag 6.0.1 for changeset 5ef112a6eb87 stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 13:04:31 +0200] rev 2284
Added tag 6.0.1 for changeset 5ef112a6eb87
Thu, 20 Apr 2017 12:59:19 +0200 pkg: prepare release 6.0.1 stable 6.0.1
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 12:59:19 +0200] rev 2283
pkg: prepare release 6.0.1
Thu, 20 Apr 2017 12:58:27 +0200 debian: finalize 6.0.0 entry stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 12:58:27 +0200] rev 2282
debian: finalize 6.0.0 entry
Thu, 20 Apr 2017 12:54:57 +0200 readme: fix 6.0.0 release date stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 12:54:57 +0200] rev 2281
readme: fix 6.0.0 release date It was March, not February.
Thu, 20 Apr 2017 12:50:22 +0200 merge with future 6.0.1 mercurial-3.8
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 12:50:22 +0200] rev 2280
merge with future 6.0.1 Nothing special to report
Thu, 20 Apr 2017 12:48:31 +0200 merge with future 6.0.1 mercurial-3.9
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 12:48:31 +0200] rev 2279
merge with future 6.0.1 Nothing special to report
Thu, 20 Apr 2017 12:45:02 +0200 merge with future 6.0.1 mercurial-4.0
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Apr 2017 12:45:02 +0200] rev 2278
merge with future 6.0.1 Nothing special to report
(0) -1000 -300 -100 -60 +60 +100 +300 +1000 +3000 tip