Skip to content

repoutil: Update full-repack timestamp when creating repositories

When deciding whether we need to repack a repository or not, we use the time of the last full repack as input: only when the last full repack is longer ago than a certain cooldown period will we do a new full repack. It thus acts as a cooldown period to space out full repacks given that they are generally expensive.

When a repository has never been repacked, the full-repack timestamp does not exist and is considered to be zero, which has the consequence that we will always perform a full repack in this case. This mechanism allows us to gracefully handle cases where repositories predate the logic that creates the timestamps.

But there is one exception: repositories which have just been created don't have such a timestamp, either, and will consequentially receive a full repack almost immediately. While not all that bad for empty repos, it can also cause excessive full repacks for repositories that have been created e.g. from a URL or an archive.

Generally speaking, any such repository should be in a well-packed state at the time of creation:

- The empty repository is well-packed by definition as it cannot be
  repacked more efficiently.

- A repository that is created from a source will have a single
  packfile only and thus be packed efficiently,

So by doing a full repack, we're mostly just wasting resources.

Improve the situation by creating the full-repack timestamp at creation time. As all our repository-creating RPCs go through repoutil.Create() there is only a single location which we need to update.

Changelog: changed

Merge request reports