aka SVN. A source code version control system to
replace CVS. It is available as source or as binaries for 11 different operating
systems. The latest version is 1.6.6 Last revised/verified: 2009-10-22.
Subversion fixes many of the infuriating CVS problems e.g.
- Subversion versions not only file contents and file existence, but also
directories, copies, and renames. You have to do these file operations with a
Subversion client. It is not smart enough to track such changes done with the OS
or other programs. It versions directories as well as files. This means you can
delete and restore directories. You don’t have to keep dead empty
directories around forever as in CVS. It also means that Subversion keeps track
of the history of the renaming of a file. In CVS renaming looks like the
deletion and creation of a new file with no record of the connection.
- Lack of atomic commit. With Subversion, no part of a commit takes effect until
the entire commit has succeeded. Revision numbers are per-commit, not per-file.
This especially important with flaky dial up connections. Also someone fetching
while you are saving won’t get an inconsistent set of files.
Eclipse is still using CVS, but gradually the world is flipping over to
Subversion. You can monitor the trend looking at which repository the various
open source projects use. Subversion was designed originally for Linux/Unix. It
does not dodge various inefficiencies of Windows and is hence about only half
the speed of CVS.
There are five ways to access the Subversion server:
| Ways to Access the Subversion Server |
| Protocol |
Notes |
| file:/// |
Direct repository access (on local disk), e.g. file:///D:/svnrep
where snvrep is the directory where the repository is
stored. |
| http:// |
Access via WebDAV protocol to Subversion-aware Apache server over the
Internet |
| https:// |
Same as http://, but with SSL encryption |
| svn:// |
svn://localhost or svn://mindprod.dyndns.org
will get you to the configured repository. Access via custom TCP/IP protocol
over port 3690 to an svnserve server. Subversion
usually runs as a Windows service you set up with SC.exe
like this:
Your installer may do this for you automatically. Usually you configure your
router to tunnel that port through your firewall to the outside so it is visible
to the Internet world, possibly using DynDNS to make
your face IP and port 3690 known and visible to the
public. Users will need a username/password for access. SVN will authenticate it
using an MD5 challenge scheme that does not require the password to be sent over
the Internet, either in plain text or encrypted. You have to manually maintain
the list of users and passwords in a file something like this:
[users]
harry = sesame12
sally = sparkle76
Normally you would configure:
|
| svn+ssh:// |
Same as svn://, but through an SSH tunnel |
There are also groups who will host your Subversion project for you if you use
one of the official open source licences. See distributing
Java Source for details.
When you install Subversion, it uses three directories:
- C:\Users\user\AppData\Roaming\Subversion for
the configuration files.
- F:\Program Files\CollabNet Subversion Server for the
program files.
- F:\svn_repository for the repository files.
The server has no UI other than the config files. To control it you need some
sort of client, e.g svn, svnadmin, Tortoise SVN.
There is no step-by-step set of instructions to install a simple system. They
want you to understand it in fullness before you use it. Here is an abbreviated
get started instructions:
- Download and install the Subversion server, the appropriate binary. Set it up
for purely local access.
- Download and install Tortoise SVN client.
- Go to F:\svn_repository in my computer.
- Right click to wake up Tortoise, then create the repository files.
- Edit the config file. In particular set up these
fields:
- Go into IntelliJ Idea and use Import into Subversion to make a snapshot of your
development files in subversion. If you don’t have Intellij, do this with
Tortoise.
- Use Tortoise to browse the repository using the URL file:///D:/svn_repository
- Then you must check out to a directory where you can then start editing the
files. You must checkout even though there are no changes from the ones imported.
- I would suggest doing an expermental tiny repository to start till you get he
hang of how to make sure your excludes work, and how to check things in to the
correct place in the hierarchy, then throwing it away as many times as necessary
before you do your production version.
The catch is this will capture all your files. There is no point in capturing
class files, jars etc since they can easily be recreated from source code. I
have not yet learned to teach Subversion to avoid capturing class files.
Tips
- There are two places I have found so far to control what to exclude from the
repository, the Subversion server configuration file, the TortoiseSVN settings.
- The blame command lets you view a listing showing the
age of each line of code, in what revision it was last modified.
- The diff command compares two revisions pointing out
the differences, usualy the current and one back.
Subversion Hosting
You can use a subversion hosting service instead of hosting it yourself. For
example, if you register with wush.net
you (or others) can access the Subversion server with http://wush.net/svn/
mindprod or https://wush.net/svn/
mindprod where mindprod is your account.
You may also permit https://wush.net/websvn/
mindprod for browser-based WebSVN access to your repository
without an SVN client.
There are many advantages to hosting your repository with an ISP rather than
hosting it on your own machine:
- You don’t have to configure Subversion. The ISP handles that for you. You
can be up and flying in minutes rather than a day or so.
- Adding users and controlling access is done with a simple checkbox web app.
- The repository is offsite. It won’t be stolen or damaged if your own
computer is stolen or burned.
- The ISP makes nightly backups as a matter of course.
- You don’t have to fool with configuring your firewall to pass traffic
through.
- When you reboot your development machine, it will not interfere with anyone
accessing Subversion from the Internet as it would if you hosted your subversion
serever there.
- People on the Internet accessing the server don’t put any load on your
development machine.
- The people who run the hosting service are Subversion experts and will be able
to help you over the rough spots.
- Access to your repository will be considerably slower than on your local machine.
Not only are their net delays, there are delays from other users of other
repositories on the ISP server machine. I get only about 100K bytes/second
transfer rate to my remote Subversion server.
- If Internet access to the server goes down, you can’t get at your
repository.
- You don’t get access to the fancy Subversion configuring features.
- You have to do your wildcard excludes completely in the client e.g. *.class
*.obj *.zip */javadoc */jetpdb temp.* temp?.*
- If your code in top secret, you have to trust the ISP not to peek at it.
Mindprod Subversion Repository
You don’t have to download the entire package to browse the source code of
any Canadian Mind Products programs, even ones not released officially, by
looking in the Subversion repository which also track the history of changes.
view mindprod source in repository : novice
browse mindprod source in repository :
intermediate
access mindprod source in repository with [Tortoise] Subversion client on wush.net/svn/mindprod/com/mindprod/
: advanced