SubConf is the annual conference of Subversion (Version Control System) project community. SubConf 2009 is the third such event which was held in Munich, Germany from 27-29^th October 2009. Though SubConf is a User Conference wherein subversion users from various parts of the world take part, we do have developer hackathons in which subversion core developers come together discuss subversion roadmap, hack code, etc. The developers also meet the users to get feedback about subversion and also study the user needs so that the future releases can cater to user needs. This year we had a three day conference which was a great success.

We had 10 core developers of Subversion project at the conference venue namely Stephen Butler – Elego, Stefan Sperling – Elego, Neels Hofmeyr – Elego, Julian Foad – WANdisco, Greg Stein – Popular Open Source Developer, Hyrum K. Wright - Subversion Corp, Lieven Govaerts, Bert Huijben - The Competence Group, Senthil Kumaran - Collabnet, Inc, C. Michael Pilato - Collabnet, Inc. All the core developers were locked up (Hackathon) for all the 3 days in a room in the conference hotel where they discussed about various things related to Subversion development such as Working Copy Next Generation (WC-NG) library, usage of scratch pool, iterpool in subversion code base, release roadmap, interesting issues to work on, etc. Of course hackathon was not just discussion, we also had some real productive programming done, there were approximately 70 commits to the subversion repository with close to +46696/-36666 lines of change!

The first day of the conference started officially in the evening around 7:00pm with Subversion RoundaTable where users of subversion from various organization post their queries and feedback about Subversion. They also explored the possibilities of getting a feature introduced in future releases of Subversion. This was a fruitful discussion which brings in new requirements to the Subversion Open Source project every year, directly from the actual users.

