At CollabNet we have been discussing the differences and similarities between the Open Source community, and the Enterprise community. We want to be sensitive to that fine line between information awareness and marketing, without falling to one side or the other. Some people at CollabNet are hesitant to point to anything that costs money to the Open Source community for fear of offending, yet much of the content could indeed be very useful in shortening that learning curve.

As someone who is also helping to maintain the CollabNet site, and as Community Manager, I needed to learn what I needed to know as quickly as possible. I am not only learning to use Subversion, but I’m also learning to use the collaborative tools provided by TeamForge.You can see the tools of CEE if you look at any project on openCollabNet. We will be upgrading the site to TeamForge in the future.

Yes, we eat our own dog food, so to speak, and I’m glad. I have been impressed with the functionality and the ease of use of this platform compared to others I have used. To shorten my learning curve I have found some great training through articles, white papers, webinars, and web courses.

It is my hope that the resources I list below help to shorten your learning curve, no matter whether you want to stick with only the free materials or the ones that we charge for.

For those of you who are Subversion experts, you can stop reading here, though I value your opinion and experience and would appreciate any comments or suggestions you’d like to make. Also, some of you may not be aware of the variety collaboration tools that TeamForge provides.

Newsletters

Many bypass this option when registering for CollabNet, but the newsletter can point to useful information about learning Subversion, as well as other content you might not want to miss. You can subscribe by clicking on your user name at the top of the CollabNet site. Once in your profile, scroll down and click the Newsletter box. Or you can read the archived newsletters.

Webinars

Webinars are a great way of seeing software in action, and hearing information about the tools. Be sure to be logged into the site so you don't need to fill in any forms.

• What's New in Subversion 1.6
• Subversion Best Practices
• CollabNet TeamForge The Power of Centralization

Discussion Forums

Discussion forums are an excellent place to ask questions that fellow developers and users can answer. Be sure to return the favor by answering the questions when you can provide solutions based on your own experience. You'll need to be logged in to participate.

• Subversion for Admins
• Subversion End Users & Developers

Release Notes, Data Sheets, and Articles

We also have some good notes, data sheets, and articles. Be sure you are logged in so you needn't fill out contact information.

• Subversion 1.6
• Browsing a Subversion or CVS Repository
• CollabNet Subversion Datasheet
• CollabNet Training for Subversion

Training Courses

CollabNet offers a complete, role-based training curriculum across the entire CollabNet product line. Courses are delivered in a number of formats to best meet your education needs.

Subversion 1.5 - Individual Modules:

• Subversion 1.5 for Developers - Section 01 - Introduction to Version Control (10 min) - $28
• Subversion 1.5 for Developers - Section 02 - Introducing Subversion (19 min) - $28
• Subversion 1.5 for Developers - Section 03 - Global Revisioning and Working Copies (21 min) - $38
• Subversion 1.5 for Developers - Section 04 - Standard Work Cycle (33 min) - $38
• See More . . .

Instructor Led Courses

• Subversion 1.6 for Developers - Standard
• Subversion 1.6 for Developers - Enterprise
• Subversion 1.6 for the 1.x Developer
• Subversion 1.6 for Administrators
• See More . . .

FAQs

FAQs are probably one of the best free resources you can read for learning about Subversion.

• Subversion Client FAQ
• Subversion Server FAQ
• Subversion Migration FAQ

As I discover more resources for learning Subversion and TeamForge, I will write new blogs, and add to the newsletter as I discover.

Enjoy your Subversion learning path!

The Subversion project released the first publicly available release candidate for the 1.6.0 release on Friday Feb. 20.  You can download the source for this release candidate from the Subversion project on tigris.org.  The release notes for the 1.6 release are still being assembled but you can follow the latest state of the document from the project website.

As we did with the Subversion 1.5.0 release, CollabNet is providing binary packages of this release candidate to make it as easy as possible for the community to evaluate the release and provide their feedback.  You can download binaries for Windows and Linux right now.  We will be adding Solaris and OSX binaries soon.

