I spent three days last week in Amsterdam at the ApacheCon. I never realised how big the Apache project actually is in terms of projects. Just look at the Apache project list. The conference was a bit disappointing for me, as it was way to Java heavy. That’s great for the Java guys of course, but not so good for me wearing my two hats of system administrator and frontend developer (PHP/XSLT for now).

I plan to digitalize some notes of the conference. Let me start with the subversion talk which I found quite interesting. Brian Fitzpatrick gave some of his opinions on how to work with Subversion. The slides of the talk were identical to the ones of this earlier presentation at Google.

Server

  • Authorisation is not recommended, rather you should trust your commiters. Don’t confuse that with authentication which is something different and needed of course.
  • You should not reformat or change code in the commit hooks. Mainly because you can’t notify the client about your changes.
  • Locking is possible now. Useful for files that can’t possibly be merged such as Photoshop files. And should indeed only be used in this case.
  • For example using the Apache WebDAV module you can do autoversioning (i.e. automatically check in any new file into SVN). This great for non-techies but not very useful for developers as it can generate empty commits, six commits per save operation in some cases, does not have any commit message or not a useful one.
  • I found it interesting that Google has written their own SVN data backend to sture data in BigTable.

Client

  • Commit often
  • Commit small chunks
  • Use a consistent format for log messages
  • Merging:
    • Merge tracking is currently manual and very unsexy in subversion
    • Brian is a fan of Perforce in that area.
    • Use svnmerge.py for good branch management today
    • Subversion 1.5 will have real merge tracking built in. Backwards-compatible to how svnmerge.py handles it (using keywords)
  • Autoprops: The client can automatically set properties
    • It’s a client configuration, not managed in the repository
    • Useful ones: mime-type, eol-style, needs-lock

Cool tricks

  • Switching to branch in mid-flight
    • You do some changes and realize you’d like to check them into a different or new branch
    • So now continue to do your changes
    • Create the branch if necessary
    • Use “svn switch” to switch your checked out repository to the branch
    • Local changes are preserved, you can check in now into the branch
  • In-place “import”
    • If you import a directory into subversion it’s not a working copy yet. You have to check out the repository manually again to get a working copy
    • But there is this workaround:
      • create the repo: svn mkdir URL
      • check out repo into current directory: svn co URL .
      • add all files: svn add *
      • check in: svn ci
  • If you manage a web site in subversion you can add a post-commit hook to automatically update the web site working copy
  • Use svnversion for build systems - to detect changes
  • Templates
    • Often you have a config file or something that developers must modify. Putting that into subversion control is a bad idea, because it will get checked in by accident.
    • Instead create a separate file like “config.xml-dist” and put “config.xml” into the svn:ignore property.
    • Developers then copy the template into the final destination and subversion is instructed to ignore it

svn:externals

Brian talked a bit about svn:externals. The subversion people don’t really like it and it may be replaced/improved in the future.