On the second day of the conference we had many talks scheduled regarding Version Control Systems. The keynote was delivered by C. Michael Pilato who is a long term (from Jan 2001) Subversion developer. He spoke on the history of Subversion, the way the community works, why CollabNet chose to make Subversion a Open Source Project etc. This was refreshing to see the legacy and the advancements that had gone through in the Subversion Community through the years! The Subversion developers would like (which also forms the message from subversion developers via the conference) the users to do real testing of the pre-release versions (we don't want you to try on production data, though) of Subversion software to catch bugs early and due to the difficulty developers face (mainly due to computing resources) in order to mimic the varied environments in which subversion is deployed in organizations. The developers are interested to hear from organizations which are interested in offering resources to work on testing Subversion and welcome any such potential prospects. The users requested accessibility for pre-release version of Subversion binaries which the Subversion community is not engaged in providing other than the source tarballs, but the developers took a note of it, that they will work on some mechanism to get it done in future. FWIW, Subversion project in the recent past has started providing nightly tarballs of latest trunk development sources - http://orac.ece.utexas.edu/pub/svn/nightly/

Some of the talks given on the second day and third day of the conference were as follows (there were even more talks, but they were non-English):

• Subversion Release Process by Hyrum Wright (Release manager of Subversion project) and Stefan Sperling

• Bringing Subversion to the Java (TM) World by Alexander Kitaev and Alexander Sinyushkin

• WC-NG (Subversion's new working copy management library) by Hyrum Wright

• Comparing Apples to Oranges – Subversion, git and Mercurial by Stefan Sperling and Stephen Butler

• Moving from SVN to Mercurial by Zsolt Koppany and Janos Koppany

• Server Side Java bindings for Suvbersion by Dave Brown

• SVN Obliterate by Julian Foad

• Coding Control by Tony Smith from Perforce Software

See http://2009.subconf.de/vortraege/1-konferenztag/ , http://2009.subconf.de/vortraege/2-konferenztag/ for presentation slides.

Another interesting take away from the conference was Subversion Community's feeling about Distributed Version Control Systems (DVCS). The community is excited about DVCS, since we are part of advancing the “State of the Art” and we are happy that, ultimately we have competitors in the version control world :) With the latest improvements on WC-NG library, Subversion will be able to get features like offline commits, shelving, etc which are premature to talk now, but are possible in the foreseeable future.

It was a nice experience for me to lurk around with the Subversion Developers at the Conference, whom I ve known for the past 2 years via email communication. We also had a surprise on the following week after the conference with the announcement made at ApacheCon 2009, about Subversion project finding a new home in Apache Software Foundation! With such kind of announcements and user conferences Subversion Community advances in a faster pace to make this extraordinary piece of Version Control software even better!

Related links

Detailed Report - Day1

Detailed Report - Day2

Detailed Report - Day3

Pictures - Day1

Pictures - Day2

Pictures - Day3

SubConf website

CollabNet TeamForge (CTF) 5.2 has been out for a while now but I thought I would help introduce the most significant feature added as a result of its release: Subversion path-based permissions.  Prior to CTF 5.2, when you wanted to manage access control for your Subversion repositories, you were able to provide only "blanket level" permissioning.  This means that you either had no access, read access or read/write access and that access applied for the whole repository.  There was no way to open up or lock down subsets of the repository tree.  For many, this was fine but often resulted in some process of maintaining multiple repositories to suit their needs.  The problem was even bigger for those that came from other solutions where they were use to full control.

Well, with the release of CTF 5.2, you now have the ability to use path-based permissions to take full control of the repository access for your project's repositories.  Once you create a Subversion repository, path-based permissions are available just like the rest of the CTF tools.  For those of you that do not want or need path-based permissions, CTF still works with blanket-level access.

(Note: The purpose of this article is not to teach you how to create a CTF integration, project or repository and assumes that you've got a Subversion repository already created and ready to work with.)

As with previous releases of CTF, to start we need to get to the project Permissions by performing the following steps:

1. Click the "Project Admin" tab
2. Click the "Permissions" menu item to the left

Now we can create a new role or modify an existing role so that we can create some new path-based permissions for our repository.  To provide a full example, we'll create a few roles:

• Developer: Has complete access to the repository except the /tags directory where he can only read.
• Manager: Has complete access to the repository
• Contractor: Has no access anywhere except /trunk/contractor and /branches/b1/contractor

(As with any CTF role, you can add individual users or you can create groups of users and then add those groups to the role.)  To get started, let's click the "Create" button on the Permissions page.  Fill out the form with the following values:

• Role Name: Developer
• Description: This role is for developers.

Once you've done this, click the "Create" button once more.  At this point, the role is created but it has no real permissions set.  Since we're here for path-based permissions, click the "Source Code" menu item to the left.  This is where the magic happens for path-based permissions.  To set/manipulate path-based permissions, look down in the "Permissions for Specific Repositories" section of this page to see a list of repositories.  (Only Subversion repositories have the ability to have path-based permissions set for them.)  To get started, click the "Path-based Permissions" radio button and you should see that a sub-form is displayed.  This is where you will add these path-based permissions.

Let's go ahead and setup the Developer role.  To do this, follow these steps:

1. Change the default permission for the "/" path to be "View and Commit" by selecting the "View and Commit" radio button
2. Click the "Add" button
3. In the newly displayed text box, type in "/tags"
4. Beside the "/tags" row, select the "View" radio button.
5. Click the "Save" button

At this point, we have fulfilled the requirements for the Developer role.  Based on our permissions model, any user with the Developer role will have full read/write access to the repository except for the "/tags" directory and everything below it, where the user will have read access only.  Below is a screenshot of what you might expect to see:

Now that we know how to create a role in CTF and modify its "Source Code" permissions to use path-based permissions for Subversion, let's quickly go through configuring the other two roles, starting with the Manager role.

To configure the "Source Code" permissions for the Manager role, follow these steps:

1. Create the role using the same steps above (The "Role Name" should be "Manager" and the description should be "This role is for managers.")
2. Get to the "Source Code" permissions for this role using the same steps above
3. Enable path-based permissions using the same steps above
4. Click the "View and Commit" radio button for the default repository path
5. Click "Save"

As with the Developer role, here is an example screenshot:

The last role we have to configure is the Contractor role.  To configure it, follow these steps:

1. Create the role using the same steps above (The "Role Name" should be "Contractor" and the description should be "This role is for contractors.")
2. Get to the "Source Code" permissions for this role using the same steps above
3. Enable path-based permissions using the same steps above (Since we'll not be giving access to any parts of the repository by default, we will not be updating the default path permissions.)
4. Click the "Add" button
5. In the newly displayed text box, type "/branches/b1/contractor"
6. Beside the "/branches/b1/contractor" row, click the "View and Commit" radio button
7. Click the "Add" button
8. In the newly displayed text box, type "/trunk/contractor"
9. Beside the "/trunk/contractor" row, click the "View and Commit" radio button
10. Click the "Save" button

Here is an example of the configuration:

At this point you have all of your roles created and you could start adding project members with their respective roles, which is outside the scope of this article.  One more thing before we move on is to explain how these permissions are used to give you access.

When it comes to generating the internal "model" of what you have access to, CTF plays by the same rules as Subversion's authorization model.  The idea here is that you can give/restrict access at any path and the permission for that path applies for said path and all paths below that path.  Sounds simple enough.  Now...to "override" a higher-level permission, all you have to do is create a path-based permission for the path you want to enable/restrict access for.  You saw an example of this in the Contractor role.  While we initially said that the Contractor role would have no access at "/", we then enabled access at "/branches/b1/contractor" and "/trunk/contractor" by creating a more specific rule and that rule applies at that path and everything below that path unless overridden by a lower-level rule.  So to summarize: Permissions for a path are inherited from their parent unless you create a new path-based permission for the path in question overriding its parent's permission.

So what else is there to learn about path-based permissions in CTF?  Well, you should know the CTF tools that path-based permissions are enforced on.  Sure Subversion access is a given but here is the full list of CTF tooling that path-based permissions impact the access of:

• Subversion access
• Source code browsing (This includes the enablement/display of the "Source Code" toolbar button, the listing of the repositories when the "Source Code" button is clicked and the actual content rendered when you click a repository and start browsing its content.)
• Commit viewer (Much like the source code browsing, when you view commit objects in the Commit Viewer, the content rendered depends on your access permissions.)
• Repository monitoring

Well, that pretty much sums up path-based permissions in CTF.  As you can tell by the information above, path-based permissions are a very simple yet very powerful way to restrict access to your source code and the CTF tooling related to source code.  If you have any question about path-based permissions or anything in CollabNet TeamForge, please visit our community site for mailing lists, forums, articles and help documentation.

One of our customers reported a funny issue with the pre-lock.bat hook script. Yes, when he used Subversion Server on Windows system. The customer is using a custom pre-lock.bat script to explicitly lock the file before every commit.

Why does he explicitly lock the file while svn commit itself locks the file implicitly? He has a valid reason to do so.

In earlier releases (v1.6), Subversion discarded the stdout messages printed in hook scripts. It is applicable for all hook scripts including pre-lock.bat script. Starting with v1.6, it behaves the same with all hook scripts, except the pre-lock.bat script. The message printed in this hook script is used as a UID for the lock. It should be unique across the repository. The best part about Subversion is that it is clearly documented in the Subversion 1.6 Release Notes.

Guess what? The customer complained that the custom pre-lock.bat script worked very well in prior releases, but it do not work with Subversion 1.6. When he performed a file commit, he faced a 423 Locked Error error. We attempted to release the lock obtained by a different user, if any, using svnadmin rmlocks and svn unlock --force commands, but they did not help. When we investigated if it has to do with any stdout messages, we discovered that NO it didn't. The hook script does not print any message to stdout.

WHERE THE PROBLEM EXISTS?

The issue is that the customer has set echo on globally in his Windows system. It prints all the commands we execute in the hook script to stdout, including the comments as in rem command.

The solution is to set echo off in his system, and he no longer faces the problem!

When you use softwares which requires a username and password to be keyed in every time you access some resource, it becomes a pain. On the other hand if that software is capable of remembering your username and password, then it is a great advantage. But what if the username and password which is remembered by this software is stored in plaintext at some location in your system? Isn't it a security risk? Of course yes, specially when you don't know that your passwords are stored in plaintext. This was the case with subversion till 1.6.0, but now we have greater security improvements to subversion 1.6 which aids us with a lot of features to avoid such a scenario.

Warn caching of plaintext passwords

From the past subversion had capabilities of caching passwords, but in systems which does not have a good method of storing these passwords in encrypted form, subversion silently cached passwords in plaintext, which was bad, since the user is not aware of this fact, specially the new users of subversion. On one fine day when they come to know about this fact, they are disappointed. So we thought of solving this in the subversion community since this was a common problem reported by many users in the mailing list. Subversion 1.6 behaves in a different way when it is about to cache passwords in plaintext, as you can see from the following sample run,

 
 $ svn co http://localhost/svn/repos wc 
 Authentication realm: <http://localhost:80> TEST SVN repository 
 Password for 'stylesen': 
 ----------------------------------------------------------------------- 
 ATTENTION! Your password for authentication realm: 

 <http://localhost:80> TEST SVN 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/stylesen/.subversion/servers'. 
 ----------------------------------------------------------------------- 
 Store password unencrypted (yes/no)? yes 
 Checked out revision 0. 
 $

Thus the user is aware that his password is cached in plaintext. What if the user decides not to store the passwords in plaintext, but don't want to get prompted each time? In such a case the user can play around with the following options in subversion servers file, ie., '~/.subversion/servers'

Globally,

 [global] 
 store-passwords = yes
 store-plaintext-passwords = yes

Per server basis, 

 [groups] 
 group1 = *.collab.net 
 othergroup = *.example.com
 
 [group1] 
 store-passwords = yes
 store-plaintext-passwords = yes
 [othergroup]
 store-passwords = no
 store-plaintext-passwords = yes 

Oh wait, all the above is specific to *NIX users, we already have mechanisms built in Subversion to cache passwords in encrypted form using wincrypt API in windows machines and Keychain services in Mac OS.

Okie, that is cool, but yet *NIX users like me are not happy, since we don't have a proper mechanism in place which stores passwords in an encrypted form. That is not true anymore, since 1.6 comes with support to cache passwords/passphrases in an encrypted form in GNOME Keyring or Kwallet depending upon the desktops they use. The password store could also be chosen with the following parameter in the subversion config file ie., '~/.subversion/config' as follows,

 [auth] 
 ### Set password stores used by Subversion. They should be 
 ### delimited by spaces or commas. The order of values determines 
 ### the order in which password stores are used. 
 ### Valid password stores: 
 ### gnome-keyring (Unix-like systems) 
 ### kwallet (Unix-like systems) 
 ### keychain (Mac OS X) 
 ### windows-cryptoapi (Windows) 
 password-stores = gnome-keyring , kwallet

GNOME Keyring

In order to enable Subversion to cache passwords in GNOME Keyring we need to pass the following parameter to the “configure” script while compiling Subversion source.

--with-gnome-keyring

The above requires GNOME Keyring libraries available in the operating system, failing which Subversion falls back to caching passwords unencrypted. Once you have Subversion binary compiled with GNOME Keyring support, the password is automatically cached in the Keyring, provided it is unlocked. CollabNet subversion binaries are compiled with GNOME Keyring support which you can use right away, to get this feature.

What if my GNOME Keyring is locked? Subversion provides a way to solve that too,

 $ svn co http://localhost/svn/repos wc 
 Password for 'default' GNOME keyring: 
 Authentication realm: <http://localhost:80> TEST SVN repository 
 Password for 'stylesen': 
 Checked out revision 0. 
 $ svn co http://localhost/svn/repos wc 
 Checked out revision 0. 
 $

KWallet

KDE users are not left alone, you can make use of KWallet in order to store passwords in encrypted form. In order to use KWallet the Subversion binaries must be compiled with the following option

 --with-kwallet

SSL client certificate passphrase caching

As we know, subversion was good at caching passwords, but it didn't had any mechanism to cache SSL client certificate passphrases, may be this was never thought, since the users were limited. The only way to avoid entering client certificate passphrases each time was to hard code it in the servers file with the parameter ssl-client-cert-pp, which is ugly! But now in 1.6 we use the same infrastructure as above to cache SSL client certificate passphrases.

 store-ssl-client-cert-pp = (yes/no )
 store-ssl-client-cert-pp-plaintext = (yes/no)

Aren't you curious to watch this in action? Here we go,

 $ svn co https://localhost/svn/repos wc 
 Authentication realm: https://localhost:443 
 Client certificate filename: /home/stylesen/stylesen.p12 
 Passphrase for '/home/stylesen/stylesen.p12': 
 ----------------------------------------------------------------------- 
 ATTENTION! Your passphrase for client certificate: 

  /home/stylesen/stylesen.p12 

 can only be stored to disk unencrypted! You are advised to configure 
 your system so that Subversion can store passphrase encrypted, if 
 possible. See the documentation for details. 

 You can avoid future appearances of this warning by setting the value 
 of the 'store-ssl-client-cert-pp-plaintext' option to either 'yes' or 
 'no' in '/home/stylesen/.subversion/servers'. 
 ----------------------------------------------------------------------- 
 Store passphrase unencrypted (yes/no)? yes 
 Checked out revision 0. 

Thus Subversion 1.6.x brings in lot of security improvements which enhances and gives a better user experience.