From fad4a92f93d3ad2d798521735c8f83827107d603 Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Wed, 29 Aug 2012 23:57:05 -0400 Subject: [PATCH] doc:tutorial: document `be serve-storage`. --- doc/tutorial.txt | 20 +++++++++++++++++--- 1 file 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 -------------------------- -- 2.26.2