Examples below use an imaginery repository located at svn+ssh://firstname.lastname@example.org/project
Create and Import
I prefer to create plain file backed repositories as they don’t suffer the same inconsistency quirks as the berkley database backed repositories. The following will create a new repository called project in the current working directory.
svnadmin create project --fs-type fsfs
If you don’t have any files to import you can start creating files as you develop and then use svn add to put them into version management.
The following will checkout the project into a directory called myproject, created in the current working directory.
svn checkout svn+ssh:/email@example.com/project/trunk myproject
Build directories or log directories can be annoying when they continue to show up in the svn status command. You can instruct subversion to ignore them using
svn propedit svn:ignore target
Tagging and Branching
Make sure the tags or branches directory is created first.
svn mkdir svn+ssh://firstname.lastname@example.org/project/tags
From the base directory of your project, tag the release or create the branch.
svn copy . svn+ssh://email@example.com/project/tags/1_0_0
Updating a tagged revision
If you need to make updates to a tagged revision (say 2.1.0) when the main trunk has already progressed with new development (2.2.0 for instance) you can do it as follows.
Copy the 2.1.0 tag into a branch
svn copy svn+ssh://firstname.lastname@example.org/project/tags/2_1_0 svn+ssh://email@example.com/project/branches/2_1_1
Checkout this new branch and make code updates within it. You can commit changes as you would if you were working on the trunk.
svn checkout svn+ssh:/firstname.lastname@example.org/project/branches/2_1_1 myproject-2_1_1
When finished, tag the new version.
svn move svn+ssh:/email@example.com/project/branches/2_1_1 svn+ssh:/firstname.lastname@example.org/project/tags/2_1_1
If you try to apply changes and end up with a file in conflict (marked with a C next to its name) you have 3 ways to solve this; merge text in the file by hand, copy one of the temporary files over the top of the original, run svn revert on the file.
If you fix the problem by hand, or by copying one of the temporary files over the top, you must let subversion know by using the following command.
svn resolved <FILE>
Merging changes from a tag/branch back into trunk
You need checked out copies of the tag/branch and trunk. It’s easier if changes in trunk are committed as it makes rolling back easier (just use the revert command).
Next, work out which revisions from the tag/branch you want to apply into trunk. You can do this with svn log (within the tag/branch) to see when it was created and what has been committed. From with trunk, run the following command.
svn merge -r 200:204 svn+ssh:/email@example.com/project/branch/big_change
At this point changes are made locally in trunk (201,202,203,204, 200 is not inclusive). Compile code, check changes work then commit them being very specific of what just happened in the log message, e.g. Merged branch/big_change r200:204 into trunk
Relocating a subversion repository
Maybe the server breaks down, or you just need to move the location of your subversion server. In theory you can do it with the following command.
svn switch --relocate svn+ssh:/firstname.lastname@example.org/project/branch/2_2_2 svn+ssh:/email@example.com/project/branch/2_2_2 .
The command above should recurse into subdirectories, although when I tried it, it didn’t work for me. Resorting back to sed you can do the same as follows.
for file in `find . -name 'entries'`; do sed firstname.lastname@example.orgemail@example.com/g $file > $file'A'; done for file in `find . -name 'entriesA'`; do mv `dirname $file`/entriesA `dirname $file`/entries; done