157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
# <a id="sql-solution"></a> Solution 2: SQL-Level Backup
The first method doesn’t get you a copy of the remote’s
[private branches][pbr], on purpose. It may also miss other info on the
remote, such as SQL-level customizations that the sync protocol can’t
see. (Some [ticket system customization][tkt] schemes rely on this ability, for example.) You can
solve such problems if you have access to the remote server, which
allows you to get a SQL-level backup. This requires Fossil 2.12 or
newer, which added [the `backup` command][bu] to take care of
locking and transaction isolation, allowing the user to safely back up an in-use
repository.
If you have SSH access to the remote server, something like this will work:
``` shell
#!/bin/bash
bf=repo-$(date +%Y-%m-%d).fossil
|
|
|
|
|
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
# <a id="sql-solution"></a> Solution 2: SQL-Level Backup
The first method doesn’t get you a copy of the remote’s
[private branches][pbr], on purpose. It may also miss other info on the
remote, such as SQL-level customizations that the sync protocol can’t
see. (Some [ticket system customization][tkt] schemes rely on this ability, for example.) You can
solve such problems if you have access to the remote server, which
allows you to get a SQL-level backup by delegating handling of locking
and transaction isolation to
[the `backup` command][bu], allowing the user to safely back up an in-use
repository.
If you have SSH access to the remote server, something like this will work:
``` shell
#!/bin/bash
bf=repo-$(date +%Y-%m-%d).fossil
|