We use VisualSVN to manage our code. How do you manage SQL Schema changes in the database? Do you branch these off with each feature as well?

Thanks for the great articles!
Nathan

This has answered some of my previous questions in part 1. The key is the sync from the trunk. I usually merge into my trunk from the branch without syncing first and this caused some major headaches.

Can’t wait for the next one :)

Good question – and not an easy one to answer. I’ve been having conversations around that exact issue with my current team leads, and a few other people via email, recently. My Part 3 Strategy post will cover this topic in some detail. I’ll provide different scenarios and issues surrounding the scenarios.

this issue really is a question of ‘what is your merge strategy?” what do you merge, where and when…

I’m trying to find time to finish that post and am hoping to have it done this week.

What do you do if you land a feature in the trunk and then realize that its not ready? (Saying “that shouldn’t happen” isn’t an answer, it happens, despite the best intentions) Do you just let it hold up your release, or do you try to roll it back (if other people haven’t also landed in trunk), or disable it manually?

What do you do if you want to merge two feature branches? Suppose you originally thought these two “features” would be independent but you now need to work on them together for any number of reasons. Does SVN force you to merge along the branch lines (like TFS), so your only choice is to merge to trunk, or can you merge between “siblings” (ex: from Feature A’s branch into Feature B’s branch w/o going through the trunk)?

Thanks,
Kevin

SVN switch is your friend. I switch from trunk to branches on one local working copy as I move back and forth.

Is there any added value for having a branch per feature (the only thing I can think of now is, you can easily see what changes were needed for a feature)

instead of having

a branch per team (only works of course if the teams don’t change often). Then you could setup your CI also to this.

Best regards,
Ike

We do branch-per-feature, and we use Hudson for our build. It’s literally 5 minutes to set up a new build. yes, Hudson is Java, building our .NET app, but it’s so easy to create a new build.

All of our other mainline trunk builds and deployments are still CCNET for historical reasons.

I find this way of working to be pretty intuitive – ie: dev teams I’ve worked with in the past have just ended up working this way, there was no formal education process required.

What I find disturbing and frustrating is that it is such a manual process, and that it requires such long articles to explain to people that have not found it the obvious or intuitive way to work with source control.

Why do we need such lengthy articles to try to explain to us how to use a tool properly? I think the problem here is that modern source control is still just a glorified (and only slightly glorified) text diffing engine not much better than it was 20 years ago.

If this is the clear and obvious and most productive way of using source control, why doesn’t source control help more? Source control tries to remain agnostic of the other parts of development – managing tasks, organising iterations, releases etc. This is why we’re stuck doing stupid merges and trying to keep things up to date on a manual, text based level.

I haven’t used Git, but it sounds interesting. I also haven’t used TFS, I’ve heard plenty of complaints about it, but it’s the only source control package I’ve heard of that attempts to bring source control to the rest of the development party.

Until we have source control that actually has an understanding of the content it’s managing and can use that understanding to guide the user, we’ll be stuck doing this manual stuff and writing lengthy articles to help people find ways of using the tools that works better.

If you’ve heard of Rico Mariani’s “Pit of Success” (see http://blogs.msdn.com/brada/archive/2003/10/02/50420.aspx),I think current source control is a very long way away from this.

This is a great series. One thing I am interested in – have you tried never synchronizing from the source? If you keep your features small I suspect that this may be waste. If you have tried it, what problems did you find that led you to decide to do regular synchs?

Also, as Jim asked, how are you handling CI for each branch?