aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorW. Trevor King <wking@tremily.us>2012-08-29 23:57:05 -0400
committerW. Trevor King <wking@tremily.us>2012-08-29 23:57:05 -0400
commitfad4a92f93d3ad2d798521735c8f83827107d603 (patch)
treeb046a3e6b7e17084e2cd985d8aabf27c1625a29a
parent0336db8d4052a319f1d959a33fc847814551e3f8 (diff)
downloadbugseverywhere-fad4a92f93d3ad2d798521735c8f83827107d603.tar.gz
doc:tutorial: document `be serve-storage`.
-rw-r--r--doc/tutorial.txt20
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
--------------------------