Last week I attended the UK Subversion User Group meeting which was held at JP Morgan in London. It was a long way to travel from Worthing to London for a two hour session, but it was worth it.
I have rebuilt my svnmerge Windows installer, get it from here.
We were having a few problems with Subversion checkouts failing and it was suggested on the subversion mailing list that using the older version of APR included in Fedora Core 4 could be causing the problems. So we decided to upgrade to Fedora Core 6. I expected Subversion to work pretty much straight away, but I ran into a serious problem - the subversion binaries I built from source crashed Apache.
Our IT department upgraded our McAfee installation just before Christmas to McAfee VirusScan Enterprise Workstation. After they did that Subversion checkouts slowed by a factor of about 20.
Having gone through the migration from CVS to SVN and from our internal, rather onerous bug and change tracking system to Trac I suddenly find that we have lost the plot.
Having imported a lot of files into Subversion (approx. 47500) in large import batches Subversion takes a long time to return the history log. As Windows users our primary interface to Subversion is TortoiseSVN which always does a verbose log so that it can show the list of files which changed at each revision.
For me there are three packages which make up "Subversion":
If you have read my previous posts you will know that our repository is quite large and contains code for a large number of products which are made up by pulling in various bits of code, many of which are shared.
We are TickIT accredited as part of our ISO 900x quality system. This means that all changes to code have to be traceable back to either a specification or fault report. So I thought why not make ticket numbers in commit compulsory, that way all commits can be traced to tickets. This turned out to be more than a little controversial. There is an easy case and that is where a fault has been reported so there is a ticket to book the commit against. But there are a couple of other cases.
As part of our move to Subversion we have also moved to Trac for issue tracking.
We had a home grown system which had certainly grown, by the time it was killed last week it had twenty five fields per reported issue! Few people understood the purpose of more than half of them. Worse still some of the options for these fields were incomprehensible. Each field had been added with good intentions but it all got out of hand.
The issues we have had with Subversion have not been trivial to resolve. It was this e-mail on the svn-dev mailing list which helped us enormously.