Using the Subclipse Subversion Source Control
COMP 310    Java Resources  Eclipse Resources

ALWAYS COMMIT THE ENTIRE PROJECT!
Committing just a package or a file WILL result in repository corruption!

The page will discuss how to use Rice's Subversion source control facilities with the Subclipse plug-in for Eclipse.

To use Subversion ("SVN") source control for managing projects or for turn-in, be sure to first install the Subclipse plug-in. 

If you wish to manually turn-in work from the Unix command line, then you will need to initialize the turnin directories as described below.

Rice IT directions on using Subversion, which includes directions on how to make your personal SVN repositories: https://docs.rice.edu/confluence/pages/viewpage.action?pageId=25170300

Help on using Subclipse is available through the Eclipse Help system.   From the main menu, select Help/Help Contents and then click on the Subclipse chapter.

See the general information page on Subversion source control

Be sure to check out the semester-specific source control information for your particular class, as the specific repository information and procedures may vary from year to year.

Quick Links to the topics below:

Quick start:

General tasks:

 

WARNINGS! 

Accessing Your Own Repository

To connect Eclipse to your personal repository, use the SVN Repository Exploring perspective (see Open a SVN Perspective below) to connect to your repository.   See Add a New SVN Repository to View in Subclipse  below.

This all you will ever need to access any code in your own repository.   There is no need to add additional repository connections for projects stored in your own repository.

Setting Up a Project for Teams and Connecting to Someone Else's Project

Here, one member of the team, whom we will call the team "leader", will have the shared code stored in a folder in their repository and all other members will connect to that repository for the code.

Team "leader":

  1. Create a Java Project in Eclipse and commit it to an appropriately named folder in SVN.  See Add an Existing Project to Subversion and Committing the Entire Project below.    The Java project can be essentially empty at this point. 

All other team members:

  1. After the team leader has committed the new project, add the repository to Eclipse, including the new project's folder name in the URL, e.g.  "https://svn.rice.edu/r/comp310-svn/turnin/S17/teamleader_netid/HWXX".   (CHECK THE COURSE MATERIALS FOR THE EXACT URL!) See Add a New SVN Repository to View in Subclipse but add the folder name to the repository URL.
  2. Check out the entire repository.  See Creating a New Eclipse Project from an Existing Project in the SVN Repository below.

All team members should now be working on the same codebase.

Open a SVN Perspective

To work with Subversion, you must first open a SVN "perspective":

  1. Click on the menu item Window/Open Perspective or the "Open Perspective" button on the upper-right corner of the Eclipse window.
  2. A sub-menu will open.   Click on "Other...".
  3. The "Open Perspective" dialog window will open.   Highlight "SVN Repository Exploring" and click "OK".
  4. A total of 4 new tabs will open:  "SVN Repositories", "SVN Annotate",  "Task Repositories" and "History".
  5. Once the perspective has been created, a button for it appear on the upper right corner of Eclipse.

 

Add a New SVN Repository to View in Subclipse

It is possible to have many different repositories of code, for instance one's personal development repository and the course turn-in repository.   To use a repository, you must first add it to Subclipse.

  1. Either right-click the "SVN Repository" and select "New" then "Repository Location..."   or click the "Add SVN Repository" button at the upper-right corner of the SVN tabs.
  2. The "Add SVN Repository" dialog window will open.   Type in the URL of the desired SVN repository and click "Finish".
  3. When asked, enter your NetID login credentials.

 

Add an Existing Project to Subversion

Usually one has already started a project and needs to add that code to source control.  

  1. Be sure you are in the "Java" perspective.
  2. Right-click the project that you wish to add to source control, scroll down the pop-up menu and click on "Team/Share Project...".
  3. In the dialog that appears, highlight the "SVN" repository type and click "Next".
  4. Assuming that you already added the desired repository as per the directions above, click on "Use existing repository location" and highlight the desired repository that you wish to use.  Click "Next".
  5. Either use the project name as the folder name or create a specific folder name to use.    You can create the save location as a sub-folder of a new or existing folder.   IT is recommended that you repository's folder structure mirror your local workspace structure.  Click "Next".
  6. Add any desired commit comments that will help identify this project from all others.  Click "Finish".
  7. When asked, let Eclipse open the "Team Synchronizing" perspective.

