Difference between revisions of "Subversion"

From DreamHost
Jump to: navigation, search
(Versions of Subversion on DreamHost)
m (Versions of Subversion on DreamHost)
Line 50: Line 50:
# Most (over 80%) current customers, including all customers who signed up after mid-2008, should be on newer machines (in the "homie" cluster), which should have Subversion 1.5.
# Most (over 80%) current customers, including all customers who signed up after mid-2008, should be on newer machines (in the "homie" cluster), which should have Subversion 1.5.
# As of 2010.04, Subversion 1.6 is available from [http://subversion.apache.org/ Subversion's web site], but is not yet available on Dreamhost servers because (at least then) DreamHost runs [[Debian]] Etch and [http://packages.debian.org/search?suite=all&section=all&arch=any&searchon=sourcenames&keywords=subversion latest Subversion is not yet pre-packaged for Debian Etch].
# As of 2010.04, Subversion 1.6 is available from [http://subversion.apache.org/ Subversion's web site], but is not yet available on Dreamhost servers because (at least then) DreamHost runs [[Debian]] Etch and [http://packages.debian.org/search?suite=all&section=all&arch=any&searchon=sourcenames&keywords=subversion latest Subversion is not yet pre-packaged for Debian Etch].
# As of 2012.02, at least server Kings has version 1.6.12
[[#Upgrading_to_Newest_Subversion|Installing a newer version Subversion manually]] will make the command-line tools available to your user, but will not cause your repository to be served as SVN 1.6 (so not accessible via http(s)? Why? Also citation needed); as such '''your installing a newer version of Subversion is not recommended''' by DreamHost.
[[#Upgrading_to_Newest_Subversion|Installing a newer version Subversion manually]] will make the command-line tools available to your user, but will not cause your repository to be served as SVN 1.6 (so not accessible via http(s)? Why? Also citation needed); as such '''your installing a newer version of Subversion is not recommended''' by DreamHost.

Revision as of 04:49, 22 February 2012

This article or section may require a cleanup.
We are hoping to create articles that meet certain standards. Please discuss this issue on the talk page. Editing help is available.

Subversion (official site) is a version-control system that keeps track of changes in your files on a server. Subversion helps to coordinate work among multiple people. For an introduction - read the book - it is really great.

Subversion on DreamHost

For Subversion hosting, DreamHost is notable in that DreamHost is the only web host providing private storage (for Subversion & more) with a huge & potentially-unlimited total storage size for a flat-else-very-low fee --or else the first web host to do so (at least since 2006), seemingly years ahead of anyone else. However, a serious drawback: a new bug, apparently from DreamHost, limits seemingly every new file to be under ~0.5GB.

Since about 2009 July, I User:CaydenMC have used DreamHost Subversion on a near-daily basis for text editing (writing, coding, spreadsheets) as my primary working-file storage; now today 2011.08.31 with 5 SVN repos so far totaling 5.7GiB, and here are the pros-thru-cons I find:

  1. Notable Pro: storage space is "unlimited" per http://dreamhost.com/unlimited-policy (see that for the current details); in general, the total storage space is unlimited else notably inexpensive, which seems to be a one-of-kind for private Subversion storage, making DreamHost the most inexpensive-by-far private Subversion storage (in terms of $/GB) of anywhere I've seen
  2. Notable Pro: servers are almost always online (never a problem in my experience); "consistently fast" reports another user*
  3. Pro: servers have always been reasonably fast
  4. Pro: unlimited repositories & users
  5. Mixed: Very easy to start, but the best direction? It's very easy to get started with the #Built-in/Control-Panel Subversion on DreamHost but this Subversion has a number of drawbacks seriously limiting its use & scalability for me & seemingly many, so one would have to #Upgrading to Newest Subversion which I read here is possible but I haven't really tried because of its apparent complexity & other drawback on DreamHost (possibly "not accessible via http(s)"), plus also then converting ones repos to the new format.
  6. Con, Possibly Serious: The version of Subversion running by default is always out-of-date and getting a-more or the current version is difficult or impractical.
  7. Serious Con: the size of each new file (& seemingly commit) is now limited to ~0.5GB due to some new bug apparently with DreamHost, at least with the built-in Subversion and possibly custom, too, so unless one is prepared to split & reassemble every type of large file into < .5GB chucks (typically impractical), due to this new bug it now seems typically impossible to store in DreamHost's Subversion any file over ~.5GB including all the common & important ones as videos, disk images (as CDs & DVDs & virtual machines & more), Outlook data files (.ost & .pst), and more. This is a serious drawback to DreamHost Subversion (which, before this, could handle files over 0.5GB, at least .ost), as one can often want & need to have at least some if not all Subversion benefits (as efficient & automatic versioning, and real protection protect-from-erasure, & store-and-transmit-just-the-differences) for the larger files just as one would for other files (such as when editing a video, or a virtual machine, or an .ost/.pst with all ones personal data, so wanting to keep prior versions), indeed for larger files, efficient -versioning & store-and-transmit-just-the-differences is notably more critical

For more on what DreamHost Subversion users are into & wanting, see DreamHost's Customer Suggestions for Subversion and for SVN.

Built-in/Control-Panel Subversion on DreamHost

Most obviously & easily, a version of Subversion can be immediately setup & configured via the DreamHost's Subversion Control Panel. And as of 2010.04.09 thru today 2011.08.31, here are the pros-thru-cons of using this built-in Subversion, found at least by I User:CaydenMC:

  1. Notable Pro: makes it very easy to get started with & learn Subversion from the server side (installing & configuring basic repositories & users) plus test DreamHost's Subversion server speed
  2. Notable Pro: easily create/delete any number of users (all with write access) and set/change the password of each
  3. Notable Pro: easily specify if the repository is public and to require/offer http and/or https access
  4. Notable Pro: easily specify if the repository available via WebDAV thanks to SVN's Autoversioning which then allows you to conveniently access SVN via WebDAV clients.
  5. Cons: the built-in/panel Subversion has serious scalability limitations which will force me & many others to eventually move off of it:
  6. Small Con: does not allow a user to delegate who can create accounts and grant/revoke access (say when a user wants to store a file there then grant access to additional people).
  7. Con: does not allow a user to create & update his/her own Subversion account --as implied by one customer's suggestion for this
  8. Con, Possibly Serious: breaks passwords containing spaces; it's possible to enter passwords that contain spaces, but each time the page is loaded, all passwords will be truncated before the first space. If you use passwords containing spaces, you must remember to re-type each password whenever making changes to the SVN settings.
  9. Con, Possibly Serious: The only version of Subversion which the panel uses is the pre-installed & maintained version of Subversion, which, as #Versions of Subversion on DreamHost details & "explains", is always out-of-date.
  10. Serious Con: uses Basic Authentication that stores and transmits user passwords in plain-text, making it very insecure unless SSH tunneling or SSL/TLS encryption is used.
  11. Serious Con: does not allow one to specify who can get access to what. Instead, every listed-user has read & write access to everything, and the public/anonymous-users have either has no access at all or read access to everything. Consequently, the only workaround is to have multiple repositories (one for each kind of access-list desired) so then to give most every user multiple accounts, and in all that confusion hope something doesn't get misfiled as it would be very difficult to move its history.
  12. Serious Con: there is no supplied server-side indexer to index & fast-search the server's repository (such as http://Atlassian.com/software/fisheye ); consequently, to content-search a repository (and often even to full-search the file & folder names), each user (potentially on each computer) has to download potentially the whole repository (and potentially ever version) and search it using say his/her local desktop search --and as the repository grows, naturally this becomes impractical.

Consequently in DreamHost's Customer Suggestions there are several customers asking fixes for these limitations:

  • Some customers ask fixes to just the limitations they've encountered thus-far: Goodies - Subversion suggestions
  • Alternatively a number of customers (including me User:CaydenMC) ask DreamHost simply provide a standard SVN front-end which solves all these limitations and more, as:
  1. one suggesting the open-source http://USvn.Tigris.Org
  2. one suggesting http://Atlassian.com/software/crowd
  3. one suggesting open-source http://Insurrection.Tigris.Org
  4. among even more web admin GUIs for Subversion available.

Versions of Subversion on DreamHost

To find out which version of Subversion you have on your server, login to it with PuTTY or other SSH client and enter the command:

svn --version 

In one's DreamHost account, the version of Subversion pre-installed & maintained is the version which is pre-packaged for the version the OS (which is always Debian) --the standard on DreamHost for many third-party apps. This guarantees the combination (OS & all its apps) will work at the cost of apps being typically about 1 to 3 years out-of-date. And, as that link explains, the OS generally isn't upgraded (so neither are Subversion & these other; rather a newer OS version may be running on another DreamHost machine, in which case one can request one's account be moved to such a machine with a newer OS. That link will also tell you how to tell what version of the OS your account has and what is current and how the upgrade process works if you need one. On DreamHost,

  1. For the reason explained above, the pre-installed version of Subversion will always be out-of-date (it was on 2010.04.09 and for at least a year or more before that, seemingly has been out-of-date for most of the last 4 years before that (since 2006) and maybe longer).
  2. A few older customers may be on machines with Subversion 1.4.
  3. Most (over 80%) current customers, including all customers who signed up after mid-2008, should be on newer machines (in the "homie" cluster), which should have Subversion 1.5.
  4. As of 2010.04, Subversion 1.6 is available from Subversion's web site, but is not yet available on Dreamhost servers because (at least then) DreamHost runs Debian Etch and latest Subversion is not yet pre-packaged for Debian Etch.
  5. As of 2012.02, at least server Kings has version 1.6.12

Installing a newer version Subversion manually will make the command-line tools available to your user, but will not cause your repository to be served as SVN 1.6 (so not accessible via http(s)? Why? Also citation needed); as such your installing a newer version of Subversion is not recommended by DreamHost.

Quick Start

To set up a Subversion repository at svn.yoursite.com for a project called "myproject", follow these steps:

  1. Create svn.yoursite.com:
    1. Go to your DreamHost control panel and click Domains, then Manage Domains
    2. Click Add New Domain / Sub-Domain
    3. Enter "svn.yoursite.com" in the Domain To Host field, enter "svn.yoursite.com" in the Web Directory field, and select Remove www.
    4. Click Fully Host This Domain Now!
  2. Wait a few hours until the new DNS information propagates (that is, when visiting svn.yoursite.com in a web browser doesn't give an error--the page will look like an empty directory listing once the DNS info has propagated).
  3. Set up a Subversion repository:
    1. Click Goodies, then Subversion
    2. Enter "My Project" in the Project Name field, "myproject" in the Project ID field, and make sure that svn.yoursite.com is selected for the URL. Use "myproject" as the directory name.
    3. Replace the dummy usernames and passwords with a username and password for yourself.
    4. Click Create My New Project Repository Now!

As soon as the DreamHost Subversive Robot actually creates your repository, you can begin using it. For instance, to import a directory:

svn import some_directory http://svn.yoursite.com/myproject -m "Initial import"

You can create additional users for your Subversion project at any time by going to Goodies, Subversion and editing the project. Using this method, users cannot change their own passwords.


Warning: If you are getting 301 errors saying "repository has been moved permanently to [some other url]", then check these things:

  • Make sure that you haven't created your repository called "svn" or inside of a directory called "svn".
  • Make sure you don't have .htaccess rules above the subversion directory that are causing any kind of re-write (like WordPress)
    • This includes having Dreamhost automatically add 'www.' to your URL. In Domains -> Manage Domains, clicking on edit hosting, you have a choice with regards to "www". Selecting the 'Add WWW' option will result in a 301.

Troubleshooting: If you are getting weird errors and import or checkin is working for some but not all files, double check and try disabling your anti-virus software. See this post for more info http://old.nabble.com/Propfind-200-ok-error-td20063285.html

Warning: Repositories don't act like normal directories: You will not be able to use .htaccess files, cgi scripts, etc. in your repository directory. For instance, if you setup your repository at http://svn.example.com/, you will not be able to password protect that directory using .htaccess. You must use the Public/Private field in the Subversion panel page. Changes made in the Htaccess/WebDAV panel also do not apply to your SVN repository.

This also means you can't install ViewVC in the main repository directory. To work around this, put your repository in http://svn.example.com/svn/ and the ViewVC cgi in http://svn.example.com/. Remember, you'll need to use a .htaccess file to configure http://svn.example.com/, but the Public/Private field in the Subversion panel to protect http://svn.example.com/svn/.

Hastily-made repositories often don't work: If you create your repository before its intended host is fully created (and resolved), you may have an inaccessible repository. Assuming it doesn't yet contain any information (how could it?), just delete it and recreate it. (Alternatively, you may be experiencing a DNS propagation delay if you can access your repository via http within the DreamHost system, but see an empty directory from outside DreamHost [Apache 1.3x serving your empty domain]. If you can't wait, try querying the DH DNS servers for your IP and using a local hosts file or NetInfo to temporarily resolve your svn host. Remember to undo this when DNS records have propagated.)

Hosting more than one Subversion domain: You can host multiple svn domains and subdomains under one Dreamhost account, but they are not completely independent. In particular, all repositories created with the same FTP account share the same namespace, even if under different URLs. With a single FTP account, a given repository name can only be used once for all svn domains. If you create http://svn1.example.com/repo, you cannot have a second repository named http://svn2.example.com/repo. If you do configure http://svn2.example.com/repo, it will be a second name for the same repository, with a separate set of permissions. If you must create two repositories with the same name, create a second FTP user.

Hosting subversion for a domain that is not on Dreamhost: If you have a domain which is not hosted on Dreamhost and you want to set up Subversion on a subdomain of that domain, it will not work with a normal setup. Instead, you must set up a subdomain to a domain hosted on Dreamhost (e.g., realsvn.exampleOnDreamhost.com), then create a Dreamhost mirror to that domain from the domain you want (e.g., svn.exampleNOTonDreamhost.com). Make sure you wait for DNS propagation to occur before testing everything.

File Ownership Problems: On Dreamhost subversion runs as the dhapache user. If you create a file, it is owned by yourusername, not dhapache and subversion can't read it. It is pretty easy to have this happen. (For example, the backup feature of the popular emacs text editor will do it: to prevent this add (setq backup-by-copying t) to your .emacs file.) Once dhapache has lost ownership of the file, your repository becomes unmodifiable and your users will get "permission denied" errors when they try to commit.

If your repository becomes corrupted through bad ownership, try the following:

  1. Open DreamHost Subversion Control Panel
  2. Under "Actions" click "Edit" for the appropriate repository
  3. Add a new user and password (any will do...just make the pw non-guessable)
  4. Click "Update my repository now!"

In the process of adding a new user, the DreamHost job will recursively change file ownership for the whole repository back to dhapache.

Some have reported success just submitting an edit (with no changes) to their repository in the Control Panel. This operation recreates your reponame.access and reponame.passwd files re-establishing dhapache as their group (and undoing any MD5 passwords you've made manually). Unfortunately, this does nothing to fix your repository if the owner has been changed from dhapache to your username.

If neither of these work, you may have invoke the nuclear option: dump, recreate and reload your repository.

It would be nice if the Subversion Control Panel had an explicit option to fix file owners and groups directly with e.g. a script like this:

sudo chown -R dhapache ~/svn/reponame; 
sudo chgrp dhapache ~/svn/reponame.access ~/svn/reponame.passwd;

Another nice feature would be a Control Panel switch to allow passwords to be created and maintained with MD5 encryption.

Some clients require MD5 passwords: If you get "access denied" warnings, you may need to use MD5 passwords instead of the standard variety created by the DreamHost Control Panel. Use htpasswd -nm username to generate the entry (ala username:passwd-hash) for your reponame.passwd file. And use an editor (ala nano reponame.passwd) to replace your standard password entry.

Don't overwrite your reponame.access and reponame.passwd files with echo "username:passwd-hash" > reponame.passwd Overwriting the files will cause them to have your user's group instead of dhapache, leaving your repository in a read-only or inaccessible state.

Removing repositories through the control panel doesn't seem to remove the ~/svn/<repo-id> directory. (as of Apr 12 2006) Workaround:

cd ~/svn;
mkdir old;
mv <repo-id> old 

You have the proper permissions to do this. (You can also use WebFTP to delete or rename the repository directory.)

Warning: It has been reported that DreamHost's "Extra Web Security" (Mod_security) can interfere with proper operation of Subversion on DreamHost servers. If you find that you are having trouble with checkouts, and a check of your error.log shows a "ModSecurity:" error, you can resolve this issue by disabling mod_security for your domain ("Edit" the "Web Hosting" setup in the "Domains -> Manage Domains" section of the panel and uncheck the "Extra Web Security" checkbox).

Connecting to Subversion Repository

Using svn+ssh

Allows for a svn client to connect directly with the repository via ssh.

You have to set up a ssh username and password. Subversion users defined in the panel will not be used for authentication.


note: {project} is the ID of your subversion project, NOT the projectname.

You should also check SSH#Passwordless_Login to use this mode without being asked for the password repeated times

See also SVN book for SSH tricks

Using HTTP

  1. Use the HTTP path that you used in the Subversion panel.
  2. Sign in using username and password specified in the panel.
Is there any way for svn users to change their password in this mode? No. Only through panel.
Is there any way to use https instead of http? Yes, but first you will need a unique IP address and Secure Server installed on your domain.

Using the Command Line (CLI)

  • Locally (assuming your project is hosted on Dreamhost and can be accessed from your shell).
svn list file:///home/{user}/svn/{project}
  • HTTP.
svn list {projectURL}
  • SSH Tunnel.
svn list svn+ssh://{user}@www.yourdomain.ext/home/{user}/svn/{project}

note: {project} is the ID of your subversion project, NOT the projectname, which can be found on the Subversion panel.
note: {projectURL} is the Project URL chosen by you on the Subversion panel.

How to use: quick reference

The instructions provided in this article or section require shell access unless otherwise stated.

You can use the PuTTY client on Windows, or SSH on UNIX and UNIX-like systems such as Linux or Mac OS X.
Your account must be configured for shell access in the Control Panel.
More information may be available on the article's talk page.

Creating Repository via Command-Line

If you didn't use the Dreamhost Subversion Panel, you can create the repository at a directory. If you used the Quick Start method then skip this step and go to the next one.

svnadmin create /home/user/path/to/repository


Handmade repos are read-only (via http): If you find that you have to tweak and reload your dumpfile a few times, it can be handy to use the CLI tools (e.g. rm -rf and svnadmin create) to wipe and recreate your repository until you get it right. But then you'll want to use the Control Panel to delete and recreate your repository. Your test repositories will not function properly in production (they won't permit any changes).

The Panel creates the repository with dhapache as the owner, and the reponame.access and reponame.passwd files with dhapache as the group. Trying to create your own production repo with svnadmin create is futile because you don't have authorization to change those ownerships and group memberships (and you're not a sudoer).

Don't overwrite dhapache files: Don't overwrite your reponame.access and reponame.passwd files with echo "username:passwd-hash" > reponame.passwd (e.g. if you're trying to use MD5 passwords). Use an editor and paste in the new data. Overwriting the files will cause them to have your user's group instead of dhapache. If your repository is relatively mature when you make this mistake, and you have no backup, you will be out of options.

Importing Folders and Files

Once the repository is created you can add folders and files that you have in another location. It is better to use this method to keep the revisions number down when first creating the repository.

svn import /home/USER/path/to/source file:///home/USER/path/to/repository --message="Importing Project"

You have to put a message in and change the text inside to whatever you are doing at the time.

Loading a dumpfile

Sometimes, you would have an existing repository that you want to migrate to your Dreamhost svn repository. You will need to take a dump of your existing repository and load it into your Dreamhost repository.

  • Dump your existing repository
 svnadmin dump path-to-repo | gzip > dumpfile.gz
  • Upload dumpfile.gz to your home directory.
  • Load this into your repository.
If you set up using the Dreamhost Subversion Panel, then the repository will be under the $HOME/svn/{repo-id} where the repo-id is the id you used to setup the repository in the panel. Decompress the dumpfile first.
gunzip -c home_dir/dumpfile.gz | svnadmin load svn/repository_id

Command should show all files being imported, if not then check the instructions and try again.

Using TortoiseSVN

TortoiseSVN is a Windows GUI integration program for svn. Use at your own risk, it is not officially supported.

Using HTTP

  1. Download the TortoiseSVN client from the official site
  2. Run the installer
  3. Create a folder somewhere and leave it empty. Any name and location on your own computer will do. A folder under My documents or on your desktop might be convenient.
  4. Open the context menu of the folder (by right clicking on it for example) and you will notice a few new items somewhere halfway the menu, in particular SVN Checkout... and TortoiseSVN which is a submenu.
  5. Choose SVN Checkout.... A new window called Checkout wil open.
  6. In the Repository section, fill out the URL of your repository. Don't forget to start with http://. For example : http://svn.mysite.com/myrepository/.
  7. You can immediately type the full path in your svn that you would like to check out or you can now click the button with the ... besides the URL field. This will let you browse the contents of your repository and choose a specific folder. It might take a minute to load.
    1. If you get a 405 error that says something about not having permission, you may have mistyped the URL for your repository and ended up on your regular webserver instead of inside the repository. If you have this problem repeatedly, use a command shell to do the checkout.
    2. Note that your repository is completely empty if you just created it. The repository browser allows you to create folders and move them around, but that's about it.
  8. The Checkout directory should already be filled in, there are two checkboxes (Only check out the top folder and Omit externals) which you should leave unchecked. If you just plan to have a simple repository you probably won't be needing them at all. Otherwise read about them in the TortoiseSVN help (folder context menu > TortoiseSVN submenu > Help).
    1. You may rename the local directory if you wish, but do not give it a name ending in .com (as suggested below for the server), as this can cause problems with some Windows security programs that flag the directory as an executable file.
  9. Leave Revision at HEAD revision for now. Go ahead and confirm this dialog with the OK button. You should now see a log screen and after a few seconds it should say complete at revision 0.
  10. At this point you can start working in the folder, if you already have a project you were working on just move it all into this folder.
  11. Now pull up the folder context menu and choose SVN Commit...
  12. This brings up a window where you can choose which files should be included in the SVN. If you're working with software and compiling things a lot of temporary files and binaries get generated that are absolutely not necessary since they can be easily regenerated from the source code. You should uncheck these to avoid needless traffic and storage usage.

Congratulations, at this point, you're in business! You can now make changes and commit them, revert if you want to undo (TortoiseSVN submenu) everything after the last commit and much more. The TortoiseSVN help is always available for more details.

Note that this method sends everything over the internet in cleartext, which may or may not be much of a problem to you.

Using an SSH tunnel

This walkthrough assumes username is myname, with a website at www.mysite.com, and that the repositories are in ~/svn starting with a project named myproject. You can choose your own directory names.

Step 1: Create the repository following the Repository section of this guide. Step 2: Download and install SVN client

Create Session Key

If you don't create the public session key, you will have to type your password in for every action in the browser and for every time TortoiseSVN connects to the server.

Start in your home directory

cd ~

Generate the key set using the passphrase of your choice and put the public key in a .ssh directory (note: the name "rsakey" isn't required)

Write down your passphrase as you will need it later.

ssh-keygen  -b 1024 -t rsa -N SomeLongTextForPassphrase -f rsakey

Create the .ssh folder

mkdir .ssh

Move the public key inside of the folder and rename it.

mv rsakey.pub .ssh/authorized_keys

Change permissions on both the folder and file for security.

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Download and install the Putty tools (scroll down to the Windows-style installer). This is an SSH client with authentication tools.

Download your "rsakey" file (your private key) from the server to your local machine (the rsakey should be in your home directory).

Use your Windows FTP client.

Load it into the PuTTYgen tool (puttygen.exe) and enter your passphrase when it asks for it.

Use SSH-2 (RSA) which will be the default.

Save it as a private key from PuTTYgen in a safe place as rsakey.ppk.

Setup New Session
  1. Run PuTTY Pageant. Pageant will put an icon of a computer wearing a hat into the System tray.
  2. Load a private key into it. Double click on the icon and then click on Private Key File.
  3. Type in the Passphrase.

  • Run Putty and make a new session:
    • Hostname: www.mysite.com
    • Protocol: SSH
    • Saved Sessions: mysiteSSH
    • Connection->Data->auto-login username: myuser
    • Connection->SSH->preferred protocol: 2
    • Connection->SSH->Auth->private key file: path\to\rsakey.ppk
  • Click "Save" on the sessions panel to save this config.
  • Open PuTTY if you want to test your session. PuTTY will notice that Pageant is running, retrieve the key automatically from Pageant, and use it to authenticate. You can now open as many PuTTY sessions as you like without having to type your passphrase again. You may get a message saying, "The server's host key is not set in the registry." (Insert what this means here.)

  • Now find your local project directory, and copy what you want to add to Subversion into a temporary directory (let's call it "ImportMe"), organizing it carefully -- it's smart to put your files in a "trunk" directory so that working with new branches and tags later is simple.
  • Right-click on the ImportMe folder and select "Import..." from the TortoiseSVN submenu. You will be adding everything inside this folder into the root of the "myproject" repository.
  • In the import dialog, enter the URL of Repository like this. Replace "mysiteSSH" with the name of your PuTTY stored session and "myusername" with your real username. If you just want a straight SSH tunnel, we'd use myuser@www.mysite.com here instead of mysiteSSH:

...and click "Okay". This will load your project files into the repository.

  • Next, check out the files you want to work with into your project directory (but make sure you aren't overwriting files when you check out or you'll get errors). This is the "SVN Checkout..." option in the folder context menu.

Everything should be pretty self-explanatory from there on.

Other References

For Windows XP

Guide from TortoiseSVN site (generate RSA key instead of DSA key).

  • TortoiseSVN (1.1.3) - Go into Settings and enter TortoisePlink as the SSH client under the Network tab to connect to your repository. You can use svn+ssh://myusername@mysiteSSH/home/myusername/svn/myproject to specify your username directly in the URL. Along with Pageant for key-based authentication, using TortoiseSVN is very transparent and easy to use.

Also screen is getting over worked for overnight checkouts (yes overnight)

svn co &> ~/log_co &

Multiple User Access to Repository

(I have only tried this in a bundy shell, not externally (with TortoiseSVN, for example)

  • Create at least two users (mysvnadmin, mysvnuser)
  • Create the repository and import the project with mysvnuser.
  • Login (ssh) to mysvnuser's account:
$ su mysvnuser
$ svn co file:///home/mysvnadmin/repos/project work
$ svn add file
$ svn commit -m "added file"
$ svn log
 r1 | mysvnadmin | 2005-09-04 08:03:47 -0700 (04 Sep 2005) | 1 line
 initial import
 r2 | mysvnuser | 2005-09-04 23:34:13 -0700 (04 Oct 2005) | 1 line
 added file

I had no trouble with svn+shh (on bundy):

$ svn co svn+ssh://mysvnuser@bundy.dreamhost.com/home/mysvnadmin/repos/project work

Note: The mysvnadmin user must have "Enhanced Security" turned off in order to share data between the two users. There is a checkbox on the User setup screen (under Manage Users) that allows you to toggle enhanced security.

Using Apache basic authentication

The prior section's steps require each user to have a Unix account with shell access so they can log in via SSH.

However the Dreamhost panel provides a way to create user accounts only for Subversion.

But for those accounts, if you want to specify who has read vs read-write access and/or per-directory of your repository, you will need to manually edit the .access file as described in the latest Subversion manual on "Per-directory access control" and Dreamhost's implementation of this feature. You can manually add and administer the usernames and passwords for Subversion by using htpasswd to add/edit users to the .passwd file for your repository.

Note after manual editing either the .access or .passwd files,

  • the file's group changes from dhapache to whatever the auto-generated group for your account is, which prevents the Apache module from being able to read the files, so you then need to change the permissions so that they can be read by Apache(do "chmod 644").
  • You will also need to avoid else be prepared that if you now use the Dreamhost control panel to change settings (at least if you make changes to the user list), the panel will not only revert the file permissions back to dhapache but it will also overwrite both files, overwriting any changes you made to them, so you'd best have a backup to reconstruct anything important that might have gotten overwritten.

Note that "chmod 644" is giving "world" read access to those files which may be a security risk: while these files won't be accessible via http (unless you also publish your svn/ which would likely be unwise), these files would be accessible to other shell users to your account and MAYBE by other Dreamhost account holders on your shared host (though the parent directory is unreadable by the average user); however the passwords (in *.passwd) are hashed so someone would have to break the hash which is likely reasonably hard.

However one would put one's password (and data) at risk by using http to sniff the connection. Therefore, for real security, you should not use http, but instead https (which is also the only option if accessing via WebDAV) or SSH (by creating Unix accounts with SSH shell access as described above).

Using Subversion for Web development

Using Your Repository (via Command Line)

Now that you imported your files to the Repository, you might be wondering how to leverage version control to your advantage. First thing you need to do (if you haven't set it up already) is set up a Development area and a Live area. For the purposes of this HowTo, http://dev.yoursite.com/ will be our development area and http://www.yoursite.com will be the Live area.

1 ssh into your Dreamhost account. From your home directory, we'll be issuing the following commands. 'svn help' can be very useful.

2 Back-up your site

tar -cvvf yoursite.tar yoursite.com/

3 Check out your repository to your development area

svn checkout http://svn.yoursite.com/yourProject dev.yoursite.com

4 Check out your repository to your live area

svn checkout http://svn.yoursite.com/yourProject yoursite.com
rm -rf yoursite.com
mkdir yoursite.com
svn checkout http://svn.yoursite.com/yourProject yoursite.com

Note: If the yoursite.com directory is the directory you initially imported from, you may get errors. I recommend starting from scratch (why I had you back up the site to begin with)

NOTE: These instructions are for use on the server. If you are using Windows for development, do not create a folder with a name ending in .com, as this can cause problems with some Windows security programs that flag the directory as an executable file.

Publishing from Dev to Live

All the changes you made in your Dev area are now ready to go Live.

1 Go to your dev directory

cd dev.yoursite.com

2 Commit your changes

svn commit -m "Your change log notes"

3 Go to your live directory

cd ~/yoursite.com

4 Update Live

svn update

Automatic Post-commit Checkout

Subversion can be a very useful tool for developing Web sites or Web-based applications. You may wonder, though, how that would work. After you commit your changes to your repository, how do you have them reflected on your site? The easiest method is to have your site's directory on the server be a working copy checked out from your Subversion repository. If you elect to do this be certain to modify your site's .htaccess to prevent users from browsing Subversion's control files. Something simple in the root of your site such as the following will suffice.

RedirectMatch 403 /\.svn

Additionally you can configure your site to automatically check out the current sources from your repository by using Subversion's "hook scripts". In short, the script called hooks/post-commit will be executed by the web server each time new sources are checked into your repository. Be advised that when the web server executes this script it is running in the security context of the dhapache user -- this user does not and should not (for security reasons) have the necessary permissions to modify the files in your web site's directory. As such we need to arrange for the post-commit script to run the update in the security context of a user with the privileges necessary to update your site.

Users familiar with UNIX systems will recognize that this is a task for a setuid binary. Unfortunately the DreamHost /home/ directories are NFS filesystems which are, for security reasons, mounted with setuid disabled. Fortunately the workaround is trivial -- simply set up your update script as a CGI script and have the Subversion post-commit hook invoke this script. Instructions follow.

1. Create a private directory on your website to host your updater script such as /home/username/mysite.com/cgi-bin/pri

1b. And set its permissions so that only the user has write access to it.

chmod 755 pri

2. Secure the private directory by creating a .htaccess file with contents similar to the following.

AuthName "Dialog prompt"
AuthType Basic
AuthUserFile /home/username/mysite.com/cgi-bin/pri/.htpasswd
Require valid-user

3. Using the htpasswd utility create the .htpasswd file by running the following command in your /home/username/mysite.com/cgi-bin/pri directory. For security reasons make up a new username and password and do not re-use the username and password of a user you have created on your server or a user you have given access to your subversion repository.

htpasswd -bc .htpasswd someuser somepasswd

4. Now that you have created and secured a directory for this special CGI script to live in, create a script in that directory called do_update.cgi with the following contents.

set -f
echo "Content-type: text/plain; charset=iso-8859-1"
/usr/bin/svn update /home/username/mysite.com

4b. Don't forget to give execution privilege to your file. Only the user can have write access to it.

chmod 755 do_update.cgi

5. Finally, modify your /home/username/svn/projectname/hooks/post-commit to invoke your CGI script so your site will update after each commit.

wget --http-user=someuser --http-passwd=somepasswd -qO - http://mysite.com/cgi-bin/pri/do_update.cgi

5b. Don't forget to give execution privilege to your file. Again, only the user can have write access to it.

chmod 755 post-commit

Alternatively, if you run many subversion web projects, you could create a directory in your web space, and create CGI script to update each of them. For example, having all projects in http://mysite.com/projects/proyectname

For this, instead of using script in step 4, use this:

set -f
echo "Content-type:text/plain; charset=iso-8859-1"
PROJ=`echo "$QUERY_STRING" | grep -oE "(^|[?&])project=[^&]+" | sed "s/%20/ /g" | cut -f 2 -d "="`
export LC_CTYPE=en_US.UTF-8 # added for support of non-ascii file names
echo "[Server $SITE] Updating: $PROJ in $PROJDIR"
/usr/bin/svn update /home/$USERNAME/$SITE/$PROJDIR/$PROJ --username user --password pass 2>&1 

and save it as svn_update.cgi. Remember to set permissions afterwards.

Then, instead of the script in step 5, use this:

wget --http-user=someuser --http-passwd=somepasswd -qO - http://mysite.com/cgi-bin/pri/svn_update.cgi?project=myproject

And specify a diferent 'myproject' at the end of the wget line of the script.

Upgrading to Newest Subversion

If you would like to install a newer version of subversion (e.g., for repository syncing), then you will need to go to this page


and download both the subversion-x.x.x.tar.bz2 and the subversion-deps-x.x.x.tar.bz2. The "deps" file contains all the subversion dependencies.

Compilation and Installation

Compiling subversion is pretty straightforward but you may encounter some compilation errors depending on the version. In general, follow these steps to compile and install subversion locally:

mkdir tmpwork
cd tmpwork
wget http://subversion.tigris.org/downloads/subversion-x.x.x.tar.bz2
wget http://subversion.tigris.org/downloads/subversion-deps-x.x.x.tar.bz2
tar -xjf subversion-x.x.x.tar.bz2
tar -xjf subversion-deps-x.x.x.tar.bz2
cd subversion-x.x.x
./configure --prefix=/home/{yourlogin} --with-ssl [See version specific config information below]
make install

That will install the new subversion into your user directory. You'll need to change the path to include your ~/bin directory to use the new binaries. To do that type this:

alias svn='/home/USERNAME/bin/svn'


For 1.5.6, a compilation error will occur if you use the above configure command:

relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC

so when configuring use this:

./configure --prefix=/home/{yourlogin} --with-ssl --enable-shared


Just did an install with v1.6.6 and the standard configuration compiled fine.

You'll want to add the path to your installed version to both your .bash_profile and .bashrc

Be aware that if you upgrade your repository (svnadmin upgrade) to the 1.6 format, you will not be able to access it via http (use svn+ssh instead).

Interfacing with Subversion from PHP

You'll need to install the PECL extension SVN. Detailed instructions are available here: http://hp.jpsband.org/xhtml-compiler/docs/compile-svn.txt

Setting up post commit emails

Using Post-commit.tmpl

  1. Load up ~/svn/(repository name)/hooks/post-commit.tmpl file in a text editor.
  2. Change /usr/lib/subversion/hook-scripts/commit-email.pl "$REPOS" "$REV" something@example.org to: /usr/lib/subversion/hook-scripts/commit-email.pl --from SVNADDRESS@YOURHOST.COM "$REPOS" "$REV" YOURADDDRESS@example.org
  3. Save the file as post-commit (remove the 'tmpl' file extension). The new file should be owned by your user (NOT dhapache). Run chmod a+x post-commit to give the file world-executable permissions.

(Note: The --from section is crucial because the script will fail if it does not have a "from" address. Any e-mail address will do.)

Try a commit with your svn repository, and you should receive a commit notification e-mail.

Using Adam Doppelt's Ruby Script

A much more aesthetically pleasing script is also available here: Post-commit email in Ruby

  1. Copy the script (svn-email.rb) to: /your-svn-repository/hooks/svn-email.rb
  2. Load up the file in a text editor and change the line MODIFY_THIS@MODIFY_THIS.COM to an e-mail address like SVN@YOURHOST.COM
  3. Save the file
  4. Load up post-commit.tmpl in a text editor. Comment out (using the # symbol) the line: /usr/share/subversion/hook-scripts/commit-email.pl "$REPOS" "$REV" commit-watchers@example.org
  5. Insert a line below like this: /home/your_username/svn/your-svn-repository-name/hooks/svn-email.rb "$REPOS" "$REV"
  6. Save the file as post-commit (remove the 'tmpl' file extension). The new file should be owned by your user (NOT dhapache). Run chmod a+x post-commit to give the file world-executable permissions.

Try a commit with your svn repository, and now you should have a very pretty html-based e-mail.

External Links

Books and tutorials

  • Version Control with Subversion is the Online Subversion book freely available online in its entirety. If you have shared hosting, focus on the file:// and svn+ssh:// protocols (which do not involve any actual continually running "server" processes that might not be good in a shared environment). If you have a dedicated hosting, you can do whatever you want I imagine.

GUI Integration

  • Versions is a graphical Mac OS X application for managing Subversion repositories.
  • Cornerstone is a graphical Mac OS X application for managing Subversion repositories.
  • SCPlugin is a Finder contextual menu plugin for Mac OS X for subversion operations. Windows users will recognize it as the Mac analogue to TortoiseSVN.
  • <oXygen/> SVN Client, now its own product at Syncro SVN Client , is a cross platform Subversion client; it includes a free 30-day trial and costs $59 as of 20090705.
  • SvnX is an excellent GUI for Mac OS X.
  • TortoiseSVN is a subversion client implemented as a Windows shell extension.
  • RapidSVN Multi-platform GUI for Mac OS X, Linux, Windows.
  • SVN Notifier is a tiny Windows application that sits on your taskbar tray and monitors the folders you specify so it can warn you when they need updates.
  • Ankh SVN is a Visual Studio 2008 plugin (for Windows) to use Subversion as a source control provider.

Web-based repository browsers

These provide a number of convenient features, including RSS feeds, integrated bug tracking, collaborative documentation:

See Also