As you read this, AnkhSVN is under active development for a 2.0 release scheduled shortly after Subversion 1.5. Things have changed a lot over the last few months in the AnkhSVN world and time has come to begin showing you how AnkhSVN 2.0 will be a better Subversion client for Visual Studio.NET. While we aren't ready for a beta yet (for example, merge support isn't completely finished yet), we are ready to give you access to AnkhSVN 2.0 previews via our daily builds.

The AnkhSVN 2.0 builds are very stable already and provide a great integration between Subversion and Visual Studio 2005/2008. To get an idea of what you can expect from AnkhSVN 2.0, view our roadmap. The roadmap shows the major new features in AnkhSVN 2.0 but other things are included as well: improved usability, general bug fixes, performance enhancements and more.

Please help us with testing our daily builds; we rely on the help of the user community to ensure quality. To report defects, or make suggestions for future enhancements, catch us online in #ankhsvn on irc.freenode.net or visit the community support forum on openCollabNet.

Subversion 1.5.0-rc7 was released today.  As with all the previous milestones, CollabNet  provides binaries for various operating systems for you to try the release.

This is expected to be the final release candidate and the official 1.5.0 release should happen in roughly 10 days if all goes well.  Bugs reported on this release candidate will likely be addressed in a 1.5.1 or other follow-up release.  Exceptions might be bugs that are considered serious regressions or API incompatibilities.

Fixes included since the last rc are fairly minor.  They were mostly documentation fixes in the code and some minor bug fixes.  Probably the most significant change was to the new API for including arbitrary revision properties in a commit.  During review of this API it was decided that there was a cleaner way to implement it, and so a change was made before the release became final.  Since it is a public API, once it is included in an official release we would have to support it until the 2.0 release, and this was deemed significant enough to get it in before the release is public.  This API change also led to a number of corresponding changes in the JavaHL API and the other language bindings.

As with the previous release candidates, we appreciate your testing and feedback.  A number of bug fixes have been made since the 1.5.x branch was created that came from users who tested these early releases.

A CollabNet customer submitted the following question to us recently:

We set up mirrors of several Subversion repositories which CollabNet hosts for us. I have a question regarding the frequency of synchronization. How often should it be done? Should we synchronize often with a smaller number of changes, or only once in a while with larger amount?

As it turns out, I'd been considering this very question myself recently. The dynamics of mirror management in Subversion are interesting, so fielding this question gave me an opportunity to render some of my recent musings on the matter as text. And as there is nothing particularly unique about this customer's Subversion deployment scenario, you the reader get to benefit from the generality and (now) publicity of the response that I offered to the inquirer.

Chapter 4 of the forthcoming edition of the O'Reilly book "Version Control with Subversion" provides a good introduction to merge tracking with Subversion 1.5.  It describes the common scenario of feature branches copied from a trunk, which are then kept up to date with trunk via periodic synchronization, and at the end of their lifetime are reintegrated back to trunk (with the aptly named --reintegrate option).  If this model fits your merging needs, then after reading chapter 4 it is unlikely you will encounter any surprises.  But what if you don't follow this model?  What if you need to do some or all of the following:

• Merge to shallow working copies?

• Merge to targets with switched subtrees?

• Merge from sources which you don't have full access to because of authorization restrictions, or merge to targets missing subtrees for the same reason?

• Perform multiple merges to the same target without committing in-between?

• Merge to target, then merge to subtrees of that target?

Not to worry, in all of these cases Subversion attempts to "do the right thing", but you may encounter seemingly unusual behavior that doesn't fit within the 'synch and reintegrate' paradigm.  Key to understanding all of these cases is a knowledge of the new svn:mergeinfo property (frequently referred to simply as 'mergeinfo').

Mergeinfo is simply the history of merges made into a path.  But as with many things that can be described so simply, mergeinfo can become a bit more complex in practice.  Initially I had brave hopes of writing a reasonably sized blog post talking about mergeinfo; what it means and how it works.  Unfortunately as the page count of my draft post drifted past twenty (after cutting a lot of material out) and a co-worker began to refer to it as the "mergeinfo manifesto", we decided that it was better suited as an article - which you can find here.

So please take a look.  Even if you only ever do the simplest of merges, a quick read of the first few sections of the article and the "Parting Thoughts" section will help you in your move to Subversion 1.5.

Read the article: Subversion 1.5 Mergeinfo.

Earlier this week, the Subversion community issued an RC5 release with the latest round of fixes. As we have done with previous releases, CollabNet is providing binaries for Windows, Linux, OSX and Solaris. The CollabNet Merge client and Subclipse have both been updated as well.

Here is a list of some of the noteworthy fixes I see (in order they were backported):

• r30741
  Fix bug whereby 'svn status --depth=files' still showed some dirs.
• r30743, r30751
  Fix memory leak in recursive remote propget.
• r30776, r30777, r30779
  svndumpfilter drops mergeinfo when it is *not* run with --renumber-revs.
• r30666, r30684, r30726
  Fix for issue 3181. Compare repository UUID with working copy when opening RA session
• r30761, r30762
  Fix for issue 3172. 'log -g' fails the moment it encounters a bogus mergeinfo which claims a merge from a non-existentpath@REV1-REV2.
• r30820
  Fix pool issue which definitely can lead to assertion failures in reintegrate, and quite possibly to other mergeinfo corruption.
• r30868, r30871
  In svnserve, tolerate unreadable passwd files. Don't error over svn+ssh:// when the user can't read passwd.
• r30843
  Fix abort in ra_serf when server sends invalid xml during replay.
• r30907
  Fix for issue 3185. Fix the 'log --limit' compatability code in ra_svn, ra_serf, and ra_neon to ignore nested logs when in '-g' mode.
• r30883, r30888
  Fix issue 3187. Fix reverse merges where merge target or subtree has non-inheritable revision ranges intersecting with the merged range.
• r30931
  Remove 'blind deletion of argument to mkdir --parents', delete only if this invocation has created it.
• r30896, r30905
  Make Cyrus SASL client support DIGEST-MD5.
• r30986
  Fix potential segfault in svn_io_remove_dir2(path='.').
• r29191, r29398, r29833, r30663, r30963, r30964
  Improve the responsiveness and accuracy of 'svn log -g'.