At this point SVN knows about all the files in your project, but those files have not yet been "committed" to the repository and fully synchronized with the source control.

 

Committing the Entire Project

Committing the entire project will take all files that are part of source control (Careful!  It is possible to have files that are not in source control!) and upload them to the SVN repository and reconcile those files with any changes that anyone else has made.

  1. Be sure you are in the Java perspective and that the project has already been added to SVN.
  2. If you are working with other people you should ALWAYS perform a "Team/Update to Head" and resolve any conflicts before committing.    If you are getting "file out of date" errors, you should try updating first as well.
  3. Right click the desired project and scroll down the sub-menu to select "Team/Commit..."
  4. A dialog will show all the files which have been changed since the last commit.   Type in a comment that describes the changes that were made.   Click "Ok".

 

Creating a New Eclipse Project from an Existing Project in the SVN Repository

This is what you would do to retrieve code that someone else has created and already committed to the repository but which you do not yet have.

  1. Open up the repository in the "SVN Repository Exploring" perspective.
  2. Right-click the desired project and select "Check out...".
  3. By default, Subclipse will create a project in the current workspace.

 

Going Back in Time

One of the powerful features of using version control is that you have the ability to go back in time.  You can always "revert" your project back to a previous commit.  How valuable this feature is depends entirely on how diligent you are at committing your project regularly and at useful points.  To open up your project at a previous commit:

  1. Be sure you are in the "Java" perspective.
  2. Right-click the project that you wish to go back in time with scroll down the pop-up menu and click on "Team".
  3. Select "Update to Version..."
  4. Uncheck "Update to HEAD revision"
  5. If you know the revision number you want, you can simply enter it.  If not, use the "Select..." button to see a list of revisions and the commit messages that you typed.
  6. You can ignore the rest of the options and click "OK"

You will now be looking at your project exactly as it was at that prior commit point.  You can always go back to the latest version by updating back to the "HEAD" revision.  (Subversion always considers the latest version to be the "HEAD" revision.)

If you decide you want this previous version to be the new HEAD version, you must roll back the changes between the current HEAD and the previous version you want.

 

Knowing Where You Are

One problem with the ability to go back in time is that it becomes more difficult to understand what version of your project you are actually looking at.  We recommend that you modify the preferences slightly in order to be able to know what revision you are looking at.

  1. From the "Window" menu, select "Preferences"
  2. On the left pane, expand "Team" then "SVN" and select "Label Decorations"
  3. Select the "Text" tab
  4. Make sure that the variable {revision} appears in each of the "Format" boxes.
  5. We suggestion you use "R{revision}", so it will show up as R254 for subversion revision 254.
  6. For example your project format could be: "{dirty_flag}{name} [{url_short} R{revision}]"

By setting things up in this way, you can always see what revision you are looking at.  This is critical when you start moving among revisions and working in teams where each team member may have a different revision.

 

Reverting Uncommitted Changes

Sometimes you find that you have made some bad changes and you just want to get rid of them.  You can always get back to the most recent commit in subversion by "reverting" your changes.  This gets rid of all changes you have made since you last committed your code to subversion.

  1. Be sure you are in the "Java" perspective.
  2. Right-click the project or file that you wish to revert, scroll down the pop-up menu and click on "Team".
  3. Select "Revert..."

This will easily get you back to where you were.

 

Rolling Back to a Previous Version

As previously discussed, you can go back in time with subversion.  But, you can't just start editing a past version.  Subversion keeps every change that you commit, good or bad, forever.  This is the way it should be.  Imagine it's 4am and you've been working all day.  You decide you messed up and roll back your code 5 revisions back.  When you wake up the next day you find out you were wrong and want all of your work back.  That's okay, it will be right there waiting for you!

This means that if you want to roll back to a previous version, what you are really doing is making a new commit that undoes all of the changes you don't like.  You can later "undo" this "undo" if you decide it was a bad idea.

