EECS Repo | Main / EECSRepo

The purpose of the EECS Repo project is to create a facility that allows UCB and non-UCB participants to access shared version control resources for files such as papers and software development. The motivation is that there is a need for students, faculty and staff to collaborate on shared files in a secure manner and avoid having non-backed up state on laptops etc. By providing a common Source Code Management (SCM) infrastructure, we can avoid costly duplication of effort.

As of October, 2012, EECS Repo supports Subversion (aka SVN) and Git.

Quick Start

To get started:

Go to https://repo.eecs.berkeley.edu
Log in using your UCB EECS LDAP account name and password
There are two types of spaces, personal and non-personal. If you only have a personal space you will be sent to its management page on login. If you also administer one or more non-personal spaces, you will be sent to the space selection page on login; in that case, select a space in one of the two pulldown-lists, then click Select Space.
Add a repository to your current space: Under Repositories, click on Add, enter a repository name, for example test1, select Subversion or GIT, then click Create.
Check out your repository using Subversion:

 $ cd /tmp
 $ svn co https://repo.eecs.berkeley.edu/svn/users/YOURNAME/test1
 Checked out revision 0.

or for a git repository:

 $ cd /tmp
 $ git clone https://repo.eecs.berkeley.edu/svn/users/YOURNAME/test1.git
 Cloning into 'test1'...

The Location of the SVN Repository

The Subversion command to check out a repository is:

 svn co repositoryURL

In EECS Repo, an SVN repository is either a personal space or a non-personal space.

A SVN repository can be accessed either with named accounts or (if enabled) anonymously.

There are personal SVN repositories that have the following repositoryURL:
https://repo.eecs.berkeley.edu/svn/users/eecsUserName/repository
or, if anonymous access is enabled:
https://repo.eecs.berkeley.edu/svn-anon/users/eecsUserName/repository

There are non-personal SVN repositories:
https://repo.eecs.berkeley.edu/svn/projects/space_name/repository
or, if anonymous access is enabled:
https://repo.eecs.berkeley.edu/svn-anon/projects/space_name/repository

Hint: To see the path of a repository, go Repositories -> Access and click on the repository name.

Subversion Clients

Windows Subversion client: TortoiseSVN.
Mac users probably have the svn command installed. To check, start up the Terminal and run svn. If the command is not found, Mac OS 10.7 (Lion) users may download XCode for free or find a free version of XCode 3.

The Location of the Git Repository

The git command to check out a repository is:

 git clone repositoryURL

In EECS Repo, a Git repository is either a personal space or a non-personal space.

A Git repository can be accessed either with named accounts or (if enabled) anonymously.

There are personal Git repositories that have the following repositoryURL:
https://repo.eecs.berkeley.edu/git/users/eecsUserName/repository.git
or, if anonymous access is enabled:
https://repo.eecs.berkeley.edu/git-anon/users/eecsUserName/repository.git
or, if your ssh key is uploaded to git:
repoman@repo.eecs.berkeley.edu:users/eecsUserName/repository.git

There are non-personal Git repositories:
https://repo.eecs.berkeley.edu/git/projects/space_name/repository.git
or, if anonymous access is enabled:
https://repo.eecs.berkeley.edu/git-anon/projects/space_name/repository.git
or, if your ssh key is uploaded to git:
repoman@repo.eecs.berkeley.edu:projects/eecsUserName/repository.git

Hint: To see the path of a repository, go Repositories -> Access and click on the repository name.

Git Clients

Windows users, see https://code.google.com/p/msysgit/downloads/list
Mac users, for a command line client, see https://code.google.com/p/git-osx-installer/downloads/list?can=3, for gui clients, see http://stackoverflow.com/questions/455698/best-visual-client-for-git-on-mac-os-x

Repository Suggestions

When deciding on a layout, things to consider include

Is this a truly a one-off collaboration, or will I be doing the same thing with the same group over time?
How much security is really required? Personally Identifiable Information should not be hosted here. There are many UCB policies that control use of this resource.

Papers

If a group is regularly collaborating on papers, then create a repository for that group and then add subdirectories by year and then by papers. For example, the fictitious Professor Turing might have a paper called turingpapers/12/vonNeumannWasWrong.

Software

