Subversion

iCIS has its own subversion server. You can use this to create svn repositories and define the group of users that has access to these repositories yourself. In particular this means that you can cooperate with people who do not have a Science account.

The server has a nice webdav-based solution with a web front-end which allows you to:

• Create user accounts
• Create repositories
• Manage access to repositories
• Set email addresses to get notifications of commits to a repository
• Edit your user information
• Emailing a new password if you forgot your password.

Graphical interface:

• For easy browsing the repositories and their history use for example the free foundation version of the SmartSvn GUI tool
• Note: browsing the repositories and their history using WebSVN online is not available anymore because the lack of maintainence on WebSVN which made it incompatible with the new apache webserver.

Access limitations:

• The admin functions in the web front-end are only accessible in following domains: local(131.174.142.0/24) or Science VPN(131.174.224.0/24)
• However the subversion repositories are worldwide accessible!
• Note: eduroam is different network then the local network, so you can either plugin an utp cable to connect to the local network or connect to the Science VPN network over eduroam.

The ICIS Subversion Server is available at:

  https://svn.cs.ru.nl

In order for you to get acquainted with the web front-end, we have set up a sandbox at:

  https://svn.cs.ru.nl:4432

Keep in mind that the sandbox is just meant for you to play around with the features of the web front-end. It is also a place for us to test new features so your repositories will not be safe in such a place :) Furthermore, it is not possible to migrate user accounts or repositories from the sandbox to the real ICIS Subversion Server.

If you have any problems, questions, or suggestions, please contact svn-admin@cs.ru.nl.

Thanks to Bas Lijnse and Thomas van Noort for setting up the Subversion Server.

Rule: keep the same first two version numbers for all clients

Rule

Version: 1.<mayor>.<minor>.

All clients working on the same checkout must use the same mayor version (all 1.x). (minor version may differ)
You can use any client version with any server version, so both mayor and minor versions may differ.

This means :

• if the svn server version : 1.7.2
• then having following clients is not OK :
  • client A with version 1.6.7
  • client B with version 1.7.1
• however when having the following clients it is OK :
  • client A with version 1.6.7
  • client B with version 1.6.1
• also OK is :
  • client A with version 1.7.7
  • client B with version 1.7.1

Explanation :

       http://en.wikipedia.org/wiki/Apache_Subversion
           Any 1.x version of a client can work with any 1.x server. Newer clients and
           servers have additional features and performance capabilities, but have fallback
           support for older clients/servers.
           => seems to go ok, however there is a catch :
              If you use both cmdline client and gui client
              then the older of the two cannot work anymore with the working
              copy because the newer of the two upgraded it to a new working
              copy version!! (See also next reference!)

       http://stackoverflow.com/questions/1508466/svn-client-server-versions
            Most will automatically upgrade a working copy automatically to their own
            version; so if you checkout using an older 1.4 client, and update it with a
            newer client ( eg. the latest svn 1.6); the working copy will no longer be
            usable with the older the 1.4 client.

Thus you can use any 1.x client with any 1.y server however when using multiple clients on the working copy can mess things up. Thus make sure all clients are of the same version (all 1.X).