Confused by remotes and autosync

(1) By Frank Leland (roadkill) on 2024-07-10 19:10:33 [link] [source]

Migrating to Fossil from Git.

In Git, I can control exactly which remotes are visible for each repo. I know which remote is affected by git push <remote> <branch> and when a change happens.

In Fossil, I can adjust the remote list, but because of autosync, any remote may also be synching with other remotes and changes are effectively propagated to them no matter what. That's not necessarily bad, but I want to verify my understanding.

My use case is when I work in a virtual machine with a host, but there is also a server on a separate machine with a master copy of the repo.

The VM has a local repo and a working copy. The remote of this is the VM host. (It appears that I have to have a local repo whenever I have a working copy, as I would have had with the .git directory.)
The VM host has a local repo and a working copy. The remote of this is the server with the master repo.
The VM repo is made by copying the VM host repo. When I open the VM repo, I get remotes to the VM host and the server. Did this happen because I copied the repo? This is worrisome because the VM is not on the same network as the server and may have troubles synching with it. Because of this, I'm tempted to delete that remote. Is this wise?
When I commit from the VM, the change propagates to the VM host, because it is a remote of the VM, via autosync I assume.
When I update on the VM host, the change appears in the working copy there, but is also propagated to the server, by autosync I assume because the server is a remote of the VM host.
If I go traveling with the VM host and the server is no longer visible, do I have to turn it off as a remote to avoid sync errors?

(2.1) By Warren Young (wyoung) on 2024-07-10 19:39:34 edited from 2.0 in reply to 1 [link] [source]

I think your main problems come down to a wish/worry/presumption that autosync is transitive; it is not. If B cloned from C and A clones from B, a commit on A will autosync to B, but it won't go to C until someone on B does something to trigger a separate autosync.

In a scenario like yours, I would point both the VM itself and the VM host at this "master" repo of yours, directly; then you don't need to worry about transitive syncs.

The only time I use multi-level cloning like this is when "C" can't get to "A" at all, and I'm forced to go through "B" as an intermediary. I do this as temporarily as I can manage; I work diligently to fix that problem as soon as I'm able.

Local DNS service is useful for this, as it lets you use URLs like ssh://fossil/museum/repo.fossil everywhere, with "fossil" being a CNAME for the master repo host. If you move the repos to a different master host, you change the CNAME to track the change, and all the clients follow along.

(3) By Frank Leland (roadkill) on 2024-07-10 20:44:44 in reply to 2.1 [link] [source]

Good to know how it behaves in a chain of repos. Thanks for that.

The star of connections you prefer is definitely easier to manage but cannot always be achieved. The most frequent scenario is when the server is unavailable for some reason, not on the physical network and not internet-connected.

That leads back to my second question of what happens when autosync is triggered but the remote target is unavailable. That's probably documented somewhere but I haven't seen it yet. Does the process hang? Does it complete with an error? Does it queue the changes to be synced later? I will test it but would like to know what to expect.

(4) By Warren Young (wyoung) on 2024-07-10 21:28:12 in reply to 3 [link] [source]

Does it queue the changes to be synced later?

Approximately.

When the pre-commit autosync fails outright or times out, it asks if you want to commit locally anyway. If you say "yes," your local repo clone is out of sync with the remote, and now you have a risk of an inadvertent fork.

That leads you directly into the more advanced topics lower down in this doc.

(5) By Thomas Hess (luziferius) on 2024-08-03 17:02:21 in reply to 3 [source]

General remote management

Check the output of fossil remote --help

You can list all registered remotes via fossil remote ls. Also, this excerpt from the --help output may be useful:

fossil remote off

Forget the default URL. This disables autosync.

This is a convenient way to enter "airplane mode".  To enter
airplane mode, first save the current default URL, then turn the
default off.  Perhaps like this:

    fossil remote add main default
    fossil remote off

To exit airplane mode and turn autosync back on again:

    fossil remote main

Going offline

That leads back to my second question of what happens when autosync is triggered but the remote target is unavailable.

If the remote is unavailable, the autosync will fail. Then, fossil will ask if you want to continue the check-in or abort. How long that takes depends on the host machine and the kind of network outage. If the connection attempt fails immediately, like with an immediate DNS resolution failure, that response will be immediate. If it does not fail, but rather hang until a socket timeout occurs, you'll have to wait while the process hangs for that timeout to occur, so likely 30s each time you want to check-in changes.

In that case, the most convenient solution is to use the "airplane mode", as outlined in the help quoted above. Just keep in mind that you have to give your default remote an explicitly name the first time you want to use that feature. Otherwise running fossil remote off will wipe the remote completely (as it simply deletes the "default" remote) and you'll have to re-add the remote URL manually later.

Sync behavior with multiple remotes

A sync, however triggered, uses the current default remote, which is the last used one. You can switch the default to any of the registered ones by explicitly syncing to them, via fossil sync REF, or switching there via fossil remote REF, and then running plain fossil sync.

So if your VM host has the remote server added as a named remote, for example "upstream", and you copy it to the VM, you can then add the VM host as another remote, maybe named "host".

Once setup, you can switch where to sync by default by simply doing an explicit sync once. If you want to do a star sync, you can use fossil sync --all, which will sync all remotes known to the repository, as the flag implies.