New to SVN? Not sure how best to maximize your efficiency when working with SVN? We’ve compiled a few guidelines here to help you get started with SVN and work more efficiently.

There are numerous ways to lay out your repository and, ultimately, only you can decide on a layout that works for you.

The officially recommended structure includes a “project root” which serves as the anchoring point for your project. The “project root” is made up of three subdirectories: /trunk, /branches, and /tags. Your repo can have only one project root, or several of them. 

For repositories with entirely unrelated or only loosely related projects, it is important to ensure that each project has its own /trunk, /branches, and /tags to ensure that changes in one project don’t affect the usability of another project. 

 
In this way, each project gets its own folder with the /trunk, /branches, and /tags folders created beneath it. However, this layout may not be optimal if you will need to create a branch or tag with files from both ProjectA and ProjectB. In that case, you may want to create a single root with multiple projects.

Typically, /trunk is the main development line for your project. Depending on your team’s workflow, you may or may not make commits here. On the other hand, /branches are used in many ways, but most often to protect the development on /trunk. Finally, /tags are usually used to create “snapshots” of your project at a specific point in time. This is the main difference between branches and tags - most often, tags are  not modified once they are created, while branches are often created for the express purpose of modifying them. For more information on branching and tagging, check out this article.
​

The system you use to determine when to branch depends on your own project workflow. However, there are three common systems in wide use:

In this system, all users commit their work to /trunk. Sometimes, /trunk will break if the user is committing complicated changes. This system is easy to follow and has a low barrier to entry because no one needs to learn how to branch or merge. However, development in this manner can be chaotic and the code could easily become unstable. 

In this system, all users create a private branch for every single coding task. Then, when they are done with their task, someone else reviews the changes and merges them to /trunk. Because of this, /trunk is guaranteed to be stable all of the time. However, this system requires much more branching and merging than is necessary which can interrupt the workflow and cause unnecessary delays.

Finally, you could use a system that attempts to bring together the best of both worlds. In this system, users commit their everyday work on /trunk. Also, commits must be small enough that they can be easily reviewed by peers. However, /trunk must compile and pass regression tests all of the time. So, if it is impossible for a user to make several small commits without disrupting /trunk, then the user will create a branch and do their work there. That way, peer review is encouraged without disrupting /trunk.

It’s important to remember that when you make a commit to your repo, it should complete one particular purpose. It’s never a good idea to make a commit that fixes two different bugs, for example. When you keep commits for different purposes separate, it is easier to keep track of what is being accomplished where.

An important fact to keep in mind is that your working copy’s directories and files will most likely be at different “working” revisions. 

Every time you make a commit in SVN, the things you just committed become the HEAD revision, and everything else remains at an older revision.

There are certain commits that can’t be completed. For example, you can’t complete a commit that entails deleting a file or directory which doesn’t have a working revision of HEAD. Additionally, you can’t complete a commit with a property change to a directory which doesn’t have a working revision of HEAD. To fix these problems, svn update will bring the entire working copy up to one working revision.

One benefit of working with SVN is that there is no hard limit to the file sizes that it can handle because files are sent “streamily” in both directions between the client and server. In this way, a small, constant amount of memory is used on each side of the network.

However, while there is no hard limit on file size, there is, of course, a practical limit on file size. Files larger than a dozen or so megabytes will take a large amount of time and space to upload. The good news, though, is that uploading large files won’t harm your server or affect other users.

Additionally, it is important to remember that your working copy will store pristine copies of all of your version-controlled files in the .svn/text-base/ area. Because of that, your working copy will take up at least twice as much disk space as the original dataset does. 

Have questions? Email us support@assembla.com