Typically, in Subversion, a trunk/ directory is created for the main development trunk and adjacent branches/ directory contains release branches. See Subversion Best Practices. Collecting individual software efforts into one project could help foster collaboration within a group. However, if the repository is too large, then it may make sense to have multiple repositories.

Proposals

Each proposal usually has a slightly different set of collaborators. Each proposal may want to be a separate repository in the user space of a faculty or staff member. Individual users can be granted read-only or read-write access to the repository.

Small Datasets

A handful of small datasets (a few KB to a few GB) can easily be shared by creating a repository to contain them. If the data is public, you can create the repository with anonymous read-only access. If you have more than just a couple of datasets or if it is more data than would fit onto a CD or DVD, this is probably not the best way to distribute it. Also, be sure to review the UCB policies before hosting public data.

EECS Repo Overview

EECS Repo uses http://www.insanefactory.com/if-svnadmin/ iF.SVNAdmin. The iF.SVNAdmin package uses Subversion's path-based authorization.

There are a number of terms:

Spaces - After logging in to https://repo.eecs.berkeley.edu, a user may have access to one or more repository 'spaces'. Each space can hold a collection of repositories and private group definitions. Access to repositories may be controlled by administrators of the space in which the repository belongs. Most users will have control over just their own personal space. Most repositories will generally be created in the personal space of one of the collaborators. Sometimes a research group or organizational unit will have sufficient mass to warrant the creation of a non-personal space for the collaboration.
- Personal space - Each local user is automatically given one personal space. A local user may create and share repositories in their own personal space with other local and external users. The personal spaces are just like any other space in terms of management. The files and configuration for a personal space are stored in EECS managed storage, not in the user's home directory. Most short-term repositories (e.g. for class-projects or paper preparation) likely belong in a user's personal space for ease of creation and management.
- Non-Personal spaces - The system also supports non-personal spaces intended to collect related repositories for some higher-level units such as a long-term, on-going organizational unit, research center, research group, or major sub-group within a research center or organizational unit. The name space for creating new non-personal spaces is shared between all the research projects on this server. Thus, there can be at most one non-personal space with the same name. A local user can administer 0 or more non-personal spaces. Each local user can see only the spaces that they have created or that they administer. To request a new non-personal space, click on the link, fill in the form and the space generally will be created for you. See Why can't I create a Non-Personal Space? If your 'group' has its own web site and needs multiple repositories for separate software, paper, or data offerings, then it is possibly a candidate for a named non-personal space; otherwise consider adding a new repository to your personal space or adding/requesting a new repository in an existing non-personal space that you are affiliated with.
Repositories - A space may contain 0 or more repositories. A repository typically contains work that is to be shared with a group of users. For example, a repository might correspond to a software project, a paper being written, or a data-set or collection of data-sets. See Repository Suggestions. Repositories can optionally be given anonymous read-only access for use as a public distribution service. Access to repositories is granted via access-paths. It can also be useful to create private repositories (accessible only to the user) for check-pointing the development or revisions of code, documents, or data that is under development or shared between multiple devices owned by the user.
Users - There are two classes of users:
- local users that have accounts in the UC Berkeley EECS LDAP database, and
- external users who do not have accounts in the UC Berkeley EECS LDAP database, but have had their e-mail address registered with the repository system by a local user.

Local users can create accounts for external users to access this system. External users are named by their e-mail address, for example user@mydomain.com. Local users can control read/write access by other local and external users for repositories in spaces that they administer.

Groups - Within a space, administrators can share administration and access to their repositories with other users by adding local users and external users to space-specific groups. Each space administrator has the ability to define groups to be used in controlling access to the repositories in that space. These groups are only defined within a single space. (Only local users can be granted administrative access to spaces.)
Groups--ldap - Alternatively, you can import groups from EECS LDAP server. Selected group from the list will be imported to your group list of the space with suffix --ldap. It will contain the members already defined in LDAP. Even though, you can manipulate group membership, since it is a copy of the predefined ldap group, will change only in your local space. Be advised, if group membership changes and subsequent import is performed, all local changes will be lost.
Access-Paths - The access path to a repository is repositoryName:/. Users and/or groups are then given read or read & write permissions for an access-path. Local and external users can be given read-only or read-write access to repositories by the space administrators. Anonymous access is limited to read-only or none (i.e. not read-write). At present, access can only be granted to a full repository and not to sub-directories.

