Subversion : Java Glossary

• 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.

There are five ways to access the Subversion server:

# list of users
[users]
# user = password pairs
harry = sesame12
sally = sparkle76

When you install Subversion, it uses three directories:

1. C:\Users\user\AppData\Roaming\Subversion for the configuration files.
2. F:\Program Files\CollabNet Subversion Server for the program files.
3. 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:

1. Download and install the Subversion server, the appropriate binary. Set it up for purely local access.
2. Download and install Tortoise SVN client.
3. Go to F:\svn_repository in my computer.
4. Right click to wake up Tortoise, then create the repository files.
5. 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:
6. 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.
7. Use Tortoise to browse the repository using the URL (Uniform Resource Locator) file:/D:/svn_repository
8. 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.
9. 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.

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.

Subversion Hosting

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/