troubleshooting a "dead" svnserve daemon

Q1) What line needs to be at the top of each dummy file, as with an RCS versioning line? How is it structured? Where is it documented?  There are no required lines for any file that is versioned within the Subversion repository. That said, you can choose to use "RCS-like keywords" wherever valid. Documentation is here: http://svnbook.red-bean.com/en/1.8/s....keywords.html  Q2) What are the commands that get used in the two methods listed above?  I'm going to assume you've setup Apache using "SVNParentPath" since it is FAR easier to create new repos with that setup than with "SVNPath".  If you give the Apache account a shell (normally a security issue - but in reality a practical requirement when hosting repos), then login as the Apache account to the server. You can then do:

 
1. "svnadmin create" to create the repo. 
2. "cd /tmp; svn checkout file:///path/to/repo" to get a working copy in /tmp 
3. "cd repo; ..." to setup the initial structure. 
4. "svn checkin" to get the initial structure up into the repository. 

After that you can just use Apache and/or svnserve  Q3) Does svnserve need to be running for those commands to work?  No, it does not need to be running. In fact, if it is running then anyone who has the ability to connect to that port will be able to do whatever the account that svnserve is running as can do - and every operation will be recorded as having been done by that account. If you don't care then, I guess, sure.  Instead, you would use a URL such as: svn+ssh://apache@192.168.56.200/reponame That URL assumes that the Apache account (in this case "apache" although on some systems it is "httpd") has an appropriate "authorized_keys" file that has entries of the form:  

command="/usr/bin/svnserve -t --tunnel-user=acct10001 -r /opt/repo",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding public-key-for-account-acct10001

   Note that the "-r /opt/repo" specifies the root of the search for repositories. That way the URL only needs the repo name. When SSH sees the request it will match the private key of the caller to the public key on that line (see the end of line). Then SSH will invoke that command - which identifies the specific account to which the operation should be registered (and authorized if you've turned on AuthZ).