Recipe#9: Setup Repository On VisualSVN

Overview: At the start of a software project, you need somewhere to store and version your source code, from where it can also be shared with others on your team. I use VisualSVN Server as my SCM server.

Use case: I am starting the redesign of my financial webapp (Geldzin) and need a new source repository for the project where I will check in source files and other resources, and launch builds + automated tests from.

How-To:
* Open VisualSVN Server. Right-click: Repositories > Create New Repository.
* Provide name {geldzin2} and check "create default structure". [OK].
* If you don't already have users configured, use the "Users" node to create a few.
* If you don't already have user groups configured, use the "Groups" node to create some. Add users to groups so that permissions be set on group rather than individual users.
* Setup security for the repository. Right-click newly created repository, select Properties | Security tab. Set Everyone -> No Access. [Add]. Select group or user [OK]. Give this group Read/Write permissions. [OK].

Recipe#5: Configure Eclipse for SVN

With access to an SVN server, you need to configure your IDE to connect to available SVN repositories. In Eclipse, you'd need to install and configure the Subclipse SVN plugin:

1. Open menu Help > Install new software ...
2. Add the Tigris Subclipse update site http://subclipse.tigris.org/update_1.6.x
3. Select the Core SVNKit library, JNA library, and Subclipse.
4. After installation, you can further configure the plugin at Window > Preferences > Team > SVN.

To check in a project:  right-click project in Eclipse, select Team > Share Project.
To checkout a project: select menu File > Import, select SVN > Checkout Projects from SVN.
Thereafter, all version control operations (update, commit, add, etc) are available from the Team menu.

Recipe#4: Install an SVN Server

Even if you are the sole programmer on any project, it is imperative that you use version control for your source code and documentation. I use Apache Subversion (SVN) for, among other things:

1. Be able to revert to a previous version of an application, either because my current working copy is corrupted or full of unanticipated bugs.
2. Sharing the project with other developers for collaboration or contribution.
3. Maintaining multiple branches or tagging code at specific milestones.

To use SVN in development, you need an SVN server and SVN client. I use Visual SVN for the server component, installed on a separate machine than what I use for development. VisualSVN is easy to manage and configure, but I mostly like its ability to authenticate via Windows users or your own creations, and access to the checked-in artifacts over HTTP(s) (browser and clients).

On why you have no excuse for not using source versioning:
http://betterexplained.com/articles/a-visual-guide-to-version-control/
http://www.relisoft.com/co_op/whyvcs.html
http://www.mactech.com/articles/mactech/Vol.14/14.06/VersionControlAndTheDeveloper/index.html
http://jamesmckay.net/2009/06/why-would-anyone-not-use-source-control/
http://www.soundsoftware.ac.uk/why-version-control

Using Subversion for NetBeans on Windows XP

Any programmer by now knows the value of having a source versioning and change management facility. A day comes when you mess up existing programs or lose your work, and that's where you can check out the latest working version from a repository somewhere. Beyond that, other benefits of using SCM include source code control and configuration management.
Because of simplicity and cost (free), I decided to use Subversion as the SCM solution. Subversion is designed to replace CVS, which I've had some trouble with. My latest aggravation comes from CVS's popular error message "cvs [server aborted]: Couldn't chdir to working directory : Invalid argument" (2.0.51d). Rather than try to resolve the issue, I decided it was time to find another solution, thus Subversion.

We've come to a point in development where we are making a lot of changes to the timecard utility. In order to preserve all our work, we should start checking it into a repository. This will also allow us to branch the application and merge changes from various contributors.
Here's the process for installing Subversion n Windows XP and to use it in NetBeans 6.0 (M10).

1. Download Subversion from http://subversion.tigris.org/project_packages.html. Choose the binary executables under the Windows section. I'm using version 1.4.4.
   
2. Run the executable and note the install directory (C:\Program Files\Subversion).
3. Add environment variables: SVN_EDITOR = C:\Windows\notepad.exe (to use Notepad as the log editor), and to PATH += C:\Program Files\Subversion\bin (NetBeans needs this).
4. Create a database directory that'll hold your versioned projects (J:\Subversion). Use the usual Windows Explorer for this.
5. I want all my NetBeans projects to be versioned under the NetBeans directory in the SVN database. So we create a repository as such - at command prompt, svnadmin create "J:\Subversion\NetBeans". A directory should appear under your SVN database (#4).
6. The repository in #5 above has a conf directory. Open the svnserv.conf and uncomment anon-access = read, auth-access = write, and password-db = passwd. Save that file.
   
7. Open the passwd file with a text editor and add a user under [users] in the form username = password. Save the file.
8. Create a windows service for SVN: at the command prompt, run sc create svnserver binPath= "\"C:\Program Files\Subversion\bin\svnserve.exe\" --service --root J:\Subversion --listen-port=6043 --listen-host=localhost" DisplayName= "Subversion Repository" depend= Tcpip. Startup is manual, so visit the Services applet and set how you want it to start, and start it.

In NetBeans, import the project into SVN:

1. Right-click the project -> Versioning | Import Into SVN Repository ...; repository url = svn://localhost:6043/NetBeans, enter the username and password specified earlier. [Next].
2. Repository folder defaults to the project folder name. I'd leave it like that. [Finish].
   

That's all! At the completion of each task, you should check your work in. If multiple developers work on the project, synchronize your local workspace with the latest from SVN.