You do not have to undo all commits between a previous version and HEAD.  In fact, you can select each commit separately and decide whether you want to undo it or not.

  1. Be sure you are in the "Java" perspective.
  2. Right-click the project or file that you wish to revert, scroll down the pop-up menu and click on "Team".
  3. Select "Show History"
  4. Select the revisions that you would like to revert.
  5. Right click and select "Revert Changes from..."
  6. Your working copy will now have those changes removed.  You still must commit the reverted changes if you decide you want to keep it that way.

If you later change your mind, you can revert the changes from the roll back commit, which will effectively "redo" all of the changes.

 

Tagging and Branching

Another invaluable feature of version control is tagging and branching.  In subversion, these two tasks are handled in the same way.  Conceptually, a tag is a marker that allows you to easily get back to a past revision without having to remember its revision number.  In contrast, a branch is a parallel development track on which you make changes that are not committed to the main line of the code.  Subversion handles both branches and tags by creating a new directory that is a snapshot of the current directory.  By convention, tags are always stored as subdirectories of a "tags" directory and branches are always stored as subdirectories of a "branches" directory.

There are a couple of ways to perform a branch using Subclipse (See "Copying a Source-Controlled Project" for the same directions plus screen shots):

RECOMMENDED: Use the "SVN Repository Exploring" perspective:

  1. Switch Eclipse to the "SVN Repository Exploring" perspective.
  2. Right-click the desired repository folder and select "Branch/Tag".
    1. In the "Copy to URL" box, add the appropriate suffix to the repository's URL.  Typically, this would be something like https://svn.rice.edu/r/comp310/turnin/trunk/jqstudent/tags/hw01
    2. Be sure to check the "Create any intermediate folders that are missing" box.
    3. Click "Next" to go to the next page of the dialog.
    4. You likely want to create the tag or branch from HEAD, so leave that checked. Click "Next" to go to the next page of the dialog.
    5. Enter a useful comment that describes the reason for creating the tag or branch.
    6. Click "Finish" to create the new branch.
  3. Check out the new branch into your Eclipse workspace.

Alternate technique: Use the "Java" perspective -- This has the disadvantage that the original project in the workspace will be replaced by the branched project which is typically NOT desirable:

  1. Be sure you are in the "Java" perspective.
  2. Right-click the project or file that you wish to revert, scroll down the pop-up menu and click on "Team".
  3. Select "Branch/Tag..."
  4. In the "Copy to URL" box, add the appropriate suffix to the repository's URL.  Typically, this would be something like https://svn.rice.edu/r/comp310/turnin/trunk/jqstudent/tags/hw01
  5. Be sure to check the "Create any intermediate folders that are missing" box.
  6. You likely want to create the tag or branch from HEAD, so leave that checked.
  7. Enter a useful comment that describes the reason for creating the tag or branch.
  8. Check the "Switch working copy to new branch/tag" box if you wish to start working on that branch.  Otherwise, leave it unchecked.  Usually, you would leave this unchecked for a tag and checked for a branch.

If you are just tagging the repository to make it easy to go back to that version, you are now done.  If you are branching the repository so that you can work on a branch instead of the main code, you can now commit to the branch (assuming you checked the "Switch working copy to new branch/tag" box) and those commits will not affect the main code base.