Follow this blog for more entries on specific features in Subversion 1.6.  There are several new features as you can see in the release notes.  The biggest new feature is arguably the support for tree conflicts.  This will need a separate post of its own to explain, perhaps more than one.  For those that cannot wait, I can only point to the folder with the notes the developers were keeping on the feature.  Not all of those files represent what finally went into the feature so keep that in mind and keep an eye out for more posts.

The Subversion project has issued an alpha2 release on the path to the final GA. The next release might be alpha3, it might be beta1, that depends on the feedback we get from testers. One thing is certain, and that is the sooner we can find any remaining bugs, the sooner the GA release will be available.  Likewise, hearing that you have used this version with some success will also help us make decisions.

CollabNet has created binaries for Linux and Windows (with OS X coming soon) from this alpha2. You can download them from openCollabNet. There are also updated versions of the CollabNet Merge Client, Subclipse and TortoiseSVN available on this site.

We have a forum where you can post questions, comments or problems that you encounter using this version. If after some discussion a report is indeed deemed a defect, we forward the bug to the Subversion community using their normal processes. Feedback on the GUI merge clients will go to CollabNet Engineering.

A few things to be aware of:

• Subversion 1.5 client has an updated working copy format.  Once an SVN 1.5 client updates a working copy it will be converted to the new format. This means that older SVN clients will no longer be able to read these working copies. So either be careful, or be sure to update all your clients to the same version. There is a Python script that you can use to downgrade your working copy to the 1.4 format.
• Subversion 1.5 server can be used to serve an existing repository, but you will not be able to use the new merge tracking features with this repository until it is upgraded. You have a few options here:
1. Dump existing repository, then create a new repository using the 1.5 binaries and load the dump file.
2. Create a new repository using 1.5 binaries and use svnsync 1.5 binary to transfer the contents to the new repository.
3. Run a new command svnadmin upgrade to upgrade an existing repository. This runs fast as it just updates the internal repository format. There are some downsides to this approach though:
• SVN 1.5 repositories maintain a new index called the node-origins index  This is needed to speed up certain merge operations. The index will be lazy-populated on upgraded repositories, but can be updated on demand by running a new tool named svn-populate-node-origins-index(.exe). If you have a large repository you will likely want to populate the index. New repositories, or ones that are dumped/loaded or svnsync'ed will not need this.
• For fsfs repositories, the node-origins index will be slightly faster and take up less disk space if the repository is reloaded or synced. For existing repositories, the index has to be maintained in a separate set of files that takes up extra disk space and I/O.
• For new 1.5 fsfs repositories, there is a new sharding mechanism for storing revisions on disk. Instead of storing all revisions in one single directory, they are now spread across multiple directories which will be better on certain filesystems.  There is a Python script you can run to shard an exising fsfs repository though.
4. If you were using an earlier version of the 1.5 binaries, note that the on-disk format of the repository has been changed in the most recent builds. You should dump your repository with your current binaries, then install the new binaries, create a new repository and load the repository.

Please take the opportunity to give these alpha versions on the path to GA a try. Your feedback will lead to a better final release and likely also help us deliver Subversion 1.5 as soon as possible.

It is an exciting time for Subversion as its adoption continues at a dizzying pace in enterprises. I'm out there helping that adoption so I'm a bit late in posting the questions and answers I promised around the three basic branching strategies that I covered in the last two webinars in which I presented (Branching and Merging Strategies for Subversion 1.5 and Advanced Merge Tracking and Branching with Subversion 1.5). Hopefully these will be useful to many of you.

First, a quick reminder on what the three branching strategies were:

1. The unstable trunk which mimics the way that Subversion itself is developed. In this model, development is done on the trunk and a release branch is created around the time of feature completion with the formal promotion process carried out on that branch.

