r7 - 20 Aug 2012 - 19:49:21 - JohnPerkinsYou are here: TWiki >  CSDocs Web  >  CSLDocumentation > FileSharingAndSVNHowTo

Sharing Files/Using Subversion (SVN)

This document explains how to set up AFS groups for sharing files, and also how to use Subversion for version control. This document was adapted from our documentation on CVS. Users who are going to use Subversion version control software are encouraged to review the Subversion Book for further reference in creating and using Subversion repositories. Commands shown here are shown for unix hosts; Windows users will find the same functionality if TortoiseSVN is installed on their computer (using the Windows Explorer, right-click on any given file or directory and look for "TortoiseSVN" in the drop-down menu for SVN commands).

Setting Up AFS Groups For Sharing Files With Other Users

You want to set up a pts group to share files in your AFS space with other users. You can find documentation on how to do this on our AFS How-To page.

We'll assume you've created a group frida:cs736-group; to add write access to all the members of this group, you'd want to run afs_rseta as follows:

afs_rseta repository_path frida:cs736-group write

Windows computers do not have an afs_rseta command available. We recommend you set the ACLs on your repository command using fs setacl or via the Windows Explorer by right-clicking on the directory and opening AFSAccess Control Lists.... You can find information on how to use fs setacl on our AFS How-To page. Subdirectories and files created in this directory with an SVN "import" will inherit the parent directory ACLs. Memberships of the PTS group(s) used in ACLs can be easily modified at any time, but it is important to get the ACLs set correctly when first establishing the repository.

Creating The SVN Repository

First, you need to decide what kind of repository backend (where your files are stored) you want to use. You have two choices: FSFS and BDB. Only FSFS will work with AFS filesystems; if the repository is in your home directory, you must use FSFS. BDB can provide some advantages with very large repositories, but local filesystem space must be allocated for the project. If this is necessary for any reason, users are advised to work with CSL to make sure adequate filesystems are available with data backup before establishing such repositories.

To use Subversion for version control, you need to create a repository, where the master copies of your files are kept. This only needs to be done once. The syntax for doing this:

svnadmin create repository_path

Next, import data into your repository. Here, you have a couple of options:

svn import mytree file:///repository_path -m "repos-title"
svn import mytree svn+ssh://repository_host/repository_path -m "repos-title"
svn import mytree svn+ssh://user@repository_host/repository_path -m "repos-title"

Any of these forms will import the contents of directory mytree. If you want your repository to keep all the files under a mytree directory within the repository, you should make sure your repository_path includes mytree at the end of the directory name like this:

svn import project1_files file:///u/f/r/frida/repository/project1 -m "project1"

For Windows workstations, your file repository reference should look something like this:

file://afs/cs.wisc.edu/u/f/r/frida/repository/project1
file://localhost/u:/f/r/frida/repository/project1
svn+ssh://repository_host/u/f/r/frida/repository/project1
svn+ssh://username@repository_host/u/f/r/frida/repository/project1

The first format will attempt to access files directly via the AFS client on your workstation. The second uses the AFS client through its local drive mapping. The third format attempts an SSH session

The first option access files through the filesystem on the machine you are running the command; the second option will ssh to repository_host and run the svn command there. The only difference between the last two forms of this command is if you are connecting to an offsite computer with a different login name; user can be specified for the ssh connection in that case.

The CSL recommends using one of the first two formats above. If it is necessary to use the svn+ssh repository definition, some things to keep in mind:

  1. You will may need a copy of PuTTY, a free SSH client, available on your computer; SecureCRT will not work for SVN repository access.
  2. You will need to make sure GSSAPI authentication is disabled in the connection profile to repository_host. This will force a password prompt with each SVN operation, but it will also make sure your SVN operations are authenticated on repository_host when your repository is housed on an AFS filesystem.

Checking Out A Copy Of The Repository For Editing

Now each user in the cs736-group group can create a working directory (also called a "sandbox"), to edit or change project files. To check out a copy of the project tree, a checkout would look like this:

svn checkout repository_path

Do NOT do this checkout while in the repository_path directory! Run your checkout elsewhere.

The project1 example above would look like this:

svn checkout file:///u/f/r/frida/repository/project1

This will create your cs736-p2 working directory as a subdirectory of your current directory, which only you have access to. You can now safely edit files in your copy of the source tree without fear of your changes conflicting with other users' changes.

Adding New Files To The Repository

Any user can add files to their "sandbox" copy of the repository data, although they will need to tell Subversion new files have been added, like this:

svn add file1 file2 ...

Things to keep in mind when adding files like this:

  • The repository path does not need to be specified; that is stored in your sandbox when you checkout files.
  • Adding a directory will, by default, recursively add files in directory specified to the repository unless you specify not to recurse the directory; consult the Subversion Book for how to do this.

Commiting Changes

If you make any changes to files in your "sandbox", you will need to commit them before others in your workgroup can access them. The command to do this is as follows:

svn commit -m "commit comment"

...where commit comment is a comment for you to note what changes you just committed to the repository.

Updating Your Own "Sandbox" Copy

If others in your group have committed changes, you may want to update your own sandbox to make sure your copy of the files are up-to-date. To do this:

svn update

Exporting A Version

When it comes time to turn in an image of the project to the professor or publish your project for others outside your workgroup, the svn export command is very handy. svn export works much like svn checkout, except that SVN files are not created, only an image of the latest version (or whichever version you select).

The command to do this takes a number of forms:

svn export dir my-export svn export repository-path my-export

The first form will export directory a-wc into directory my-export; you would run this from within your project sandbox. The second form will export from the repository-path into directory my-export. The examples using user "frida" above would look like this:

svn export project1 my-export svn export file:///u/f/r/frida/repository/project1 my-export

You can specify exactly which revision to export; this is documented in the Subversion Book.

-- JohnPerkins - 21 Feb 2008

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r7 < r6 < r5 < r4 < r3 | More topic actions
 
CSL Home
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback