gnome-keyring

Subversion might complain about needing to store passwords in a unencrypted form. To prevent this, we need to figure out how to enable the gnome-keyring add-on. To do this, edit the file ~/.subversion/config and search on the string password-stores. Most likely this will be commented out in your current configuration file. I updated mine to the following:

password-stores = gnome-keyring

However, this was not enough to prevent me from being prompted each time. I then added the following package:

yum install subversion-gnome

We will see if this permits us to store the password or not (you may need to be logged into a GNOME desktop in order to make use of the gnome-keyring feature).

Directory Structure

Currently the directory structure under Subversion is fairly straight forward. We use trunk as the current working area (this is what most developers will be checking out from and committing to). When we have a release, we will copy trunk to the release number. For example, to create the 2.13.0 release, we would run the following Subversion command:

svn copy ${SVNROOT}/trunk ${SVNROOT}/releases/2.13.0

We would also run the following command for maintenance updates to the 2.13.0 release:

svn copy ${SVNROOT}/trunk ${SVNROOT}/maintenance/2.13.0

Subversion Commands

Use the following to get the list of available subversion commands:

svn help

To get more information about a specific Subversion command (like ls), run:

svn help ls

Checking Out Code

To make the initial checkout of the current source code into a sub-directory named nst, you can use the following Subversion command:

svn co ${SVNROOT}/trunk nst

Committing Code

You use the commit subversion command when you want to commit changes to the source code.

When you first run commit, it may prompt you for the password for the incorrect user ID. If this happens, press the Enter key without specifying a password. This should allow you enter your SourceForge user ID followed by your SourceForge password when committing changes. For example:

[root@fedora11 nightly]# svn commit
Authentication realm: <https://nst.svn.sourceforge.net:443> SourceForge Subversion area
Password for 'root':
Authentication realm: <https://nst.svn.sourceforge.net:443> SourceForge Subversion area
Username: SOURCEFORGE_LOGIN_ID
Password for 'SOURCEFORGE_LOGIN_ID':
Sending nightly/nightly-build.bash
Sending nightly/nightly2html.xsl
Sending nightly/nightly2txt.xsl
Transmitting file data ...-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:
<https://nst.svn.sourceforge.net:443> SourceForge Subversion area
can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.
You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/root/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? no
Committed revision 4.
[root@fedora11 nightly]#

Status

The Subversion status command is very handy at showing not only what files you've modified, but also (when including the -u option) handy at showing what files have changed in the repository:

svn status -u

For help about the output of svn status, run:

svn help status | less

Revert

If you've made modifications to a file which you want to discard, use the revert command to restore the original version:

svn revert FILENAME

To revert back to a previous revision use the merge option. The follow example reverts back to the 3986 revision from the 3987 revision for file: "bwmonitor.js". After the revert changes are applied you will need to commit. Use the Subversion Browser to assit in finding your revision numbers.

svn merge -r 3987:3986 bwmonitor.js

Revert Commit, Undo Commit, Reverse Merge

If you've committed modifications to a file accidentally it is a bit tricky to undo the commit. To get back an older version you need to perform something called a reverse merge. This is done by running the svn merge -r BAD:GOOD SOURCE command. Where BAD is typically the current revision ID of the source you want to revert, GOOD is the revision ID of the good code you want to restore and is typically 1 less than the value of BAD. SOURCE is typically the name of the file or directory you want to undo the commit on.

For example, we can used the following command to determine the last changed revision of the files under the current directory:

In this example the BAD revision ID is 10660 associated with the last commit done to this area. To restore the files to the 10659 state (the good version prior to the 10660) state, we would run the following command:

As the status command shows, this undo only impacted one file in the directory and is not immediately reflected in the repository.

[pkb@refritos server]$ svn status
M xrdp.cgi
[pkb@refritos server]$

This allows us to inspect the undone changes. If we are happy, we can commit this version back. If we are unhappy with the results, we can revert the state of the directory and try again.

Ignoring Files

Under CVS, you could edit the file .cvsignore to tell CVS to ignore certain files within the directory. Subversion has a similar, but different mechanism for ignoring files. Basically, you change to the directory where the files/directories to be ignored exist and run the following command:

svn propedit svn:ignore .

Running the above command should pull up a text editor and allow you to specify file name patterns to specify what files and directories should be ignored. Here is an example ignore list which causes Subversion to ignore any file or directory ending with the extension .log or having the name tmp:

*.log
tmp

Manage The Executable Flag On File

Use the following command to set the executable flag on a file (e.g., bwmonitor-ajax.php)under SVN control:

svn propset svn:executable bwmonitor-ajax.php

Use the following command to remove the executable flag on a file (e.g., bwmonitor-ajax.php)under SVN control:

svn propdel svn:executable bwmonitor-ajax.php

Merging Changes Across Revisions

Our general strategy is typically to do all new work under the trunk area. However, when we move from one Fedora platform to another (like from Fedora 13 to Fedora 15), we will typically copy the trunk area to a sub-directory under the maintenance area. For example, the following shows the top level Subversion heirarchy (where you will see trunk and maintenance) and the number of older maintenance areas where we have the ability to maintain older versions of the software.

This is the old method used for merging and updating the Trunk Area with code changes in the Development 18 Area spanning from revision: "'4869" to the "HEAD (4877)" (latest changes committed to the dev/18 area). Use the following link for NST code revision reference: http://nst.svn.sourceforge.net/viewvc/nst

Switching To A New Root

There can be many different branches of the same source tree at different levels of development within the Subversion repository. You can use the switch command to switch from one branch to another. When making a switch, the source code you have checked out will be updated to match the state of the source code in the new branch. Before making a switch, it is important to make sure that all of your changes are checked into the current branch. For example, the following demonstrates how to switch to the dev branch from the trunk branch: