Fossil SCM

Change to www/caps/index.md

brickviking 2024-10-26 10:35 bv-corrections01
Commit 0af46e5dc8c2de171c89eeeacbbba29addba31915b3803a5a1a28280277adbcf
1 file changed +1 -1
--- www/caps/index.md
+++ www/caps/index.md
@@ -294,11 +294,11 @@
294294
Fossil requires write access to a repo DB while cloning from it, so you
295295
can’t clone from a read-only repo DB file over a local file path.
296296
297297
Even more surprising to you may be the fact that user caps do not affect
298298
cloning and syncing over SSH! (Not unless you go [out of your way][sshfc]
299
-patch around it, at any rate.) When you make a change to such a
299
+to patch around it, at any rate.) When you make a change to such a
300300
repository, the stock Fossil behavior is that the change first goes to the
301301
local repo clone where file system
302302
permissions are all that matter, but then upon sync, the situation is
303303
effectively the same as when the parent repo is on the local file
304304
system. The reason behind this is that if you can log into the remote
305305
--- www/caps/index.md
+++ www/caps/index.md
@@ -294,11 +294,11 @@
294 Fossil requires write access to a repo DB while cloning from it, so you
295 can’t clone from a read-only repo DB file over a local file path.
296
297 Even more surprising to you may be the fact that user caps do not affect
298 cloning and syncing over SSH! (Not unless you go [out of your way][sshfc]
299 patch around it, at any rate.) When you make a change to such a
300 repository, the stock Fossil behavior is that the change first goes to the
301 local repo clone where file system
302 permissions are all that matter, but then upon sync, the situation is
303 effectively the same as when the parent repo is on the local file
304 system. The reason behind this is that if you can log into the remote
305
--- www/caps/index.md
+++ www/caps/index.md
@@ -294,11 +294,11 @@
294 Fossil requires write access to a repo DB while cloning from it, so you
295 can’t clone from a read-only repo DB file over a local file path.
296
297 Even more surprising to you may be the fact that user caps do not affect
298 cloning and syncing over SSH! (Not unless you go [out of your way][sshfc]
299 to patch around it, at any rate.) When you make a change to such a
300 repository, the stock Fossil behavior is that the change first goes to the
301 local repo clone where file system
302 permissions are all that matter, but then upon sync, the situation is
303 effectively the same as when the parent repo is on the local file
304 system. The reason behind this is that if you can log into the remote
305

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button