aboutsummaryrefslogtreecommitdiffstats
path: root/doc/tutorial.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/tutorial.txt')
-rw-r--r--doc/tutorial.txt26
1 files changed, 3 insertions, 23 deletions
diff --git a/doc/tutorial.txt b/doc/tutorial.txt
index 443ac2a..3a1b8e8 100644
--- a/doc/tutorial.txt
+++ b/doc/tutorial.txt
@@ -372,33 +372,13 @@ BE over HTTP
------------
Besides using BE to work directly with local VCS-based repositories,
-you can use::
-
- $ be serve-storage
-
-To serve a repository over HTTP. For example::
-
- $ 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
-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::
+you can serve your repository over HTTP 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.
+Serving commands over insecure networks can be dangerous. Take
+appropriate precautions for your network.
Driving the VCS through BE
--------------------------