aka SVN (Subversion). A source code version control system to
replace CVS (Concurrent Versions System). It is available as source or as binaries for
11 different operating systems, including
W2K, XP, W2003, Vista, W2008, W7-32, W7-64, W8-32, W8-64, W2012, W10-32, W10-64, Linux and OSX. The latest version is 1.9.7
Last revised/verified: 2017-08-17. 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 (Operating System)
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
Ways to Access the Subversion Server |
Protocol |
Notes |
file:/ |
Direct repository access (on local disk), e.g. file://localhost/D:/svnrep where snvrep
is the directory where the repository is stored. |
http:// |
Access via WebDAV (Web-based Distributed Authoring and Versioning Protocols)
protocol to Subversion-aware Apache server over the Internet |
https:// |
Same as http://, but with
SSL (Secure Sockets Layer)
encryption |
svn:// |
svn://localhost or svn://mindprod.dyndns.org will get you to the configured
repository. Access via custom TCP/IP (Transmission Control Protocol/Internet Protocol)
protocol over port 3690 to an svnserve server. You
will need to poke a hole is your firewall to allow communication over that
port. Subversion usually runs as a Windows service you set up with
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 Dyn to make your
face IP (Internet Protocol)
and port 3690 known and visible to the public.
Users will need a username/password for access. SVN
will authenticate it using an MD5 (Message Digest algorithm 5)
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
|
svn+ssh:// |
Same as svn://, but through an
SSH (Secure Shell)
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 (User Interface)
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. Keep in mind these instructions
are for when you are hosting the SVN
repository on your own machine. Normally it will be on some other machine, e.g.
wush.net. 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 (Uniform Resource Locator)
file://localhost/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 experimental tiny repository to start till you get he
hang of how to make sure your excludes work and how to check things into 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, usually the current and one back.
- Every directory tree under Subversion control gets an embedded .svn subdirectory hanging off the root directory. (Formerly, every
directory in the tree got one.) In the pristine directory
off that are a snapshot of all your files the last time you committed them to or
fetched them from the repository, without any additional information, headers or
footers or compression. They have globally unique digest names. Be careful not to
disturb these files, especially when running utilities that act on your directory
tree containing the .svn tree. Happily, the pristine files have the extension .svn-base,
so most utilities will not touch them.
- If you are using Tortoise Subversion, poke around with the rep browser. From
right click menus, you can checkout and other setup.
Downsides
- If you have a crash, it is not at all clear what to do to recover, especially
if your source files are intact just the Subversion files are damaged.
- If you have been running a project for a decade or so, the very early history
is no longer of interest. There is no way to get rid of it to shrink the
repository.
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 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 (Internet Service Provider)
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
server 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.
browse mindprod source in repository
access mindprod source in repository with [Tortoise] Subversion client on wush.net/svn/mindprod/com/mindprod/