Another common conflicts is a Tree Conflict. Tree conflicts arise when the directory layout of the project changes, and can arise when folders and files are moved, deleted or created. Such conflics will cause a capital ‘C’ to appear in the svn status commands output – these must be resolved before your merge can take place so that svn knows what it should do with the files that will be merged. Note that you should treat these conflicts carefully and ensure that anyone else who may be affected by the changes is happy with the resolution you are about to apply.

Once you’ve agreed on how the conflicts will be fixed, you can use the svn resolve command to determine what action should be taken suring the merge.

For example:

svn resolve --accept mine-full /path/to/folder

indicates that the local changes should be used.

In contrast, if the changes from the server are to be used, then use this:

svn resolve --accept theirs-full /path/to/folder

Be aware that the above instruction will cause the local changes to be lost.

There are a number of different options to select (in addition to mine-full and theirs-full) that give you more control over resolving, or postponing, the conflict. See the excellent SVN manual for deails of these.

There are two ways to ignore files in svn: global settings and local. Global settings configure the users environment with some rules for ignoring files, but generally the local ignores are more useful and will be discussed here.

Most projects have files that should be ignored and not included in the version repository. For example, in Java projects, the compiler output shouldn’t be included as these can be regenerated from the source anyway. You might also have temporary cache files being generated, or output from running unit tests that you don’t want to share too.

Ignoring files and directories

Each directory in a svn managed project has a sub-directory called .svn which contains configuration information that svn uses when working in that directory. To make svn ignore certain content within a directory you need to configure an svn:ignore property for it.

To demonstrate this let’s work with the following project directory structure:

myproject/log-2009-12-01.txt
myproject/log-2009-12-02.txt
myproject/build/classes

First let’s tell svn to ignore the log files that have been created. I’m using SVN 1.5.4 on a Mac so I’ll demonstrate this using a command line but you could do much the same using a GUI tool like Tortoise:

$ svn propset svn:ignore 'log-*.txt' myproject

The above command has used the propset command to set the svn:ignore property value to log-*.txt for the myproject directory.

Note that it is possible to use a wild-card ‘*’ as part of the file name. You can also use the ‘?’ symbol to match a single character in a file name but svn does not currently support any more powerful matching features.

Importantly note also that the file name must be quoted in order that the literal value is passed to the svn command; without this the shell will process the wild-card and pass all matching file names instead.

You can inspect the value of this property using the propget command like this:

$ svn propget svn:ignore myproject
log-*.txt

An ignore property can also be applied to directories, causing all files and sub-directories within it to be ignored. To make svn ignore the classes directory and its contents we could use the command:

$ svn propset svn:ignore 'classes' myproject/build

Setting multiple ignore rules within a directory

So far we’ve looked at how we can set an individual ignore rule within a directory using the propset command. Although both of the rules we’ve demonstrated have resulted in multiple files being ignored, either by using a wild card syntax or by specifying a directory whose content will also be ignored, we’ve not yet discussed is how these rules can be combined within a directory; for example: to ignore all log files and also a sub-directory:

/myproject/log-2009-12-01.txt
/myproject/log-2009-12-02.txt
/myproject/classes

The svn:ignore property is actually a list of file name patterns that svn must ignore. The propset command simply overwrites that list with a single line that includes the pattern you specify when you issue the command.

To create a list of file names that will be matched, use the propedit command instead:

$ svn propedit svn:ignore myproject

Your svn editor will then be started and you can edit the list of filenames that must be ignored. For our example it would need to look like this:

log-*.txt
classes

Note that each file name pattern must be on a separate line.

Ignoring versioned files and directories

You must be aware that the svn:ignore properties only apply to any files that are not under version control.

In practical terms this means if you accidentally add a file or directory to your version control, you will need to explicitly issue a svn delete command (rm) in order that svn will ignore the files.

Commands like add and import work recursively in svn, so it’s easy to accidentally add files like those mentioned above to a versioned project. For example if our log files were accidentally added we could issue this command to delete them from svn:

svn rm log*.txt

Note this time that the filename is not quoted as we want the shell to pass all log files to be deleted.

After committing the changes to the project, the files will no longer be managed by svn and the ignore properties will once again work.

After a little experimenting, I figured out the following commands could be combined as illustrated below:

From within the project root folder this command can be used to list all of the .svn directories:

$ find . -type d -name .svn

If your directory names don’t have spaces or quotes in them, then you could just pipe the find command directly into xargs and rm to delete them all:

$ find . -type d -name .svn | xargs rm -rf

If you do have spaces or quotes in your directory names, then you need to change the newlines returned from find into null characters (notice the -print0 flag), and make xargs use this to split the input into individual file names (see the -0 flag) rather than the newlines, spaces and quotes that it normally looks for:

$ find . -type d -name .svn -print0 | xargs -0 rm -fr

The above command will delete all directories named ‘.svn’, regardless of whether they have spaces, or quote characters in their names.

It’s much better to work in a branch and to merge the changes once you’re convinced they are stable. This post demonstrates how to do this using the Subversion command line tools; however, the same principles would apply if you were using a GUI tool like Tortoise for example.

Creating a branch

Creating a branch is simple. You just copy the revision you want to make changes to into the branches folder of your project in the SVN repository, for example:

svn copy http://svnserver/myproject/trunk http://svnserver/myproject/branches/stevescopy

This will create a copy of the head revision in the project called ‘myproject’ in a branch folder called ’stevescopy’ on the SVN server found at ’svnserver’.

You may notice when doing this that the copy operation completes very quickly, this is because no files are actually copied, SVN just copies markers to file versions making branching a very cheap and fast operation to perform.

Next you should check out the branch before working on it in the usual manner. So, following the previous example, we could check out our branch using:

svn co http://svnserver/myproject/branches/stevescopy .

When working on the code in the branch, you should feel free to commit changes as frequently as you like. The changes that you make are now completely separate from the head revision.

Merging changes back to the trunk

When you’re ready to merge whatever updates you’ve been working on back into the trunk, you should first commit all changes in your branch. To do this, issue the SVN commit command from the working directory of your branch:

svn commit -m 'committing the branch before merging'

Next, in a separate directory, check out the version of the project that you want to merge your changes into. In our case we want to merge our changes back into the head revision:

svn co http://svnserver/myproject/trunk .

Now we can perform the merge. The merge does not change the data held in the repository, instead it updates the local copy that we have just checked out. So, from the directory into which we just checked out the trunk, we should issue a command to merge the changes from our branch:

svn merge http://svnserver/myproject/branches/stevescopy

SVN will now update all the files in this working copy with the changes made in our branch. If there are conflicts (i.e. another user has updated the original trunk files since you checked them out) then SVN will detect this and it will ask you to resolve them. Once completed, you should check that your project builds and passes all of its tests before committing your merged copy back to the trunk:

svn commit -m 'committing with updates from the stevescopy branch'

Cleaning up

If you don’t plan to do any more work on the branch, you can delete it using something like this:

svn rm http://svnserver/myproject/branches/stevescopy