Subversion Best Practices

This was given by Brian W Fitzpatrick – another great talk. Many apologies if these notes are a little less than coherent – there was a lot to get through, and it went fast :)

Always use one repository – except when data types (code vs multi-GB .psd
files), or access policies prevent

Authz policy – none if possible
If you don’t trust someone, don’t give them access

Can’t ever delete things from subversion

New features coming up for syncing repos

Virtual accounts viw apache ssl so you don’t need system accounts

Apache allows you to browse your repository – but is this useful?

Hook scripts – pre-commit can prevent stuff happening, but DO NOT attempt to
modify the transaction, because there’s no way for SVN to notify the client that
something has changed with what the client is trying to modify

Hooks we like –

Post-commit hooks, simple shell script that calls the hook in background ‘&’ / CIA bot

Locking/Reserved Checkouts – SVN works on copy-modify-merge. Some files are
unmergeable (.doc etc)
Don’t lock everything all the time ala VSS
Only lock non-mergeable files
Use svn:needs-lock property for communication – this is subvertable

Autoversioning is great for non-coding projects, horrific for traditional code
No log messages, potentially /huge/ spam and empty revisionss

Dump vs hotcopy – all good

History obliteration should be avoided – takes a long time, invalidates working

svndumpfilter has limitations, can cause problems, but can be used to dump
everything up to a certain revision, then importing all revisions after the
revisions to be deleted. Will still invalidate working copies

Filesystem based backend is just as fast as BDB, incredibly reliable, but
problems with BDB should be fixed soon

Encourage Code Review
Commit often
***Small, discrete chunks – no “power plants”
Use consistent log messages
Send commit mails to team

Don’t fear branches
Short-lived – task/bug-fix branches; Medium – feature branches; Long-term – release branches
Do have a release policy

No smart merge tracking – needs to be managed by humans, typically by
descriptions of merges in the log messages
Real merge tracking might come in v1.5

Standardise on one locale, or else.
All filenames and log messages stored as UTF-8

Use autoprops – the server can’t transmit them to clients
Useful ones – svn:mime-type svn:eol-style svn:needs-lock

Cool client tricks – switching to a branch in mid flight
In-place “import”

Mix & Match components
svn:externals not all that hot – not protocol independent
‘svn switch’ on empty directories

Managing a website in SVN – serve site from a working copy
Disable httpd access to .svn

$Revision$ doesn’t do what you want – use svnversion, designed to work with your
build system

Use pre-commit hook or wrapper to force code-styles before commit – svn won’t
do this

Don’t version ISO images!! Don’t lock everything in your repository. Don’t
forget to back up. Don’t commit gargantuan files. Don’t commit files one-by-one
when a single commit would do. Don’t forget a useful log message.

1 comment to Subversion Best Practices

  • Hi,

    How do you backup your Subversion repository? I am new to Subversion and looking for best practices for backups. I will be in a Windows only environment. I have read on your blog and others about svnadmin dump vs. hotcopy and also about a post-commit script to dump each rev after a commit. Any recommendations is greatly appreciated. Cheers.

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>