Fossil SCM
Fixed a few errors in www/backup.md
Commit
bcff80c1d4cb9690ee3dfe07d04ec39f5d5cf371ef10122d234b2c53e121f899
Parent
4740cf7589b7a4b…
1 file changed
+2
-2
+2
-2
| --- www/backup.md | ||
| +++ www/backup.md | ||
| @@ -248,11 +248,11 @@ | ||
| 248 | 248 | care of. If all variables defined in earlier scripts are available, then |
| 249 | 249 | restoration is: |
| 250 | 250 | |
| 251 | 251 | ``` |
| 252 | 252 | openssl enc -d -aes-256-cbc -pbkdf2 -iter 52830 -pass pass:"$pass" -in "$gd" | |
| 253 | - xz -d | fossil --no-repository ~/museum/restored-repo.fossil | |
| 253 | + xz -d | fossil sql --no-repository ~/museum/restored-repo.fossil | |
| 254 | 254 | ``` |
| 255 | 255 | |
| 256 | 256 | We changed the `-e` to `-d` on the `openssl` command to get decryption, |
| 257 | 257 | and we changed the `-out` to `-in` so it reads from the encrypted backup |
| 258 | 258 | file and writes the result to stdout. |
| @@ -265,11 +265,11 @@ | ||
| 265 | 265 | restoration: |
| 266 | 266 | Fossil serves as a dogfooding project for SQLite, |
| 267 | 267 | often making use of the latest features, so it is quite likely that a given |
| 268 | 268 | random `sqlite3` binary in your `PATH` will be unable to understand the |
| 269 | 269 | file created by “`fossil sql .dump`”! The tricky bit is, you can’t just |
| 270 | -pipe the decrpted SQL dump into `fossil sql`, because on startup, Fossil | |
| 270 | +pipe the decrypted SQL dump into `fossil sql`, because on startup, Fossil | |
| 271 | 271 | normally goes looking for tables created by `fossil init`, and it won’t |
| 272 | 272 | find them in a newly-created repo DB. We get around this by passing |
| 273 | 273 | the `--no-repository` flag, which suppresses this behavior. Doing it |
| 274 | 274 | this way saves you from needing to go and build a matching version of |
| 275 | 275 | `sqlite3` just to restore the backup. |
| 276 | 276 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -248,11 +248,11 @@ | |
| 248 | care of. If all variables defined in earlier scripts are available, then |
| 249 | restoration is: |
| 250 | |
| 251 | ``` |
| 252 | openssl enc -d -aes-256-cbc -pbkdf2 -iter 52830 -pass pass:"$pass" -in "$gd" | |
| 253 | xz -d | fossil --no-repository ~/museum/restored-repo.fossil |
| 254 | ``` |
| 255 | |
| 256 | We changed the `-e` to `-d` on the `openssl` command to get decryption, |
| 257 | and we changed the `-out` to `-in` so it reads from the encrypted backup |
| 258 | file and writes the result to stdout. |
| @@ -265,11 +265,11 @@ | |
| 265 | restoration: |
| 266 | Fossil serves as a dogfooding project for SQLite, |
| 267 | often making use of the latest features, so it is quite likely that a given |
| 268 | random `sqlite3` binary in your `PATH` will be unable to understand the |
| 269 | file created by “`fossil sql .dump`”! The tricky bit is, you can’t just |
| 270 | pipe the decrpted SQL dump into `fossil sql`, because on startup, Fossil |
| 271 | normally goes looking for tables created by `fossil init`, and it won’t |
| 272 | find them in a newly-created repo DB. We get around this by passing |
| 273 | the `--no-repository` flag, which suppresses this behavior. Doing it |
| 274 | this way saves you from needing to go and build a matching version of |
| 275 | `sqlite3` just to restore the backup. |
| 276 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -248,11 +248,11 @@ | |
| 248 | care of. If all variables defined in earlier scripts are available, then |
| 249 | restoration is: |
| 250 | |
| 251 | ``` |
| 252 | openssl enc -d -aes-256-cbc -pbkdf2 -iter 52830 -pass pass:"$pass" -in "$gd" | |
| 253 | xz -d | fossil sql --no-repository ~/museum/restored-repo.fossil |
| 254 | ``` |
| 255 | |
| 256 | We changed the `-e` to `-d` on the `openssl` command to get decryption, |
| 257 | and we changed the `-out` to `-in` so it reads from the encrypted backup |
| 258 | file and writes the result to stdout. |
| @@ -265,11 +265,11 @@ | |
| 265 | restoration: |
| 266 | Fossil serves as a dogfooding project for SQLite, |
| 267 | often making use of the latest features, so it is quite likely that a given |
| 268 | random `sqlite3` binary in your `PATH` will be unable to understand the |
| 269 | file created by “`fossil sql .dump`”! The tricky bit is, you can’t just |
| 270 | pipe the decrypted SQL dump into `fossil sql`, because on startup, Fossil |
| 271 | normally goes looking for tables created by `fossil init`, and it won’t |
| 272 | find them in a newly-created repo DB. We get around this by passing |
| 273 | the `--no-repository` flag, which suppresses this behavior. Doing it |
| 274 | this way saves you from needing to go and build a matching version of |
| 275 | `sqlite3` just to restore the backup. |
| 276 |