The key take away points: There are personal and non-personal spaces that can contain multiple repositories; every local user is given a personal space that they administer. Space administrators can create and manage repositories including granting access to repositories by local and non-local users. Local users can register the e-mail address of external users with the repository system in order to enable collaboration.

"We intended repo project spaces as a way to manage multiple related repos whether for a specific project or for a research group or center which may have many multiple projects each with one or more repos each.

So, if <Requested_Space> existed as a project within such a center or research group, then it would make more sense to create a repo space for that center or group and place <Requested_Space> within that center/group's space, especially if <Requested_Space> has only a single git repo.

But if you anticipate lots of contributors from outside that group or center or if you anticipate that <Requested_Space> will grow beyond a single repo to having multiple sub-projects in their own separate repos, then it makes sense to create a separate space for <Requested_Space> now, even if it only has a single repo now." --Jon Kuroda, EECS Research

EECS Repo Tasks

Getting started: how to create a repository

Below we create a new user repository called ptpapers and add an external user to a group that can edit the repository.

1. Log in to https://repo.eecs.berkeley.edu with your EECS LDAP credentials.

EECS Repo Welcome Screen

From that page you can

Non-EECS Users can change their password

Read these help pages.

Click on "Log in and administer repositories" and use your EECS LDAP username and password.

2. From that page you can

Select an existing space that the user has either previously created or to which the user has been given access.
Request that a new project space be created.

Hint: Non-personal space names are shared amongst all users. Typically, spaces are created for large, long term research projects that will have multiple repositories. If a project is a short term project, say collaboration on a class project, then consider creating repositories in a user space and granting access to collaborators. Or if the project is a sub-element of some larger research project such as 'ParLab' or 'AMPLab' which already has a named repository space, consider having a repository created within that space.

We are going to create a repository called ptpapers in the user space, so click on the user name in the left hand column under "Select Personal Space" and then click on the "Select Space" button

Selecting the user space

3. Create a repository in the user space called ptpapers by clicking on Repositories -> Add, entering ptpapers into the Repository name field and then hit the Create button.

Creating a ptpapers repository

4. Create a new group called ptPapersAuthors by clicking on the Groups -> Add, entering ptpapersAuthors into the Group name field and hitting the Create button.

Creating a ptpapersAuthors group

5. Add yourself to the group:

Click on Groups -> Memberships
Use the filter entry above the User column to find your EECS login
Click the User name and the Group name
Click the Assign button

Adding a user to the group

6. Add an external user.

Click on Users -> Add
Fill out the Create External User page as below:
Userame: The email address of the user (required)
Last Name, First Name: The name of the user (optional)
Title: Could be anything, Embedded Center Collaborator is our choice (optional)
Password: If you, the account creator set a password, then that password will be emailed to the external user. If the password field is left blank, then a password will be created for the user (optional)

Adding an external user

7. Add the external user to the group:

Click on Groups -> Memberships
In the Filter, enter the username of the external user
Click on the box next to the username
Click on the box next to the group name (ptpapersAuthors)
Click on Assign

Adding an external user to a group

8. Set up the permissions for the group.

Click on Repositories -> Permissions
Click on the box next to the ptpapersAuthors group name.
Scroll down and select Read & Write
At the bottom, select ptpapers:/
Click on the Assign button

In the screenshot below, we typed a ! in the user filter to make the image more compact

Setting the permissions for the group

9. To view the URL of the ptpapers repository, go to Repositories -> Access and click on the access path ptpapers:/

Repositories -> Access for ptpapers:/

After clicking on ptpapers:/

10. If your login on your local machine is the same as the account on the EECS Repo server, then you can access the repository with:

 bash-3.2$ svn co https://repo.eecs.berkeley.edu/svn/users/cxh/ptpapers/
 Error validating server certificate for 'https://repo.eecs.berkeley.edu:443':
  - The certificate is not issued by a trusted authority. Use the
    fingerprint to validate the certificate manually!
 Certificate information:
  - Hostname: repo.eecs.berkeley.edu
  - Valid: from Wed, 22 Aug 2012 00:00:00 GMT until Sat, 22 Aug 2015 23:59:59 GMT
  - Issuer: InCommon, Internet2, US
  - Fingerprint: d3:65:79:fe:3c:ee:79:e4:6b:5d:2a:6c:dd:06:f4:05:80:ca:cb:ec
 (R)eject, accept (t)emporarily or accept (p)ermanently? p
 Authentication realm: <https://repo.eecs.berkeley.edu:443> UCB/EECS Subversion Repository
 Password for 'cxh':
 Checked out revision 0.

The "Error validating server certificate" message is because the CA is not in the OpenSSH list of CAs. See svn: Certificate is not issued by a trusted authority

To test access for the external user, use:

 bash-3.2$ svn co --username cxbrooks@gmail.com https://repo.eecs.berkeley.edu/svn/users/cxh/ptpapers/
 Authentication realm: <https://repo.eecs.berkeley.edu:443> UCB/EECS Subversion Repository
 Password for 'cxbrooks@gmail.com':
 Checked out revision 0.
 bash-3.2$

One tricky issue is that Subversion tends to cache credentials. If the external user password does not work, then try moving ~/.subversion to a safe location and run the command again.

Git

1. Create a Git repository:

Click on Repositories -> Add
In the Repository Name, entry gitTest.git. Note that the Git repository name must end in .git. If .git is omitted, then the system will add it.
Select Type GIT. If you don't, it will create an SVN repository.
Click Create

After clicking on papers:/

2. Allow the ptpapersAuthors group to access the gitTest.git repository.

Click on Repositories -> Permissions
Click on the box next to the group name (ptpapersAuthors).
Scroll down and select Read & Write
At the bottom, select the gitTest.git:/
Click on the Assign button

In the screenshot below, we typed a ! in the user filter to make the image more compact

Allowing the ptpapersAuthors group to access the Git repository

3. To view the URL, go to Repositories -> Access and click on the access path gitTest:/

4. To clone the Git repository, use:

 bash-3.2$ git clone https://repo.eecs.berkeley.edu/git/users/cxh/gitTest.git
 Cloning into 'gitTest'...
 Username: cxh

 Password: 
 warning: You appear to have cloned an empty repository.
 bash-3.2$

SSH keys and Git

Git can use SSH Keys, to upload your key, use Services -> Upload SSH Key

Upload ssh key

Below is a sample run using SSH and Git.

 bash-3.2$ git clone repoman@repo.eecs.berkeley.edu:users/cxh/gitTest.git
 Cloning into 'gitTest'...
 warning: You appear to have cloned an empty repository.
 bash-3.2$ cd gitTest
 bash-3.2$ echo "This is a test" > README.txt
 bash-3.2$ git add README.txt 
 bash-3.2$ git commit -m "A test" README.txt
 [master (root-commit) 978d6ef] A test
  1 files changed, 1 insertions(+), 0 deletions(-)
  create mode 100644 README.txt
 bash-3.2$ git push

Note: Very first git push per repository MUST be - git push -u origin master

Note that the svn server on repo.eecs.berkeley.edu does not support ssh. The svn server on repo.eecs is using the https:// protocol, not the svn+ssh:// protocol. Various svn clients optionally stash your password in various ways, consult the documentation for your local client.

Email Notification

Email Notification upon commit can be turn ON or OFF per repository, by going to Access/Notify page.

Select all repositories from the list that required email notification and hit the Enable button. Alternatively, you can select one or more repositories and disable the notification.

Once the repository is set with Email Notification ON, select the repository and go to repository Access-Path page. Use bottom section to assign/unassign users to the email list. Only users in the list will receive the email notifications.

External User: Password Reset

This is only for external users who are not in the UCB EECS LDAP database.

Go to https://repo.eecs.berkeley.edu and click on Change your password
Enter your username (If you do not know your username, ask your EECS collaborator who created your account.)
Hit Password Reset and the password will be mailed to you.

External User: Forgot User Name

External account usernames are email addresses of the format user@domainname.

External account users who do not remember their account name should contact the person who created their account. Or, see How do I contact someone about this facility?

Anonymous Read-Only Access

The * user matches all users and anonymous access.

To make a repository anonymously accessible, add the * user to the access-path for the repository.

Go to Repositories -> Permissions
Enter * in the User filter
Check the box next to "* - anonymous"
Check the box next to "Read only: The user(s)/group(s) can see all files."
Check the box next to "papers:/"
Click the "Assign" button

Hints: Note that Anonymous repositories cannot be accessed read/write. Also, making a papers repository anonymously readable is ill-advised.

Enabling anonymous access

To access the repository anonymously:

 bash-3.2$ svn co https://repo.eecs.berkeley.edu/svn-anon/projects/embedded/papers
 Checked out revision 0.
 bash-3.2$

Roles

Users may have the different roles assigned to them:

User-Group-Manager - Create/Delete users and groups and manages memberships of users. Least powerful
Repository-Manager - Create/Delete Repositories and manages user and group permissions.
Catalog-Space - Allow SPACE to be part of the global Catalog.
Administrator - Space administrator. Most powerful

To assign a role, got to Users -> Space Permissions. A user may have 0 or more roles in a repository. The roles cover the entire space.

Initializing using svnsync

The svnsync command can be used to initialize a repository from another repository.

Note that the new repository must have no revisions.

In the example below, we create a new user space repository, add a user to the list of SVN Syn users and then initialize the repository

1. Create a new repository:

Go to https://repo.eecs.berkeley.edu/
Log in using your EECS LDAP password
Select on Spaces - Users, select your user name and the click on the Select Space button
Under Repositories, click on Add
Enter a valid repository name. (ex: ActorBook)
Click on the Create button

2. Add a user to the list of SVN Sync Users (This step is only necessary if a user other than the user who created the repository will be running svnsync):

Select Access/Notification, and click on the name of the repository that requires svnsync access. (Click on "ActorBook:/")
In the Access-Path Window, scroll to the bottom of the page and use the user selection box to select the username of the user who will be running svnsync
Click the Assign button. BTW - To remove user, select the username checkbox and click on Unassign.

Note that this has to be done for each repository that is to be synced.

3. As a test, check out the initial revision. Note: do not check in any changes, svnsync requires an empty destination repository

 bash-3.2$ svn co https://repo.eecs.berkeley.edu/svn/projects/chess/ActorBook/

You may be prompted to save your password:

 Authentication realm: <https://repo.eecs.berkeley.edu:443> UCB/EECS Subversion Repository
 Password for 'cxh':

 -----------------------------------------------------------------------
 ATTENTION!  Your password for authentication realm:

   <https://repo.eecs.berkeley.edu:443> UCB/EECS Subversion Repository

 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
 '/home/cxh/.subversion/servers'.
 -----------------------------------------------------------------------
 Store password unencrypted (yes/no)?

The above message occurred when running svn on the command line on a Linux machine.

See Caching Credentials for information on using KWallett under Linux. If KWallett is not set up, the consider saying "no" to storing the password unencrypted.

Mac OS X and Windows users should not see this message, the password is not stored in clear text.

4. Initialize the repository. The syntax is svnsync initialize destinationRepositoryURL sourceRepositoryURL

 bash-3.2$ svnsync initialize https://repo.eecs.berkeley.edu/svn/projects/chess/ActorBook https://source.eecs.berkeley.edu/svn/chess/ActorBook
 bash-3.2$

This command sets up properties in the destination repository.

Hint: If you get a message like svnsync: warning: W200007: Target server does not support atomic revision property edits; consider upgrading it to 1.7 or using an external locking program, then use the svnsync parameter --disable-locking.

5. Sync the repository

 bash-3.2$ svnsync sync https://repo.eecs.berkeley.edu/svn/projects/chess/ActorBook
 Transmitting file data ...............................................
 Committed revision 1.
 Copied properties for revision 1.
 Transmitting file data ..
 Committed revision 2.
 Copied properties for revision 2.
 bash-3.2$

6. Check out the destination:

 bash-3.2$ cd /tmp
 bash-3.2$ svn co https://repo.eecs.berkeley.edu/svn/projects/chess/ActorBook
 A    ojdcheck/LICENSE
 A    ojdcheck/build-jazzy.xml
 A    ojdcheck/README.rst
 ...
 A    ojdcheck/com.github.ojdcheck.jazzy/jar/LICENSE.txt
 A    ojdcheck/com.github.ojdcheck.jazzy/jar/jazzy-core.jar
 A    ojdcheck/com.github.ojdcheck.jazzy/jar/CONTRIBUTORS.txt
 A    ojdcheck/com.github.ojdcheck.jazzy/jar/README.txt
 Checked out revision 2.
 bash-3.2$

7. You may want to check out the old repository and do a diff.

8. Then move the old repository to a different location so that users do not update the old repository.

Initializing using git remote

If you have a git repository, residing on the remote server and would like to bring it in, the following procedure can be used:

1. login to repo.eecs.berkeley.edu

2. create new repository, set permissions, etc

3. Clone the original repository from the remote server

4. on command line, change directory to that repository

5. execute:

  $git remote add <friendly_name_of_remote_repository>  repoman@repo.eecs.berkeley.edu:users{projects}/<user_name{project_name}>/<new_repository>

Or (via https)

  $git remote add <friendly_name_of_remote_repository>  https://repo.eecs.berkeley.edu/git/users{projects}/<user_name{project_name}>/<new_repository>

And then

  $git push <friendly_name_of_remote_repository>  master

NOTE: <friendly_name_of_remote_repository> is <existing/original_repository_name>, and of course, new and existing repository names can be the same.

Also, there is a little more work to point local git to new remote as origin, and remove stale remote repository pointers. For help on that topic please refer git tutorial.

Repo FAQ

How do I contact someone about this facility?

Email repo-support@eecs.

How do I update this faq?

See How do I contact someone about this facility?

What is the usage policy of EECS Repo?

EECS Repo is hosted at the University of California, Berkeley, so the UC Berkeley Computer Use Policy applies. Use your common sense. Don't upload movies and music unless you have a license. Be very careful about personally identifiable information.

This site operates under the Privacy Statement for University of California, Berkeley Websites, which may change at any time.

How do collaborators who do not have UC Berkeley EECS LDAP accounts get access to a repository?

Someone with a UC Berkeley EECS LDAP account must create a repository and then add offsite users. When an external user account is created, email is sent to that address. The person who creates the repository should email the URL of the repository to the external user.

External usernames are their email address, for example user@mydomain.com. Users can control read/write access by other users for their repositories.

External account users may change their password by going to https://repo.eecs.berkeley.edu/ and clicking on "Change your password" button and then logging in.

External account users may recover their username or password by going following the password reset instructions.

How do I transfer control of a repository to someone else?

Go to Access/Notification, select your repository and add/remove users in 'Assigned users' section. Set their permission R or RW.

If you need to add user to manage your space ( all repositories), go to 'Space permission' and assign user with administrator permission. Only EECS account holders are permitted in this section.

Allow others to administer non-personal spaces?

Once you are logged in to the https://repo.eecs.berkeley.edu gui, select the space. Then use the link "space permission" on the left. Browse or type the user name you want to provide permission to, select administrator role and click the "assign" button.

Right column shows current users with space administrative rights.

Only Eecs account holders can be set as admins.

Why isn't Mercurial/scm package de jour available?

Rather than starting from scratch, we based the site on iF.SVNAdmin, which supports only Subversion. The iF.SVNAdmin package uses Subversion's path-based authorization. Kostadin Ilov extended iF.SVNAdmin to support Git.

This user interface is horrible!

The user interface is not perfect, but once you get over a few hurdles, it becomes easier. The source code for the UI will be made available and we are happy to collaborate with people who want to make changes. To get access to the source code, send email to Kostadin (kilov at eecs). The repository is at https://repo.eecs.berkeley.edu/svn/projects/research-blue/svnadmin/. To get access, send email to Kostadin Ilov (kilov at eecs)

Why can't I create a Non-Personal Space?

Non-personal space names are shared amongst all EECS Repo users. We want to avoid clutter and also manage the names so that spaces get appropriate names. When deciding whether to request a non-personal space consider the following:

Spaces are intended to hold contain multiple repositories.
- Will this work require multiple repositories?
  - If not, then consider adding the repository to a preexisting space or to your personal space, or rethink the scope of the space to a higher level context that might involve multiple projects/repositories.
  - If yes, then continue.
The lifetime of a space is usually longer than how long a student, post-doc or visitor has an EECS Account.
- Will this repository be used by others after the primary authors graduate or depart?
  - If not, then consider adding the repository to a personal space. Class projects are typically added to personal spaces.
  - If yes, then continue.
Non-personal spaces are intended to collect the related works of a long-running project, organizational unit, or group of people.
- Is there a specific, long-term, named project, OU, or group, under which this work falls, but which does not have a non-personal space already?
  - If not, then consider adding the repository to a preexisting space or to your personal space, or rethink the rethink the scope of the space to a higher level context that might involve multiple individuals doing related work over time.
  - If yes, then consider requesting a new non-personal space.

To request the creation of a new non-personal space, please use the Space Selector web page to request a new space.

Creating Spaces

When a new space is requested, email is sent to the group of EECS Repo administrators.

In general, our policy is to create new spaces when they are requested, providing that there does not seem to be a conflict or ambiguity in the naming.

If the requestor and a EECS Repo administrator are members of the same center or group, then that EECS Repo administrator should create the group. Otherwise, either Christopher or Kostadin may typically create the project, though anyone is welcome to do so.

Below is the procedure for creating a space that is to be loosely followed by EECS Repo administrators:

Decide if the space name is valid. Does the space name overlap a preexisting space, research-center, or project not related to the requestor?
Go to the Space Selector Page and enter the space name in the "Create New Space (non-personal)" field.
Select the requesting user in the --Select-EECS-User-- pull-down (otherwise you will own the new space).
Click Create Space.
Go to the Users -> Space Permissions page, find the user, click on "Show Roles", select "Administrator" and click on Assign.

Why doesn't code.berkeley.edu meet our needs?

It appears that https://code.berkeley.edu was replaced with the Berkeley GitHub. This sort of discontinuation of services points out the need for having a local, long-lived repository, as opposed to depending on things like https://code.berkeley.edu or Google code, both of which have been discontinued.

At one time https://code.berkeley.edu/ had no way to share repositories with non-Calnet users. This probably changed in 2012: CalNet Guest Status as of May 23, 2012

Why not use github or another commercial solution?

If GitHub meets your needs, then by all means, use it. Here are some things to consider:

https://github.org is free "Free for open source, Unlimited public repositories and unlimited public collaborators", Private git repos are available to edu users, but must be renewed every two years. Thus, if you have a private repo for a long term project, you may want to look elsewhere. One could pay for a private repo, but instead look at Github Berkeley. Note that if you are going to engage in a contract with GitHub, then in theory, this means getting approval for the contract. (Merely accepting the GitHub TOS probably should be reviewed by UC Berkeley Business Contracts).
Github Berkeley was set up after this service. If it works for you, then use it. However, be aware that like all services, (See code.berkeley.edu above), Github Berkeley will end some day. By having local repos, we have more control over EOL. In addition, GitHub Berkeley does not support svn.
There are files that should not go off campus into GitHub repos. Personally Identifiable Information is one area. We are also concerned about third party software. If we have software from a collaborator, they are sometimes concerned about where it is stored.
We have no control whatsoever over GitHub. People used to put source on sourceforge, but it was seen as being very slow. If github goes down, users need to hustle and update documentation and find another vendor. If EECS Repo goes down, EECS users can put a fire under someone's feet locally.
We are concerned about the version control system de jour. SCCS begat RCS begat CVS begat SVN begat Git. There will be something after git. We want a system in place where we have users and we can update the underlying version control without updating the user database.
We have two user databases: the EECS LDAP database and the collaborator database. User in the collaborator database are user email addresses. We want to use this database to manage groups of users for research centers such as CHESS, E3S, TRUST and the DOP Center. Centers have workgroups, we can use the collaborator database here as well.

Who pays for space?

Right now, the disk space is free. As disk space usage increases, we may address usage by having repositories located in project space.

Who created the EECS Repo?

Kostadin Ilov did most of the heavy work. The EECS Research-Blue Team provided feedback: Jeff Anderson-Lee, Christopher Brooks, Ubirata Chaves Coelho, Aaron Culich, Eric Fraser, Jon Kuroda, Brian Shiratsuki, Keith Sklower and Mary Stewart. The project stemmed from conversations with Professor James O'Brien.

Problems and their Solutions

svn: access to xxx forbidden

Problem:

 bash-3.2$ svn co https://repo.eecs.berkeley.edu/svn/projects/projectName/repository
 svn: access to 'https://repo.eecs.berkeley.edu/svn/projects/projectName/Repository' forbidden

Possible solutions:

Check https://repo.eecs.berkeley.edu that you actually have access to that repository
Use the --username option to specify a username. If you have been logging in using multiple usernames, then svn may end up using the username from the last svn command. Try

 svn co --username yourUserName https://repo.eecs.berkeley.edu/svn/projects/svn/projectName/repository

where yourUserName is either your UCB EECS LDAP username or an external user name that is an email address.