2. The stable trunk where development is done on system version branches and the promotion process is also conducted on that branch. The trunk is the branch point where the production releases are merged in and parallel development efforts are branched out.

3. The agile release strategy where development is done on individual feature branches and a release branch is created late in the process with the feature branches merged to it that will define that release. The formal promotion process is conducted on the release branch and the production version merged to the trunk as well as to all remaining active feature branches.

So on to the questions, first general branching questions:

I've had the pleasure of participating in two recent webinars on the topic of branching and merging particularly in the context of the pending 1.5 release with merge tracking. The first webinar, entitled "Branching and Merging Strategies for Subversion 1.5", focused on three branch and merge models. The second, "Advanced Merge Tracking and Branching with Subversion 1.5", focused on questions from the audience of the first webinar. The intent of both was to provide some practical information on a topic that has great importance in enterprises, but isn't well covered by what's generally available around Subversion.

I wanted to post some of the questions and answers that I covered in the second webinar here in our blog. I hope that they will be useful and I encourage you to view the replays of the webinars to learn more (http://www.collab.net/webinar21 and http://www.collab.net/webinar22).

Two of the questions most asked during the webinar “Branching and Merging with Subversion 1.5” were:

• “What are the differences between Subversion 1.5's merge tracking features and svnmerge.py?”
• “Will there be a migration utility?”

I’m in Munich at the moment and today attended CollabNet’s Subversion Power Workshop that precedes SubConf, the first conference dedicated to Subversion. Answers to both questions were covered during the merge tracking sessions.

Before talking about the advantages of Subversion 1.5 merge tracking over svnmerge.py, I think it is important to say that svnmerge.py has been a very useful tool contributed and maintained by Subversion community members. We are all thankful for their contributions. That said, Subversion 1.5 does offer several advantages over svnmerge.py:

• SVN 1.5 tracks merge history at a per-path level of granularity and tracks file level merges. svnmerge.py only tracks merge info for the entire branch, it does not track finer levels (e.g.: files). This allows SVN to implement cherry picking, which svnmerge.py does not support.
• svnmerge.py doesn’t always properly merge merge-properties (like svnmerge-integrated and svnmerge-blocked), leading to property conflicts when merging across multiple branches. SVN 1.5 solves this.
• SVN 1.5 includes support for third-party tools, such as call-backs for conflict resolution. If a merge conflict arises, Subversion can call your GUI client and the client can then fire up a conflict resolution tool. This improves workflow and usability. You can see the integration between SVN 1.5 merging and GUI clients in action by trying CollabNet’s new GUI Merge Client.
• SVN’s merge tracking includes more comprehensive auditing, like querying the merge history to answer questions about what was merged when and where.

A utility to migrate svnmerge.py merge tracking history from a previous version to Subversion 1.5 was committed to the Subversion trunk just a few days ago. What can it do?

• Convert the latest merge history for multiple branches. In terms of history, information about the latest merges for each of your branches is the most important information because it allows for an easier merge the next time you merge. If you want to keep things simple and only migrate the latest merge history, you can.
• The migration utility can also scan your entire repo for merge history, or accept a series of path prefixes to look at: svnmerge-migrate-history.py /path/to/repos trunk tasks branches.

We’ve uploaded a copy of the script to the download section of the Merge Tracking Early Adopter Program. You can download it and test it out on your own repository (not for production please, Subversion 1.5 is still under development). It should work well but tell us if you run into any problems. We know of one limitation: don’t run it on a Subversion 1.5 repository that already has merge history, this has not been tested yet (then again: why would you want to do that?). Right now, only the .py script is available but the Subversion developers plan to release a Windows executable later.

One of the most common questions that occurs whenever a new release of Subversion (or any product) comes out, has to do with the considerations you need to take into account before upgrading.  I will try to cover some of those in this post.

Subversion's compatibility guidelines guarantee that any 1.x client can talk to any 1.x server.  So you do not have to upgrade the client and server at the same time.  The 1.5 client can talk to 1.0-1.4 servers and any 1.0-1.4 clients can talk to a 1.5 server.

Those same guidelines say that you never have to reload a repository when upgrading the server.  You can upgrade your server from 1.0-1.4 to 1.5 and you do not need to do anything to your repositories.  The new server will silently make any updates that are needed, when they are needed.  In the case of 1.5, a new SQLite database file will be added to the repository to store indexes that speed up the new merge tracking function.  Even though you do not have to reload your repository, there are often small efficiencies you can gain by doing a dump/load of your repository.  In the case of this release, there is a new storage mechanism for fsfs repositories.  Instead of storing all of the revisions in a single folder, we now "shard" the repository by creating a sub-directory for each 1000 revisions. This does not improve performance of Subversion, but it might improve performance of things like backup utilities or other tools you use to work with the file system on the server.  In this case, you do not have to dump/load to get this feature, there is a Python script you can run that will do the sharding for you.  This script will run relatively quickly, certainly orders of magnitude faster than a dump/load.

Some features of Subversion 1.5 will require that you have a 1.5 server and a 1.5 client to enjoy the full benefits of the feature.  For example, the merge tracking feature requires that both the client and server are running 1.5.  If one of them is running a lower version than you get the merge functionality that existed in that version of Subversion.  If you want to take advantage of merge tracking you really need to update your server and all of the clients that are doing merges.  Doing a merge with an old client will work, but will not set any of the merge tracking information when the change is committed.  This simply means that someone using a 1.5 client later will attempt to merge the same info again and get conflicts.  The svn merge --record-only command can be used to fix this after the fact.

When using the new sparse-checkouts functionality it really helps to have a 1.5 server.  The feature will work with an older server, but in most cases the server will still send the extra information (file contents) to the client and the client has to discard what it does not want.

There is an important client-side compatibility feature to take into account.  Some of the new features of 1.5 such as sparse-checkouts and changelists necessitate a new client working copy format number.  So this means as soon as you perform an operation that needs to re-write your working copy (checkout/update/switch/commit/propset etc.) then the internal format of the working copy will be upgraded to the new format for Subversion 1.5.  Once this happens, you will no longer be able to use a 1.4 client with that same working copy.  The same sort of change occurred with the 1.3 to 1.4 upgrade process.  We know that this really impacted many users that were stuck using an older client, so we are including a Python script that you can run to downgrade a working copy back to the 1.4 format.  We will distribute this as an EXE for Windows users.  Just to make this perfectly clear, you can have a 1.4 client and 1.5 client on the same system.  You just need to be careful to not mix their usage on the same working copy.  Also, pure-read operations like (status/info/ls) do not update the working copy.  So simply viewing a working copy with a new version of TortoiseSVN or SCPlugin installed does not modify the working copy format.  Conversely, however, an old version of one of these tools will not be able to read a 1.5 working copy.

Hopefully this answers the questions about upgrading to Subversion 1.5.  It is going to be a great release and I certainly hope people choose to upgrade when it comes out.  If you have additional questions that I did not cover, please post them in the comments or on the Subversion Users forum on openCollabNet.

Hopefully you have already read my post from last week, Subversion merge made easy.  In that post, I linked to information on the new CollabNet Merge client that we are building for Subversion 1.5.  There has been a lot of good feedback from users who have downloaded and tried that client.

This week, we are introducing a preview of an extension to the merge client that allows you to perform merges based on change sets.  With this extension to the merge client, users of CollabNet Enterprise Edition's Project Tracker can perform merges by specifying Project Tracker artifacts as the input to the merge process instead of having to specify a list of revisions.  This is a really easy way to perform certain types of merges and can lead to some interesting new workflows and business processes.

If you have already installed the merge client, you can just visit the same installation site and grab the change set extension.  I have also written an overview of the client that has some more details and screenshots.  Click here for the overview of the change set extension.

While you will need Subversion 1.5 on your server to get the full benefits of merge tracking, the bulk of the features of this change set extension can be used today with your version of CollabNet Enterprise Edition.  So give it a try and let us know what you think.

It has been a busy few months for the Subversion engineering team at CollabNet and the Subversion community in general. As we detailed in many posts this summer, the entire team is hard at work on Subversion 1.5, specifically the merge tracking feature. 

Back in the spring we started the Merge Tracking Early Adopter Program on openCollabNet. We wanted to make it as easy as possible to get people to try early versions of the merge tracking code and provide feedback to CollabNet and the Subversion community. The program has been pretty successful and provided some valuable feedback that was incorporated into the merge tracking deliverables for Subversion 1.5. Last week we refreshed the Subversion 1.5 Beta binaries on the merge tracking site to a more recent version in order to spawn a new round of testing. If you have not already downloaded them, please download them and give them a try. It is not too late to help the community deliver the 1.5 release.

The title of this post is "Subversion merge made easy" and that brings me to an announcement of sorts. While all of the work on Subversion 1.5 has been going on, another team at CollabNet has been working on a new GUI merge client for Subversion. Today we are releasing a beta version of this client as part of the Merge Tracking Early Adopter Program. A lot of work went into this client and there are many features. Rather than listing them here, let me instead link to the documentation on the merge tracking site.  The documents explain how to install the client and give an in depth overview of its features. I encourage you to download the client and give it a try. Use the forum of the merge tracking project to provide feedback, ask questions, report problems etc. If you try the client, you will automatically also test the Subversion 1.5 merge tracking feature, which can only help to accelerate its release.

Finally, since we are talking about merge and making it easier, I just want to also mention an upcoming webinar that is being presented by two of my colleagues at CollabNet -- Bob Jenkins and Auke Jilderda. They have both contributed a lot of ideas and feedback to the merge tracking feature as well as assisted in putting together the merge tracking early adopter program on openCollabNet. Their webinar is sure to be stocked with valuable insights on branching and merging in Subversion.

Subversion 1.4.5 was released today.  You can download the updated CollabNet Subversion binaries immediately.

Subversion 1.4.5 contains a fix for a security exploit on Windows clients. This exploit was discovered and reported by researchers at the Colorado Research Institute for Security and Privacy.

The only change from Subversion 1.4.4 is the patch for this security exploit.  Since the exploit only affects Windows clients, we decided to only release CollabNet Subversion 1.4.5 packages for Windows. There is no point for someone who is already running 1.4.4 on any other operating system to update to 1.4.5.

I am not going to give a lot of details about the exploit, you can find more information at various security reporting sites, such as CVE.  I will say that it was a legitimate exposure that made it possible for the Subversion client to write files outside the normal working copy.  That being said, there are a couple of points to make:

1. Creating the exploit requires commit access to the repository.  If you can trust the people who have write access to the repository, then you do not have too much to be concerned about. The keyword in that sentence is "trust". If you are checking out from a repository you cannot completely trust, such as on a public hosting service, then be careful and update to 1.4.5 first.
2. While the exploit itself is pretty easy to produce, it is also pretty difficult to use it in a way that would cause harm.
3. You can only create the exploit from a non-Windows platform.
4. There is nothing terribly secretive about the exploit.  If you send commit emails, or even just browse your repository using svn ls, this exploit would stand out as not normal.

If you are running a Subversion client on Windows, this would include the command line client as well as any graphical client such as TortoiseSVN or Subclipse, then you should definitely go ahead and install this version of Subversion.  I would recommend that users of earlier versions such as 1.3.2 or 1.2.3 also install this update immediately. The Subversion 1.4.5 client can talk to any 1.x version of the server, so there is no reason not to update your client (for compatibility: if you have the command line and a GUI client, update them both).

Subversion servers are not affected by this exploit.  That being said, a Windows server that uses the Subversion client in scripts would still be vulnerable and should be updated to 1.4.5.