Re: [PATCH 8/9] refs: implement logic to migrate between ref storage formats

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 23, 2024 at 01:31:03PM -0400, Eric Sunshine wrote:
> On Thu, May 23, 2024 at 4:26 AM Patrick Steinhardt <ps@xxxxxx> wrote:
> > With the introduction of the new "reftable" backend, users may want to
> > migrate repositories between the backends without having to recreate the
> > whole repository. Add the logic to do so.
> >
> > The implementation is generic and works with arbitrary ref storage
> > formats because we only use.
> 
> ECANNOTPARSE: This sentence seems to be broken grammatically.

Will fix.

> > It does have a few limitations though:
> >
> >   - We do not migrate repositories with worktrees, because worktrees
> >     have separate ref storages. It makes the overall affair more complex
> >     if we have to migrate multiple storages at once.
> >
> >   - We do not migrate reflogs, because we have no interfaces to write
> >     many reflog entries.
> >
> >   - We do not lock the repository for concurrent access, and thus
> >     concurrent writes may make use end up with weird in-between states.
> >     There is no way to fully lock the "files" backend for writes due to
> >     its format, and thus we punt on this topic altogether and defer to
> >     the user to avoid those from happening.
> >
> > In other words, this version is a minimum viable product for migrating a
> > repository's ref storage format. It works alright for bare repos, which
> > typically have neither worktrees nor reflogs.
> 
> Worktrees hanging off a bare repository is an explicitly supported
> use-case, and there are people who use and promote such an
> organization, so I'm not sure if "typically" is accurate these days.
> Anyhow, just a minor observation, probably not worth rewording, and
> certainly not worth a reroll.

True enough. I would claim that most bare repositories out in the wild
do not have worktrees, mostly because they are used on the server side.
But in the end, quantity is rather irrelevant. I'll s/typically/often/
to relax the statement a bit. Does that work for you?

Patrick

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux