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.
- 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.
- Commit often
- Commit small chunks
- Use a consistent format for log messages
- 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
- 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:
- create the repo:
- 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
- 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
Brian talked a bit about svn:externals. The subversion people don’t really like it and it may be replaced/improved in the future.
It’s much the same as I’ll talk about on September 12 at the Webtuesday event.
You can download the presentation.