Planet JM

Tag: Subversion Client

  • Sparse Directories, Now With Exclusion

    “cmpilato ❤ sparse directories”

    If I had a dollar for every time I’ve typed that… well, you and I could at least spring for some Fazoli’s fast-food Italian. Okay, I admit that the emotion doesn’t always drive me to public expression, but that in no way diminishes my fondness for this feature.

    Introduced in Subversion 1.5, sparse directory support is one of a few features from that release (besides merge tracking and foreign repository merges) that I’ve fully integrated into my day-to-day activities. I dig organization. I tend to keep a pretty neat home directory. But I routinely work on several different pieces of software, and at any given time, I’m tracking several different development branches in each of those pieces of software. Were I not using sparse directories, my “projects” directory would look something like this:

    $ ls ~/projects
subversion/		      svnbook/		 viewvc-1.0.7/
subversion-1.5.x/	      thotkeeper/	 viewvc-1.0.x/
subversion-1.6.x/	      thotkeeper-0.3.0/  viewvc-1.1.0-beta1/
subversion-http-protocol-v2/  viewvc/		 viewvc-1.1.x/
$

    On the positive side of things, I could quickly update all my working copies by simply running svn update ~/projects/*.

    But those of you who have command-line completion as hard-wired into your habits as I do will immediately notice that so many common directory prefixes does a useless completion environment make. And not using common prefixes? Well that’s just barbaric.

    Fortunately, sparse directories has given me a whole new perspective on working copy organization. Now, my projects directory contains (gasp!) only projects, and looks like this:

    $ ls ~/projects
subversion/  svnbook/  thotkeeper/  viewvc/
$

    Those directories are sparse checkouts of the root directories of their respective project repositories. Beneath them are (at least) “trunk” directories, probably “branch” and some of its children, and maybe even “tags” with some of its children in certain cases. svn up ~/projects/* still works, and my working copy topology matches that of the repositories.

    I won’t go into the details of how sparse checkouts works here — I’ve already documented the Subversion 1.5 implementation of them in the second edition of Version Control With Subversion (which you can read at http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html). The point of this blog post is to tell you about how Subversion 1.6 improves this feature in a key way.

    In Subversion 1.6 (slated for release Any Day Now), the --set-depth parameter to svn update has grown a new value — exclude. This value tells Subversion to exclude the target from the working copy, immediately and until further notice. Prior to Subversion 1.6, if a branch I was working on was no longer of interest to me, I couldn’t easily remove it from my working copy. If I simply deleted it, it would return the next time I updated the working copy. If I svn delete‘d it, the branch remained as a local modification forever. (Unless, of course, I accidentally committed it, which brought a whole different sort of trouble to my doorstep. Angry peers. Pitchforks and torches. It was a mess — you don’t want to go there.) The new exclusion mechanism in Subversion 1.6 is the Right Way To Do It.

    Say I no longer care about what’s going on some directory of one my project working copies. Maybe I don’t care about the Subversion project’s website any more. Well, with this new exclusion feature, I can tell Subversion to remove that directory:

    $ cd ~/projects/subversion/trunk
$ svn update --set-depth=exclude www
D         www
$ ls www
ls: cannot access www: No such file or directory
$

    Done deal. When I update my working copy in the future, I will not receive any changes aimed at that www directory. If I later decide that I once again care about that directory, I can “resubscribe” to it again:

    $ svn update --set-depth=infinity www
A    www
A    www/links.html
A    www/testing-goals.html
…
A    www/tigris-permissions.html
A    www/webdav-usage.html
Updated to revision 36292.
$

    Note that if you exclude a versioned directory that has some unversioned files in it, or some files with local modifications, Subversion handles this situation gracefully. All the files that aren’t safe to delete, Subversion leaves around, and of course leaves any intermediate directories required to reach those files, too.

    I hope this enhancement serves you as well as it has served me. What do you think? How are you using sparse directories to better organize your life?

  • Subversion 1.6.0 Release Candidate available

    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.

  • Subversion Revision Graph

    This past summer, via my role as project owner for the Subclipse project, I decided to participate as a mentor in the Google Summer of Code program.  Summer of Code is a great way to bring some visibility to your project as well as build relationships with other open source developers.  One of the first things you have to do when participating in Summer of Code as a mentor organization is to come up with some ideas for projects that students can work on for the summer.  It needs to be something interesting enough to attract talented students and at the same time it ought to be something where a measurable amount of work can be accomplished in just one summer.  I came up with a number of ideas, but the one I knew someone would go after, and the one I hoped would get done, was to add a revision graph feature.

    One of the top requests I hear from new Subversion users is the desire for a good revision graph feature.  Unfortunately the way that Subversion stores information in its repository is not conducive to providing a feature like this.  Specifically, Subversion does not currently track "copy-to" information.  It can tell you the history of a given item and trace that history back through all of the places it was "copied-from", but for any given path/revision pair it cannot tell you if it has been copied to another location.  This is an essential feature to create a proper revision graph, so in order to draw a decent graph, you pretty much need to have the entire history of the repository available so that you can construct the "copy-to" information yourself.  Performance would be terrible if you had to get this history every time, so a good local cache of the information is essential.  This is a fairly challenging engineering task and therefore was one that the existing Subclipse team was unlikely to ever find the time to do.  At the same time, it was a great task for a motivated student.  Combined with the ability to visualize the information in cool ways via the rich graphical library that Eclipse provides, I knew we would attract some interest.

    We were fortunate enough to attract a great student, Alberto Gimeno.  He dove right into the task when the Summer of Code program started and did a great job delivering the feature.  I was hoping we would come out of this with some interesting code that someone else might want to pick up and finish, but Alberto was able to drive this feature to a point that it was nearly ready to ship when the summer ended.  We have just spent a few months adding some Eclipse-polish to it and integrating it into Subclipse.  Today we release it, and this is what a simple graph looks like:

    Notice that the graph is capable of showing merge information when used with Subversion 1.5.  It also contains a number of nice features made available via the Eclipse Graphical Editing Framework.  Namely, the ability to zoom in/out, export to an image file as well as the ability to navigate a large graph via the Outline view.

    This feature will be included in an upcoming release of the CollabNet Desktop – Eclipse Edition.  You can get it today via the "dev-builds" update site for the CollabNet Desktop.  Download information for the CollabNet Desktop can be found at the project home here.

    Additional details on the revision graph feature can be found at the Subclipse site.

    I would like to close by once again thanking Alberto for the work he did on this feature.  I look forward to his continued involvement in this feature and the Subclipse project.  I would also thank Google for running Summer of Code and including Subclipse in the program for 2008.