GNU bug report logs - #76503
[GCD] Migrating repositories, issues, and patches to Codeberg

Previous Next

Package: guix-patches;

Reported by: Ludovic Courtès <ludo <at> gnu.org>

Date: Sun, 23 Feb 2025 15:21:02 UTC

Severity: normal

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Full log


Message #455 received at 76503 <at> debbugs.gnu.org (full text, mbox):

From: Jason Conroy <jconroy <at> tscripta.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 76503 <at> debbugs.gnu.org, Guix Devel <guix-devel <at> gnu.org>,
 Simon Tournier <zimon.toutoune <at> gmail.com>
Subject: Re: bug#76503: [GCD] Migrating repositories, issues, and patches to
 Codeberg
Date: Fri, 18 Apr 2025 16:41:12 -0400
Ludovic Courtès <ludo <at> gnu.org> writes:

>>> We could also set up our own thing; I’ll inquire to see if 
>>> there are
>>> tools to do that for regular users.
>>
>> This is what I have in mind.  Please note I’m not considering 
>> this as
>> blocking or something we must have on Day-1.
>
> I did inquire on Mastodon: nobody came up with the ready-to-use 
> tool to
> do backup.  We could use the HTTP API, which exposes everything, 
> to
> approximate it, but it’d be an approximation.

I have no personal experience with forgejo but was inspired to 
research
this a little.

The gitea and forgejo client CLIs have an option called 
"dump-repo"[1]
which appears relevant. The call requires a hostname and user 
creds, so
I don't think it's specifically a server-side tool. Unfortunately, 
it
tends to hammer the backend service with lots of API 
calls[2]. Also,
judging from the code[3], it seems to have no concept of 
incremental
operation: if the export fails for any reason (such as backend 
timeout),
the client just deletes the partially-written archive.

More recently, Forgejo has been developing an on-disk format for 
data
dumps to/from various kinds of forges. It's called F3 ("Friendly 
Forge
Format") [4] and there exists a reference implementation[5] that 
can
write the archives and talk to forgejo backends. Its project page 
states
that the tool is designed for "mirroring", which suggests that 
efficient
incremental syncs might be possible.

Maybe there's a good reason why the Codeberg experts you consulted 
on
Mastodon didn't mention these tools, but I thought I would share 
my
findings anyway.

Cheers!

Jason

P.S. Although my opinion as a lurker won't count for much, :) I 
support
this GCD. Up-thread, some discussions on ease-of-use ("it takes N 
steps
to do it this way, vs. N+2 steps that way") make the tacit 
assumption
that the user handles every step correctly. But in the real world 
where
users make mistakes, I see value in a webservice-based workflow 
that
provides instantaneous and very visible feedback to users, as 
compared
to an asynchronous workflow that's driven by emails and several
loosely-coupled services.


[1] https://forgejo.org/docs/latest/admin/command-line/#dump-repo

[2] https://codeberg.org/Codeberg/Community/issues/896

[3] 
https://codeberg.org/forgejo/forgejo/src/commit/f3882d45533bbfce234b3f127a33c19b8a7165ca/cmd/dump_repo.go#L165

[4] https://code.forgejo.org/f3

[5] https://code.forgejo.org/f3/gof3




This bug report was last modified 17 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.