Sensible SVN Structuring
SVN, or any other version control system for that matter, should always be used when developing code. It doesn't matter if it's for a single person project, or a huge project involving hundreds of different developers. Version control is essential.
Recently I've been involved in changing the version control process for some of our projects. It's taken two attempts because as a team we made some assumptions on how everything would fit together, but the first stage made good progress, and highlighted what we thought of as being future "rare events" actually became problems very quickly.
We moved from a single repo with all the revisions in it (so it did exist initially) to a traditional /trunk, /tags, /branches setup. The idea was that the trunk would hold the live code, we'd copy that into a branch for development and bug fixing, and have a separate branch within the structure each time we needed to put things into testing environments. The trouble was there's different levels of testing environments for these projects, and it meant people were adding things into internal QA testing with it only being on their development branch.
The deployment process for these projects matches those of the client, and therefore the updates aren't controlled by SVN updates, but rather exporting changes from the SVN log, and uploading the files via FTP. With multiple developers working on the same projects from time to time, and therefore different development branches, things were being overwritten very easily.
Because there's a large number of these projects, it didn't seem like there would be much overlap of the developers, or it would be rare; until we came to the very early error in our ways. It worked initially very well, but there were a few team members of fon holiday, but was spotted as they started coming back and getting back into work. Our rare events were re-evaluated and found to be highly probable events going forward. Especially with the team increasing in size soon.
Cue a mild panic and a larger whiteboard discussion. We came to the conclusion that (and this seems common sense now) we really need a specific branch for every environment the code is in. You should too!
There will always be multiple branches under the branches folder; for development and bug fixes. There needs to be a single branch for internal QA, another one for UAT and then one for production. That's not really a lot, but when we were trying to manage it with everything in the branches structure, it got quickly unwieldy.
Fortunately we've hit these problems early on, so it was easy to correct; and also easy to do ahead of the team expanding so we can instil the process in the new starters, and sensibly manage things going forwards.
I've been really lucky to be able to head up this change in process and help make things easier for the whole team. I was also fortunate enough to spot the issues so early after the first change in structure, and to be allowed to spend the time implementing the change to save a lot of time going forward.
My lesson from this is that if you think something might happen, but will be rare, then think about how much time it will take each time it happens, and if that's going to quickly add up to more time than creating a slightly longer process to minimise that risk, do the longer work up front. That and use source control!
