I've worked with SVN very successfully with a bunch of companies... In short: We moved to Bzr. We had some issues. We moved back to SVN.. we cry every day.
Due to a drive from the developers in my team we moved to a distributed version control system. When I say 'moved' there was a stipulation from above that we keep using SVN as the repository of record. The perceived benefits were being able to make branches easily and work in sub-features in a more controlled manner. Being an 'XP' Nutter I didn't buy this.. "Integrate as often as possible".. you hear me cry. Still.. the developers wanted it.. so I was happy to give it a go.
We looked at a bunch of distributed version control solutions (mainly looking for something fast that will still work with SVN). We picked Bazaar.
We got to use it for a few months. I never really shared a branch with anyone.. but I did like working on a branch per feature.. being able to switch branches to do the refactoring I just found I need to do before my feature can continue.. etc.
Then we hit a snag... something in the SVN/Bazaar integration would sometimes cause SVN to store the wrong meta-data and all bazaar users would stop being able to commit changes. Management didn't really like the effort it took to get BZR working in the first place, so that was it's death toll.
We moved back to SVN and working off trunk. Everything goes ok. It's not very speedy, but hay... we can deal with that.
What get's me is this... BZR makes sure you commit before you merge from trunk. In SVN, when you get latest (and haven't committed yet).. SVN will merge what it can into your unbacked up files. More than anything, that's starting to really bother me.
I find branching is nice when making large changes without breaking other team members.
E.g. we used it recently when switching from the Microsoft Silverlight Toolkit to the Telerik RadControls.
But IMO distributed source control systems like Git work better for that type of scenario than branching in SVN.
Post a Comment