diff options
author | W. Trevor King <wking@tremily.us> | 2012-08-29 23:57:05 -0400 |
---|---|---|
committer | W. Trevor King <wking@tremily.us> | 2012-08-29 23:57:05 -0400 |
commit | fad4a92f93d3ad2d798521735c8f83827107d603 (patch) | |
tree | b046a3e6b7e17084e2cd985d8aabf27c1625a29a | |
parent | 0336db8d4052a319f1d959a33fc847814551e3f8 (diff) | |
download | bugseverywhere-fad4a92f93d3ad2d798521735c8f83827107d603.tar.gz |
doc:tutorial: document `be serve-storage`.
-rw-r--r-- | doc/tutorial.txt | 20 |
1 files changed, 17 insertions, 3 deletions
diff --git a/doc/tutorial.txt b/doc/tutorial.txt index 7e801e7..4b3b84d 100644 --- a/doc/tutorial.txt +++ b/doc/tutorial.txt @@ -368,18 +368,32 @@ BE over HTTP Besides using BE to work directly with local VCS-based repositories, you can use:: - $ be serve + $ be serve-storage To serve a repository over HTTP. For example:: - $ be serve > server.log 2>&1 & + $ be serve-storage > server.log 2>&1 & $ be --repo http://localhost:8000 list Of course, be careful about serving over insecure networks, since malicous users could fill your disk with endless bugs, etc. You can -dissable write access by using the ``--read-only`` option, which would +disabled write access by using the ``--read-only`` option, which would make serving on a public network safer. +Serving the storage interface is flexible, but it can be inefficient. +For example, a call to ``be list`` against a remote backend requires +all bug information to be transfered over the wire. As a faster +alternative, you may want to serve your repository at the command +level:: + + $ be serve-commands > server.log 2>&1 & + $ be --server http://localhost:8000 list + +Take a look at the server logs to get a feel for the bandwidth you're +saving! Serving commands over insecure networks is at least as +dangerous as serving storage. Take appropriate precautions for your +network. + Driving the VCS through BE -------------------------- |