Idea Transcript
Apache Subversion FAQ Translations: , These are the questions related to the currently supported versions. For older questions, see below.
Table of Contents General questions: What is Subversion? Why does it exist? Is Subversion proprietary software? How stable is Subversion? What is Subversion's client/server interoperability policy? What operating systems does Subversion run on? What's all this about a new filesystem? Is it like ext2? What kind of hardware do I need to run a Subversion server? I heard that Subversion is an Apache extension? What does it use for servers? Does this mean I have to set up Apache to use Subversion? I run Apache 1.x right now, and can't switch to Apache 2.0 just to serve Subversion repositories. Does that mean I can't run a Subversion server? Why don't you do X, just like SCM system Y? Why does the entire repository share the same revision number? I want each of my projects to have their own revision numbers. Does Subversion have changesets? When's the next release? Does Subversion support symlinks? I need a high resolution version of the Subversion logo, where can I get it? I have other questions. Where can I get more information? Why isn't my post showing up on the mailing list? How is Subversion affected by changes in Daylight Savings Time (DST)? How is Subversion affected by SHA-1 hash collisions?
How-to: How do I check out the Subversion code? How do I create a repository? How do I import ' CFLAGS := $(SVNDEF) ... continue with your other flags ...
(Note that this will not work on non-GNU versions of make. Don't use it if your build process needs to be portable.) Or try this recipe: ## ## on every build, record the working copy revision string ## svn_version.c: FORCE echo -n 'const char* svn_version(void) { const char* SVN_Version = "' \ > svn_version.c svnversion -n . >> svn_version.c echo '"; return SVN_Version; }' >> svn_version.c ## ## Then any executable that links in svn_version.o will be able ## to call the function svn_version() to get a string that ## describes exactly what revision was built. ##
Windows users may want to use SubWCRev.exe, available from the TortoiseSVN download page; it replaces all $WCREV$ tags in a given file with the current working copy revision. Another alternative is creating a wrapper for 'svn commit', which does some automatic replacement in files before commit (be careful not to mess things up though -- silent manipulation of files right before commit can be scary for a user). That way you can inject any meta ssh-dss AAAAB3Nblahblahblahblah Obviously, replace /opt/subversion/bin/svnserve with whatever is appropriate for your system. You also might want to specify the full path to the Subversion repository in the command (by using the -r option), to save your users some typing. The command= magic causes sshd on the remote machine to invoke svnserve, even if your user tries to run some other command. See the sshd(8) man page (section AUTHORIZED_KEYS FILE FORMAT) for details. Now when your users run the Subversion client, make sure they have an SVN_SSH environment variable that "points to" the private half of their keypair, by doing something like this (for the Bourne Again shell): SVN_SSH="ssh -i $HOME/.ssh/id_dsa.subversion" export SVN_SSH
This file discusses this topic in more detail.
I want to allow access via svn+ssh://, but am paranoid. I hate the idea of giving each user a login; I would then have to worry about what they are, and are not, allowed to access on my machine. See the section about hacking the ~/.ssh/authorized_keys file in the answer to this other question; ignore the stuff about getting svnserve on your PATH.
How can I set certain properties on everything in the repository? Also, how can I make sure that every new file coming into the repository has these properties? Subversion will not change a file's contents by default; you have to deliberately set the svn:eol-style or svn:keywords property on a file for that to happen. That makes Subversion a lot safer than CVS's default behavior, but with that safety comes some inconvenience. Answering the first question: to set properties on all files already in the repository, you'll need to do it the hard way. All you can do is run svn propset on every file (in a working copy), and then svn commit. Scripting can probably help you with this. But what about future files? Unfortunately, there's no server mechanism to automatically set properties on files being committed. This means that all of your users need to remember to set certain properties whenever they svn add a file. Fortunately, there's a client-side tool to help with this. Read about the auto-props feature in the book. You need to make sure all your users configure their clients' auto-props settings appropriately. You could write a pre-commit hook script to reject any commit which forgets to add properties to new files (see https://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/check-mime-type.pl for example). However, this approach may be overkill. If somebody forgets to set svn:eol-style, for example, it will be noticed the minute somebody else opens the file on a different OS. Once noticed, it's easy to fix: just set the property and commit. Note: many users have asked for a feature whereby the server automatically "broadcasts" run-time settings to clients, such as auto-props settings. There's already a feature request filed for this (issue 1974), though this feature is still being debated by developers, and isn't being worked on yet.
How do I deal with spaces in the editor path? Also, how can I define command line options for the editor? The Subversion command line client will invoke the editor defined in the environment variable SVN_EDITOR. This environment variable is passed directly to the operating system along with the name of a temporary file used to enter/edit the log message. Due to the fact that the SVN_EDITOR string is passed as-is to the system's command shell, spaces in the editor name, or in the path name to the editor, will not work unless the editor name is in quotes. For example, on Windows if your editor is in C:\Program Files\Posix Tools\bin\vi you would want to set the variable as follows: set SVN_EDITOR="C:\Program Files\Posix Tools\bin\vi"
Note that there is no need to escape the quotes in the Windows shell as they are not part of the syntax for the set command. On UNIX systems you would need to follow your shell's specific methods for setting the variable. For example, in a bash shell, the following should work: SVN_EDITOR='"/usr/local/more editors/bin/xemacs"' export SVN_EDITOR
In case a command line option would be needed for the invocation of the editor, just add that after the editor name in the SVN_EDITOR environment variable just like you would us on the command line. For example, if the options -nx -r would be wanted for the above editors, the following will provide those options: For Windows: set SVN_EDITOR="C:\Program Files\Posix Tools\bin\vi" -nx -r
For UNIX/bash: SVN_EDITOR='"/usr/local/more editors/bin/xemacs" -nx -r' export SVN_EDITOR
Note that SVN_EDITOR is the Subversion specific environment variable setting for the editor selection. Subversion also supports using the more generic EDITOR variable but if you need special behaviors with Subversion it is best to use the SVN_EDITOR variable.
I'm managing a website in my repository. How can I make the live site automatically update after every commit? This is done all the time, and is easily accomplished by adding a post-commit hook script to your repository. Read about hook scripts in Chapter 5 of the book. The basic idea is to make the "live site" just an ordinary working copy, and then have your post-commit hook script run 'svn update' on it. In practice, there are a couple of things to watch out for. The server program performing the commit (svnserve or apache) is the same program that will be running the post-commit hook script. That means that this program must have proper permissions to update the working copy. In other words, the working copy must be owned by the same user that svnserve or apache runs as -- or at least the working copy must have appropriate permissions set. If the server needs to update a working copy that it doesn't own (for example, user joe's ~/public_html/ area), one technique is create a +s binary program to run the update, since Unix won't allow scripts to run +s. Compile a tiny C program: #include #include #include int main(void) { execl("/usr/local/bin/svn", "svn", "update", "/home/joe/public_html/", (const char *) NULL); return(EXIT_FAILURE); }
... and then chmod +s the binary, and make sure it's owned by user 'joe'. Then in the post-commit hook, add a line to run the binary. If you have problems getting the hook to work, see "Why aren't my repository hooks working?". Also, you'll probably want to prevent apache from exporting the .svn/ directories in the live working copy. Add this to your httpd.conf: # Disallow browsing of Subversion working copy administrative dirs. Order deny,allow Deny from all
Finally, if the working copy to be updated isn't on the same machine as the Subversion server, svnpubsub can be used on the Subversion server to advertise the commit to a listening svnwcsub client on the Web server.
How do I check out a single file? Subversion does not support checkout of a single file, it only supports checkout of directory structures. However, you can use 'svn export' to export a single file. This will retrieve the file's contents, it just won't create a versioned working copy.
How do I detect adds, deletes, copies and renames in a working copy after they've already happened? You don't. It's a bad idea to try. The basic design of the working copy has two rules: (1) edit files as you please, and (2) use a Subversion client to make any tree-changes (add, delete, move, copy). If these rules are followed, the client can sucessfully manage the working copy. If renames or other rearrangements happen outside of Subversion, then the UI has been violated and the working copy might be broken. The client cannot guess what happened. People sometimes run into this problem because they want to make version control "transparent". They trick users into using a working copy, then have a script run later that tries to guess what happened and run appropriate client commands. Unfortunately, this technique only goes a short distance. 'svn status' will show missing items and unversioned items, which the script can then automatically 'svn rm' or 'svn add'. But if a move or copy has happened, you're out of luck. Even if the script has a foolproof way of detecting these things, 'svn mv' and 'svn cp' can't operate after the action has already occurred. In summary: a working copy is wholly under Subversion's control, and Subversion wasn't designed to be transparent. If you're looking for transparency, try setting up an apache server and using the "SVNAutoversioning" feature described in appendix C of the book. This will allow users to mount the repository as a network disk, and any changes made to the volume cause automatic commits on the server.
How do I run svnserve as a service on Windows? For versions 1.4.0 and later, you can find instructions here.
How do I convert my repository from using BDB to FSFS or from FSFS to BDB? There are three steps: 1. A dump/load from the old format to the new one. 2. Copy the hook scripts. 3. Copy the configuration files. Say you have a repository /svn/myrepos which is using the BDB backend and you would like to switch to using the FSFS backend: 1. Close down your server so that the read-only", like checkouts and updates. From an access-control standpoint, Apache treats them as such. But libsvn_fs (the repository filesystem API) still has to write temporary data in order to produce tree-deltas. So the process accessing the repository always requires both read and write access to the Berkeley DB files in order to function. In particular, the repository responds to many "read-only" operations by comparing two trees. One tree is the usually the HEAD revision, and the other is often a temporary transaction-tree -- thus the need for write access. This limitation only applies to the Berkeley DB backend; the FSFS backend does not exhibit this behaviour.