git push returns "Your configuration specifies to merge with the ref 'master' from the remote, but no such ref was fetched"

The very first git push per each repository MUST be in format:

 $git push -u origin master

after that any subsequently pushes can be simple: git push

git clone returns "error: Protocol https not supported or disabled in libcurl while accessing"

http://chess.eecs.berkeley.edu/ptexternal/wiki/Main/Git#Curl

git clone returns "Gtk-WARNING **: cannot open display"

See http://chess.eecs.berkeley.edu/ptexternal/wiki/Main/Git#Gtk-WARNING

git clone returns "error: The requested URL returned error: 401 while accessing"

 [cxh@joulecentos ~]$ cat /etc/redhat-release 
 Red Hat Enterprise Linux Workstation release 6.2 (Santiago)
 [cxh@joulecentos ~]$ git --version
 git version 1.7.1
 [cxh@joulecentos ~]$ git clone https://repo.eecs.berkeley.edu/git/projects/embedded/gitTest.git
 Initialized empty Git repository in /home/cxh/gitTest/.git/
 error: The requested URL returned error: 401 while accessing https://repo.eecs.berkeley.edu/git/projects/embedded/gitTest.git/info/refs

 fatal: HTTP request failed
 [cxh@joulecentos ~]$

Try adding the username to the url:

 [cxh@joulecentos ~]$ git clone https://cxh@repo.eecs.berkeley.edu/git/projects/embedded/gitTest.git
 Initialized empty Git repository in /home/cxh/gitTest/.git/
 Password: 
 warning: You appear to have cloned an empty repository.
 [cxh@joulecentos ~]$

git clone returns "error: server certificate verification failed."

The repository server (like many other departmental servers) uses an InCommon derived certificate and some machines do not include the InCommon root certificate in the default ca-certificates file. You may be able to add the missing certificate to your ca-certificates file, as follows:

 wget https://repo.eecs.berkeley.edu/svnadmin/data/InCommonServerCA.pem

 cat /etc/ssl/certs/ca-certificates.crt InCommonServerCA.pem > ca-certs2.crt
 sudo cp /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt.bak
 sudo cp ca-certs2.crt /etc/ssl/certs/ca-certificates.crt

If the above does not work for you, then try these steps below:

1. Go to https://iris.eecs.berkeley.edu/news/6499-new-ssl-certificate-for-wireless and download the Root and Intermediate certificates

2. Create a director and copy the two certificate files into it

  sudo mkdir �p /usr/share/ca-certificates/repo
  sudo cp <location_of_downloaded_certs>/*.crt /usr/share/ca-certificates/repo/

3. Edit /etc/ca-certificates.conf as root (or sudo), at the end, add

  repo/AddTrustExternalCARoot.crt
  repo/COMODOHigh-AssuranceSecureServerCA.crt
  repo/InCommonServerCA.pem

4. Run

  sudo update-ca-certificates

If you are using anything but Ubuntu, the goal is to have the two certificates included in /etc/ssl/certs/ca-certificates.crt or wherever they are visible by CURL ( which is what GIT is using for https access).

MAC users Once you downloaded the two certificates from IRIS site, you have to append them to curl-ca-bundle.crt file that CURL is using.

For Mac OS X 10.6, the default location is /usr/share/curl/curl-ca-bundle.crt:

  sudo -i
  cat /usr/share/curl/curl-ca-bundle.crt first_downloaded_cert second_downloaded cert > /usr/share/curl/curl-ca-bundle_new.crt 
  cp /usr/share/curl/curl-ca-bundle.crt /usr/share/curl/curl-ca-bundle_old.crt
  mv /usr/share/curl/curl-ca-bundle_new.crt /usr/share/curl/curl-ca-bundle.crt

MacOS X 10.7 and newer have different approach with curl certificates and utilize Key Chain Access instead.

To Do Items

Better explanation for Space concept and better communication of that idea to the users

11/9/12

Implementation or explanation why not for second ( or more) SSH keys per user

11/9/12

Documenting the correct steps to enter the SSL certs for https on client machines

11/9/12. See git clone returns "error: server certificate verification failed."

Set up a way to use svn-hooks, or at least a way to send email on commits.

11/21/12. This is under development. Until there is an automated method, to have a hook added, send email to the EECS Repo support team.