Close

April 17, 2013

SVN – how we do it

This is a post regarding how svn is being used at my workplace. First, some background and the reason we moved to this format. I was working on a project and I had everything checked in on svn in the trunk and things were going great. Then another developer started working on some new development on the same project and committed all changes to the trunk. Still things were going great (I suspect some of you already knows where this is going).

Then I needed to make some changes to the code that is active on the production server. We were not allowed to take over any of the new development and some changes were at a level where rolling back was not an option. Things not so great.

This is only on one of my projects where the developer did not create a branch to do the new development in and it is the reason we created a set standard when working on any development, going forward.

The Structure

  • branches
    • QuickRelease
    • FutureRelease
  • tags
  • trunk

The standard structure of three folders, trunk, branches, tags will be used in all development. Additionally all new development that needs to be done will be done in one of two branches, `QuickRelease` or `FutureRelease`.

The Process

Any changes that can be done in less than a week but will take more than 4 or so hours, should be done in the `QuickRelease` branch. Any development that will take more than a week, should be done in the `FutureRelease` branch. Any changes that is minor, i.e. a spelling change, extra space, a new image, etc. can be done in the trunk. This is left to the discretion of the developer, but that is about the guides that I use.

After the development in the `QuickRelease` branch has been completed, it will be merged with the trunk and the `FutureRelease` branch, this is to ensure less merging when you merge `FutureRelease` to the trunk.

You should only merge after you have committed your last changes and the client has signed off on the branches’ code. This is just to prevent that you have to merge before the client is happy and that scenario stated earlier comes back to life. After the final commit, `switch` over to the trunk and commence the merging. I find it is good to have someone sit with you on this step if there is a lot of merging going on. Remember though to always do a dry test merge, to see what issues you might run in to.

That is it. This structure and process will be used in all projects going forward. I for one am very happy that the company has put down formal `rules` to using SVN. To let it over into the hands of each developer can be a huge mistake, as my story told.

Fixing our repositories

We started the process to fix all repositories for our current projects so the trunk of each repo will be the code that is available on our production servers. It is a simple process actually and our IT department is taking care of most of it.

  • the repo is checked out to a folder.
  • all files are deleted and the change is commited (essentially giving you a clean repo)
  • the code on the production server is downloaded into the folder.
  • the downloaded files are committed to the repo with a comment stating the change and who did it.

3 Comments on “SVN – how we do it

Jeanette
April 17, 2013 at 4:34 pm

7FD for President! 😀

Reply
Stephan
April 17, 2013 at 4:36 pm

Thanks 🙂

Reply
Source Control Revisited | 7Foot Developer
January 9, 2014 at 11:26 pm

[…] ← SVN – how we do it January 9, 2014 […]

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *