This blog details a quick step-by-step detail for creating a subversion repository.
First install subversion binaries (http://subversion.tigris.org/).
Create the Repository
Next open up a command prompt and type in
> svnadmin create \svnrepository
This creates a new repository under folder \svnrepository
. If you browse to this folder you will see folders/files that subversion uses internally to manage itself.
Next create the project directory.
> svn mkdir -m "Creating initial project root folder" file:///svnrepository/myapp1
You can later on choose to create another project such as
> svn mkdir -m "Creating initial project root folder" file:///svnrepository/myapp2
So now you have two projects myapp1
and myapp2
. Subversion tracks all of your folders and files, so how you decide to organize your folder structure is up to you. Recommended structure is:
1 2 3 4 5 |
project\ \trunk \branches \tags |
- trunk will contain your main line development
- branches will contain just that. You can also use this folder to create temporary branches and then remove them later (remove does not delete the folder…it just removes it from the HEAD version).
- tags will hold code that has been labeled over time
Upload the initial code base
So my sample project directory is:
1 2 3 4 5 6 7 8 9 10 11 |
myapp1\ \trunk \dev \web \service \test build.xml \docs \branches \tags |
Lets import this code into our repository for the first time.
> svn import myapp1 file:///svnrepository/myapp1 -m"initial load of myapp1 code base"
You will see some log messages from subversion indicating that the code is being checked in. Now what you have is a repository loaded with the first version of the project. Your original source structure is not “connected” to subversion. The import command leaves the originalsource as-is.
To get “connected” with subversion you will issue a checkout command such as:
> svn checkout file:///svnrepository/myapp1
Once again you will see a bunch of log messages indicating the files are being checked out.
Running Subversion as a Windows Service
In the commands above I am using the local repository URL file:///svnrepository/myapp1
.What if others need to connect to the same repository. One option is toshare your folder. The better option is to run subversion as a service.You have various options to do this, but the simplest way is toregister the svnserve executable as a windows service.
> sc create svnserve binpath= "\"c:\ProgramFiles\Subversion\bin\svnserve.exe\" --service --root c:\\svnrepository"displayname= "Subversion" depend= tcpip start= auto
Enter the above command on a single line. Also if there are spaces in your path then escape with quotes.
Next install the Eclipse Subclipse plugin. Open the SVNrepository perspective. Create a reference to a new repository location. In our case use the URL file:///svnrepository/myapp1or svn://localhost
. Use svn: only if you have the svnserve executable running.
If you want to restrict who can access the repository then edit the file /svnrepository/conf/svbserve.conf.
This file is only valid if you use svnserve executable, as is clearly mentioned in the comments inside this file. Create the users and their passwords in the /svnrepository/conf/passwd
file.
Working with subversion
- Edit the code file. The edits are local and not visible to other users.
- Check in the file. Now other users can “see” the changes when they sycnh to the HEAD version.
- To get changes from others perform an ‘update’ on the folder. This will synch your working copy with the HEAD version.
- Remember when you check a file into subversion it versions the entire code base and not just that one file. This way subversion is able to take you to the state of the code for a given checkin. This is slightly confusing for folks who are used to other repository tools that version file by file.
- Of course in your local copy you can have files from various versions and not just the head.
Creating Tags (or labels)
A tag is a point-in-time snapshot of the state of the repository. Say you finished an important milestone (end of an iteration or sprint). You can create a tag to mark the repository state at that point-in-time.
1 2 3 |
svn copy <a href="http://svn.example.com/repos/myapp1/trunk">svn://hostname/svnrepository/myapp1/trunk</a> \ <a href="http://svn.example.com/repos/myapp1/trunk">svn://hostname/svnrepository</a><a href="http://svn.example.com/repos/myapp1/tags/R1-S1">/myapp1/tags/R1-S1</a> \ -m "Release1-Sprint1 tag" |
Creating Branches
You are done with Release-1 and now want to continue on release 2, but you know there is a 1.1 release planned with a few minor features. Release-2 will continue on the main line (trunk). For 1.1 we create a branch from the 1.0 release code (you probably tagged it).
1 2 3 |
svn copy <a href="http://svn.example.com/repos/myapp1/trunk">svn://hostname/svnrepository</a><a href="http://svn.example.com/repos/myapp1/trunk">/myapp1/trunk</a> \ <a href="http://svn.example.com/repos/myapp1/trunk">svn://hostname/svnrepository</a><a href="http://svn.example.com/repos/myapp1/branches/release1.1">/myapp1/branches/release1.1</a> \ -m "Creating branch for 1.1." |
You will notice that the commands to create a tag is the same as that for creating a branch. Subversion shows no difference in the two. Just remember to use tags to create point-in-time snapshots and branches to track and work on multiple streams of work.
You can create branches for work that is risky. Lets say a major refactoring effort and you do not want to mess with the mainline (trunk) yet. Create a branch and then do the refactoring there. Once everything is good to go on the new branch merge it into the main line.