Hi Jason,

Jason Conroy <jconroy@tscripta.net> writes:

> 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.

OK, sounds like brute-force approach.

> 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.

Nice!  It looks like the right kind of tool.

I wanted to give it a try so I ran “guix import go
code.forgejo.org/f3/gof3/v3”, tweaked the result (file attached), but
then I’m stuck with a build failure of
go-github-com-davidmz-go-pageant-1.0.2.  If Go-savvy people are reading
this, your guidance is welcome!

> 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.

I agree.  Thanks for sharing your views and your findings on
backup/mirroring!

Ludo’.