Fear and Loathing - All Comments

re: Day-to-day with Subversion

Florian Potschka — Thu, 08 May 2008 18:50:57 GMT

Thank you very much for this great article that explains feature branching very clearly! And together with the comments you get a really good picture of the two most common branching strategies. One of the best SVN tutorials I've read so far.

re: Day-to-day with Subversion

Bil Simser — Thu, 08 May 2008 13:53:33 GMT

@Cory: Moving from SVN to TFS is IMHO bad. I won't get into a holy war here about the best source control (as I don't feel is SVN is the "best" but think it's "better" than TFS). WIth TFS I have this crazy workspace/local drive mapping issue which has caused me pain and suffering. With SVN I just move a directory somewhere. It doesn't care. TFS requires me to tell the server to map my local drive to some location it knows about. And when a person leaves the company the workspace lingers and is a PITA to get rid of. Enough on that (for now).

As for SVN and CC.NET, not sure if that's worthy of an entire blog post. It's just a task in your ccnet.config file and is supported OOTB. How to track bugs and issues might be interesting and maybe I'll look at a post on Developer->Bug Tool->SVN->CC.NET or something like that.

Thanks.

re: Day-to-day with Subversion

Bil Simser — Thu, 08 May 2008 13:48:52 GMT

@Kiran: You'll pick up the deletion (or any other changes) in your daily merge from trunk. No problems there. If you're doing a *big* refactoring (like a domain shift or a massive namechange) you might want to co-ordinate with the team. Tell them the intent and talk about it (most times something like this is needed and with a good refactoring tool and unit tests you shouldn't worry). Get them all to merge up then do the change and get them to re-merge from the trunk.

re: Day-to-day with Subversion

Rob Swafford — Thu, 08 May 2008 13:40:34 GMT

Thank you thank you thank you for the step-by-step walkthrough! I've used subversion in the past, and liked it a lot, but had not been able to find as clear and concise an explanation about merging/branching/tagging best practices as this. This is going to be extremely useful in the near future, as I'm in the process of hiring a couple new devs who have limited (if any) subversion experience.

Cheers!

re: Day-to-day with Subversion

Jason Short — Thu, 08 May 2008 02:36:54 GMT

Very nice article on branching. Doesn't matter if you are using Subversion or not, the concepts are the same (and just as powerful in other tools as well, just not TFS).

re: Day-to-day with Subversion

Kiran — Thu, 08 May 2008 01:56:20 GMT

Bill,

What happens if you deleted/renamed a file in the branch in a refactoring cycle? How can we merge any changes done to that file in the trunk?

Similarly, let us say you modified the namespace names that are referenced (via using statements) in a source file in trunk. Now you are trying to merge some other changes in the same file from trunk. When you run the merge operation, SVN overrides the using statements with old ones. It would take more than 5 minutes to fix all these breaking changes.

I am interested to know whether you have any tips in addressing these issues.

re: Day-to-day with Subversion

Cory — Thu, 08 May 2008 01:06:12 GMT

What you have there is some serious complication for a rather simple problem; version control in a team environment. In my office, we've done the exact opposite; Moved from SVN to TFS.

Release branching is great idea, and makes a lot more sense than Feature branching. I like release branching, but only if you're allowing hot fixes to occur on your main/prod/trunk/whatever branch. I do release branching in TFS, allowing the occasional hot fix to go into my main deliverable. You can execute the technique you described above in TFS, also.

Next article suggestion: How to use SVN for continuous integration (for example, linking SVN to Cruise Control), and, how to keep track of bugs and known issues.

re: Day-to-day with Subversion

John — Thu, 08 May 2008 00:42:11 GMT

Release branches are the way to go and are far less work for the developer to maintain than feature branches. I only recommend feature branches if the project is extremely large and is in danger of becoming broken (or has had a history of being broken) by someone's trunk updates. Also, you can start with release branches and switch to feature branches later on in the project's lifecycle if the project size warrants it and it becomes a problem for your team.

re: Day-to-day with Subversion

David Gardiner — Wed, 07 May 2008 23:40:33 GMT

That clarified and highlighted some ways of working with version control that I hadn't properly considered before.

-dave

re: Day-to-day with Subversion

andrex — Wed, 07 May 2008 20:55:37 GMT

Thanks for perfect article!!!

p.s. I think you should swap merge screenshots :)