Fri, 23 Feb 2024 14:07:33 +0100 perf: add a --as-push option to perf::unbundle
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 14:07:33 +0100] rev 51436
perf: add a --as-push option to perf::unbundle This turned out to make a quite significant difference.
Fri, 23 Feb 2024 06:25:09 +0100 chainsaw-update: exit early if one of the intermediate command fails
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 06:25:09 +0100] rev 51435
chainsaw-update: exit early if one of the intermediate command fails That will prevent the user to be presented with a start that pretend to be consistent with the request, but is not.
Fri, 23 Feb 2024 03:32:35 +0100 chainsaw-update: lock the repository for the duration of the operation
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 03:32:35 +0100] rev 51434
chainsaw-update: lock the repository for the duration of the operation This should prevent and catch some misusage where something else try to touch the repository.
Fri, 23 Feb 2024 11:41:55 +0100 chainsaw-update: taking care of initial cloning
Georges Racinet <georges.racinet@octobus.net> [Fri, 23 Feb 2024 11:41:55 +0100] rev 51433
chainsaw-update: taking care of initial cloning Perhaps we should go just a bit lower level than this `instance()`, since the main added value in our use-case is full path resolution, that we need to do anyway for the rmtree cleanup.
Fri, 23 Feb 2024 11:30:58 +0100 chainsaw-update: use a graph with branching in graph
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 11:30:58 +0100] rev 51432
chainsaw-update: use a graph with branching in graph This will be relevant for the next improvement of `chainsaw-update`.
Wed, 17 Jan 2024 14:39:06 +0100 chainsaw-update: log actual locks breaking
Georges Racinet <georges.racinet@octobus.net> [Wed, 17 Jan 2024 14:39:06 +0100] rev 51431
chainsaw-update: log actual locks breaking Previously, the command would simply state that it was about to break locks, not if there was actually some to break. This version is race-free. It would be also possible to display the content of the lock before hand (not race-free but informative in almost all cases).
Wed, 17 Jan 2024 14:26:58 +0100 vfs: have tryunlink tell what it did
Georges Racinet <georges.racinet@octobus.net> [Wed, 17 Jan 2024 14:26:58 +0100] rev 51430
vfs: have tryunlink tell what it did It is useful in certain circumstances to know whether vfs.tryunlink() actually removed something or not, be it for logging purposes.
Sat, 26 Nov 2022 12:23:56 +0100 chainsaw: new extension for dangerous operations
Georges Racinet <georges.racinet@octobus.net> [Sat, 26 Nov 2022 12:23:56 +0100] rev 51429
chainsaw: new extension for dangerous operations The first provided command is `chainsaw-update`, whose one and single job is to make sure that it will pull, update and purge the target repository, no matter what may be in the way (locks, notably), see docstring for rationale.
Fri, 23 Feb 2024 03:45:07 +0100 rust: disable the RustIndex without persistent nodemap
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 03:45:07 +0100] rev 51428
rust: disable the RustIndex without persistent nodemap See rational inline.
Fri, 23 Feb 2024 03:44:56 +0100 rust: stop claiming the C index is compatible with the rust code
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 03:44:56 +0100] rev 51427
rust: stop claiming the C index is compatible with the rust code This is no longer the case since the introduction of the pure Rust Index, and was probably not the case since the MixedIndex itself. So we fix the dedicated attribute value.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 tip