If you want to switch between working on a branch and working on the main code (or between two branches, you can simply use the "Replace with" menu item and choose "Branch/Tag..."  Be sure you have saved and committed any changes you have made before you do this!

 

Merging in Changes from Another Branch

At some point, it may be necessary to update one branch with changes that were made in another branch.   Typically, this is because the development on one branch has progressed to the point that it is stable and mature enough to be incorporated into the code of the other branch.   For instance, a branch off of the main codebase trunk could be made to develop a new feature without disturbing the codebase trunk.   When that feature development is complete, the feature branch would be merged back into the main codebase trunk, thus updating the trunk with the new feature. 

To merge changes in from one branch back into another you must be in the project into which the changes will be incorporated from the other project.   You cannot merge from the project where the changes were made into another project.

  1. Be sure you are in the "Java" perspective.
  2. Make sure that both the source project (where the changes were made) and the target project (where the changes will be incorporated) have both been committed to source control. 
  3. In the target project, right-click the whole project if that was what was originally branched or just the folder/package if that was the only part that was branched.  Scroll down the pop-up menu and click on "Team".
  4. Select "Merge..."
  5. In the "Select the merge type" dialog, select "Merge a range of revisions".   Click "Next".
  6. In the "Select the merge source" dialog, the location from where the branch was originally made might appear in the "Merge from" input field.   If not, or if this is a merging back to the original branch source, click the "Select..." button and browse to the corresponding folder/package in the source project where the changes were made (could be the whole project).
  7. Select "All eligible revisions" and click "Next".
  8. Take all the default settings in the "Select the options" dialog and click "Finish".

 

 

Using svn:externals to Access a Shared Code Library

It is very common for multiple developers on separate projects to use a shared code library.   In Java, that library is often in the form of a package that common to all developers.   SVN allows a shared code library (a folder = a Java package) that is stored in a single location to be incorporated into multiple projects.   

The svn:externals property of a folder in SVN will bring code in from a separate repository and combine it with the rest of the project code. 

  1. Be sure you are in the "Java" perspective and that your project has been committed to source control.
  2. To obtain the shared code library, you will need to set a "property" on the "src" directory.
    1. Right click the "src" directory and choose "Team/Set Property...".  It is critical you do this on the "src" directory and not some other directory as typically shared libraries are defined relative to the root of the default package.
    2. The property name should be "svn:externals".  You must use this property name exactly (without the quotes).   It is available on the drop list of properties.
    3. Keep "Enter a text property" selected and type "library_name library_svn_url" in the box (all on one line without the quotes).
      • library_name = the name of the shared folder/package that the library represents.  For instance if the shared package is called "provided" then the library_name should be "provided":
      •  library_svn_url = the URL of the SVN repository location that holds the shared library code.   For instance this could be something like "https://svn.rice.edu/r/comp310-svn/course/HWXX/provided" -- CHECK WITH THE COURSE MATERIALS FOR THE EXACT URL TO USE!  
      • If multiple share libraries are used, add additional lines of text with the appropriate "library_name library_svn_url" pairs for each shared library. 
    4. Do not select "Set property recursively".
    5. Click "OK".
  3. Commit the entire project again (this commits the change to the property).
  4. Update your project. 

To add another shared code library, go to "Team/View Properties" and double-click "svn:externals" to open it for editing.   Then simply add another line to the property definition.

To get the latest version of the shared library code:   Perform an "Team/Update to HEAD" on the project.

Typically, the user of a shared library does NOT have write permissions to the shared library repository, so be sure that you do NOT make changes to the shared library code or you will get an permissions error when you try to commit!

If you do have write permission to the shared library repository, any changes to the shared library code will be committed to the shared library repository when the project is committed.

Connecting to a Specific Version of the External Code

Sometimes one wants to bring in a specific version of the external code, not the latest version.    One reason could be a need to test the local code with an earlier version of the external code, for instance, if examining an earlier version of the local code that only works with an earlier version of the external code.  

Some developers do this to decouple the development of the local code from on-going changes in the external code and only changing the connected version of the external code when the local code is ready to be upgraded to it.    In any reasonable size team however, this same effect is created in a much more overall controllable manner with careful management of different development "trunks" to differentiate between "in-development" and "release" versions of various libraries.

The syntax to specify a specifc version for svn:extenrals to bring in is simply to add the "-rXXXX" parameter to the above specification:

 library_name -rXXXX library_svn_url"

where XXXX is the desired commit revision number of the external code.

Creating and Maintaining a Shared Code Library from a Master Codebase

 Shared libaries come from a master codebase, but rarely would one want to immediately update the shared library every time the master codebase is committed.    That means that the share library repository must be separate from the master codebase, i.e. that the shared library repository is a branch of the master codebase.   When the master codebase development has progressed to the point that the shared library needs to be updated with the new changes, the code from the master codebase must be merged into the shared libary repository.   But since Subclipse only allows one to merge into a project, an additional project is needed that has read/write access to the shared library repository, typically through an svn:externals connection.

In the end, to create and maintain a shared code library requires two projects, the master codebase and the shared library maintenance project, each with their own SVN repositories plus one more repository, the actual share library code repository.

The following assumes that the master codebase project already exists and that you are accessing SVN using an account that has read/write privileges to the shared library repository location.

Create the shared code library repository:  (this only needs to be done once)

  1. Branch the package (folder) that contains the code for the shared library to a new repository with the desired name of the shared library repository.

Create the shared code library maintenance project: (this only needs to be done once)

  1. Create a new Java project with a name that clearly identifies it as the share library maintenance project.
  2. Commit the project to source control.
  3. Set the src folder's svn:externals property to map shared library repository to its package name -- this is the same as any developer using the shared library would do. 
  4. Perform a "Team/Update to HEAD" on the whole project and then commit the project.

Update the shared code library repository with changes from the master codebase project:  (this needs to be done every time changes need to be propagated to the shared library for the developers to use)

  1. Make sure that the master codebase project is fully committed.
  2. Open the maintenance project and perform a "Team/Update to HEAD" on it. Commit the project if necessary.
  3. Select the shared code library package and perform a merge from the its original location in the master codebase repository.   This will bring the library changes into the maintenance project.
  4. Commit the maintenance project.   This will also commit the library changes to the shared library repository.

 

Resolving Version Conflicts

When you do "Update to HEAD", you can get a conflict if someone else (or you from another machine) has committed changes that are in the same spot as text that you have changed, but not yet committed.

To resolve conflicts, highlight the file in question and go to Team/Edit Conflicts.

When this happens, the file(s) that have conflicts end up with markers that look as follows:

<<<<<<< .mine
code in your file
=======
different code in SVN repository
>>>>>>> .r350

The way to read this is that everything between the ".mine" marker and the "=======" marker is code in your local file. Everything between the "=======" marker and the ".rX" marker is code in the SVN repository (from version X, in the above case version 350).

At this point, you have the following options:

  1. Edit the file directly and modify the code however you see fit (i.e., using your code, the repository code, some combination, or completely rewriting it). Make sure you get rid of all of the marker lines, as they are obviously not valid Java and don't belong in your file.
  2. Force all conflicts to be resolved in favor of your file (effectively keeping the code between ".mine" and "=======" and deleting the code between "=======" and ".rX").
  3. Force all conflicts to be resolved in favor of the repository (effectively keeping the code between "=======" and ".rX"and deleting the code between ".mine" and "=======").
  4. Force all conflicts to be resolved in favor of the original file you were working with. (NOT RECOMMENDED).

To resolve the conflict, first pick one of the options above. Then, do the following steps:

  1. If you choose option 1 above, edit the file(s) appropriately. For all other options, just skip to step 2.
  2. Select "Team/Mark Resolved...".
  3. Test your program. This is pretty much required. Your program is likely no longer the program you had before you updated to HEAD, as you likely resolved at least some of the conflicts in favor of the repository (under the assumption that your partner is making useful modifications).
  4. Commit your changes.

Note that when there are conflicts, there are usually more than one and they typically occur in multiple files. You need to carefully go through and resolve all of the conflicts.

Tree Conflicts

Tree conflicts arise mainly when files and/or packages are moved.  If one person has edited something and another person moves it (or deletes it), subversion does not know your intentions.

The best way to handle tree conflicts is to prevent them.  If you are reorganizing your code in a way that involves a lot of moving and renaming, you should alert those in your group and have everyone commit their changes first.  Then do all of the reorganization and commit the changed code.  Afterwards, everyone can update to HEAD and continue working.

Sometimes tree conflicts will happen, though.  You may forget to notify your partner, or there is a miscommunication, or you didn't realize you were doing something that would cause a tree conflict.  At that point, you can run into a situation where you must resolve the tree conflict.  Given that there are too many cases to discuss, you just need to follow the dialog boxes that Subclipse gives you and do what makes sense for the situation.

First, select "Team/Show Tree Conflicts".  This will give you a list of conflicts with a brief description (such as "local edit, incoming delete upon update", meaning the file is gone, or moved, in the repository and you have edited it).  If you right click a conflict and select "Resolve..." you will get a dialog box that gives you options.  Hopefully, one of them will make sense in your situation.

 References:

 

Using svn:ignore to enable teams to use separate Build Configurations

Sometimes different team members need to have separate Build Configurations.   A typical scenario is if some team members are running 32-bit JREs  and some are running 64-bit JREs and you need to use JRE-dependent libraries.

What you need to do is to set Eclipse and Subversion to "ignore" the "classpath" settings, which are contained in the.classpath file at the root of the project folder.

  1. Highlight the root of your project and under Team, set the property svn:ignore to ".classpath".
  2. Commit all your code.
  3. Outside of Eclipse, from the root of your project directory, copy your ".classpath" file to a safe location.
  4. Go to SVN Explorer and delete the .classpath file from the latest version in the repository.   svn:ignore will not work on files that are in the repository.
  5. Do an Update to Head.    This will appear to trash a lot of things.
  6. Outside of Eclipse, copy your saved .classpath file back to its original location.  Everything should be back to normal though you may need to restart Eclipse.

Dealing with "Out of Date" Error Messages

There are many possible reasons for getting an "out of date" error message during a commit process.   Fundamentally, it means that the file(s) in the repository are newer than one in your computer.    If the "out of date" entity is a folder, one must remember that SVN will only allow changes to a folder if its revision number is the same as the latest in the repository.

In short, to solve the problem, one must get the local working version to match the version in the repository. 

While not a guaranteed solution, try the following:

  1. Perform an "Update to Head"
  2. Merge any conflicts that arise.
  3. Try to commit again.

References:

 

Dealing with a "Working Copy Locked" Error

The most common reason for this error is when Eclipse or your network connection crashed in the middle of a commit operation.   Essentially, the error is telling you that Subclipse has unfinished business with the code and thus has "locked" it.

One must allow Subclipse to finish its operation and remove the locks::

  1. Right-click the project in the Eclipse's package explorer and open the Team sub-menu.
  2. Click on Refresh/Cleanup.

Sometimes, Subclipse gets confused when there are folders created by svn:externals settings.    If the locked folder is one that from an external repository and Refresh/Cleanup doesn't work, try the following:

  1. Remove the setting in the svn:externals property for that folder.
  2. Perform an Update to Head.
  3. Using your computer's file system browser, check if the folder exists and if it does, if it is empty or not.   
  4. If the folder still exists, see if the Eclipse package explorer still sees it.  You should do a "Refresh" on the package explorer to make sure it is up-to-date..
  5. Do another Update to Head.
  6. Commit the project.
  7. Reconnect the deleted folder by adding the svn:externals property back in.

 

Changing the Repository Location of a Project

Sometimes you need to change the location where a project is stored.    This could be changing the folder in the repository to which the project connects to another folder in the same repository (e.g. you put your homework in the wrong repository folder!) or moving the project's repository location to a completely different root repository, e.g. someone else's repository or another repository you have.

There are two different techniques that can be used here.   Note that all the following techniques must be done by the owner of the repository.

Technique A: Disconnect and Reconnect

This technique will work no matter where you move the repository to but will lose the ability to roll back the code to a point before the move.   The original code and its history is not lost however.

  1. Make sure that that the project is fully checked-in by all developers and is updated to reflect all changes by other developers working on the code, i.e. run Team/Update to Head
  2. In the Java perspective, highlight the desired project, right click and go to Team/Disconnect...
  3. Once the disconnection has finished, go to Team/Share Project...  to reconnect the project as if it was the first time doing so.    See  Add an Existing Project to Subversion.

After you are completely sure everything has properly transferred and that you do not need the original repository folder any more, you can go into the SVN Repository Exploring perspective and delete that remote folder but this is not recommended.   Rather, simply rename the old folder to something like xx_old and ignore it.   This way, it will always be there in an easy-to-retrieve form should you need anything from it.       Rolling back a remote folder after delete is possible in SVN, but it is not a convenient thing to do and rarely is it obvious that a deleted folder needs to be restored because a deleted folder is invisible.

Technique B: Disconnect, Rename, Move and Check-out

This technique only works if the new folder location is in the same repository but it does preserve the ability to roll-back to any previous version.    It is a little more involved process however than the other technique above and the project can only be moved within the same repository.

  1. Make sure that that the project is fully checked-in by all developers
  2. In the Java perspective, highlight the desired project, right click and go to Team/Disconnect...
  3. In the Java perspective, rename the project to something like xx_old.    Deleting the project is not recommended.  You can always simply close the project in Eclipse to ignore it.
  4. In the SVN Repository Exploring perspective, right-click the current repository folder and select Rename/move... 
  5. Once the remote folder has moved, you can check it out again as if it was a new project from an existing project in SVN.   See Creating a New Eclipse Project from an Existing Project in the SVN Repository.

Do not delete the old version of the project until you are absolutely sure that it will never be needed again.

 

 

"Unfinished transactions detected" or "Cannot commit" Errors

 There are many possible reasons for these errors and they can be very difficult to diagnose and fix.   

First, try doing a Team/Cleanup on the project and recommitting.   You may need to restart Eclipse.

If that fails, here are some reasons that have been found:

 

The following information is NOT applicable to the COMP 310 class and is included here only for completeness, for use when working with your own SVN repositories outside of class.

How to Give Someone Else Access to a Repository

IN COMP 310, ALL SVN PERMISSIONS ARE SET BY THE INSTRUCTOR AND THE IT DEPARTMENT. STUDENTS CANNOT CHANGE THE PERMISSIONS ON ANY REPOSITORY ASSOCIATED WITH THE CLASS!

The following directions on setting folder privileges only apply if you are working in your personal repository obtained directly from IT or one where you have sufficient permissions to do so.  In general, for a class repository, you will NOT have such privileges--the class staff will set up the access privileges for your repository.   In this case, simply create the team folder and project folders as needed and proceed to the next section below on instructions for your teammates.

When you are working in a group, you will want everyone in the group to share the same repository location for everyone's code.   The easiest way to accomplish this is to pick a folder location in one of the member's SVN repository and give permissions to the other team members.   All projects in that folder will be accessible to all team members.  Giving permissions to an entire folder that contains project(s) rather than just a single project, allows team members to branch and tag the main project, which creates new projects in the repository in that folder. 

 

Setting up SVN folder permissions to give others access:

  1. In Eclipse, open up the SVN Repository Exploring perspective.
  2. If you don't already have a folder you wish to give permissions to your teammates, right-click the top level of the repository and select "New/New remote folder"
    1. In the New remote folder dialog that comes up, select the location in which you want your new folder to be located, typically the top level of your repository or the top level folder for this class.
    2. Enter  a meaningful name for your new folder and click Next.
    3. Enter a commit comment that describes why you are making this new remote folder.   Click Finish.
  3. If this is your first time to give someone else permissions, you must create a new Eclipse project that will enable you to modify the permissions in your repository.
    1. In your repository, locate the folder called rice_config, which should be right below the top level of the repository.
    2. Right-click this folder and select "Checkout...".
    3. Follow the usual procedure for checking out a new project from SVN.
  4. Open the Java perspective and open the rice_config project if it is not already open.
  5. You should see two files in that project.   When you try to open them, Eclipse may ask you to specify an editor--any one will do, such as the "Text Editor" choice:
  6. In a nutshell, you specify, surrounded by square brackets, the name of the folder to which you want to give permissions.   Below that, you specify what permission you want to give to whom.
  7. For example:
    [/]
myNetID = rw

[/MyTeamProjects/ProjectA]
myNetID  = rw
teammate1NetID = rw
teammate2NetID = rw
teammate3NetID = r

[/rice_config]
myNetID = rw
* =
  8. In the above example, the only text added was the middle part, concerning the MyTeamProject folder.   All of the rest of the text should have already been there.  NEVER CHANGE ANY PERMISSIONS THAT ARE ALREADY THERE AS YOU MAY LOCK YOURSELF OUT OF YOUR REPOSITORY!!
  9. After all the necessary changes to access_file have been made, save it and check it The change in permissions are immediate effective.
  10. If it doesn't yet exist, create a new project for the team in Eclipse and commit it to a folder that is a subfolder of the one you created for the team projects, MyTeamProjects above.
  11. Give the URL of the shared folder to your teammates.   It should be something like:   "https://svn.rice.edu/r/myNetID/MyTeamProjects/ProjectA".

For your teammate(s):

Each teammate should add  a new repository to the SVN Team Exploring tab (click the "Add SVN Repository" icon on the "SVN Repositories" tab) using the URL of the shared folder that you gave them.

© 2020 by Stephen Wong