Subversion, best practice for small team of 5 developers?

Question

Hello, we have svn setup through Assembla with CI Team City. I understand source control, my team is new to it? How should we proceed with work? Right now our environment, is not organized as it should be. I am also trying to get Trac working for our group. What should we do each person work on there own branch? Merge the changes back to the trunk when they are done? Or allow them to work off the Trunk and hopefully Teamcity would catch bad stuff?

Answer 1

What should we do each person work on there own branch? Merge the changes back to the trunk when they are done?

I'm not usually in favor of this, since branch-per-developer is clunky, and it's hard for a given developer to get an understanding of what everybody else is working on this way by looking at a single branch. You could mitigate this somewhat by asking everyone to merge back to trunk with every commit, but then why have a branch at all?

Or allow them to work off the Trunk and hopefully Teamcity would catch bad stuff?

My recommendation here would be to get developer buy-in to make a team rule: everyone updates from and commits to trunk, and they run (all) the tests locally before they commit. Branches in Subversion are more effectively used for sets of features, like that corresponding to an upcoming release, rather than individual testing grounds for features.

I think your CI should be a safety net to alert you that things aren't in the state you expect them to be. But it helps if your developers understand they shouldn't be checking in code that doesn't pass in the first place.

Answer 2

Branches in SVN aren't as easy to deal with as they are in git. Therefore I am of the opinion that most day-to-day work should be done in the trunk and only large disruptive changes should occur in branches.

note: This is how we do it at my company and it works pretty well.

Answer 3

Hi skurge,

I've found myself in a similar situation we're a team of three and I've been the one pushing for source control even though my experience with it is limited and I'm learning as I go. I found this article exceptionally useful: http://www.ericsink.com/scm/source_control.html

If your team hasn't read it yet, they definitely should - it's a great starting point.

Having tried the everyone in their own branch and then merging to the trunk method, I can tell you from our mistakes that it was painful and confusing to say the least. If you're the most experienced and they're new to it, then chances are you're the one who's going to have to shoulder the responsibility of merging all those branches together...not fun.

Everyone running off the trunk has been by far the least painful way, I'd go so far to say that it's almost a joy in comparison to how we'd been operating previous to that. You all can benefit from the improvements made by each other on separate files, differences will be automatically updated and merged (unless there's a conflict). It will also let your team get used to how revision control works and slowly you'll all become more comfortable with the mechanics of it and then it'd be worth exploring branching & merging.

In short: Baby Steps :-)

It'll pay off in the long run.

Answer 4

This is how we use it:

1. All changes happen in trunk
2. Anything experimental? Branch it, work with it till you're satisfied. Merge back to trunk.
3. All major releases are tagged

Answer 5

1. How should we proceed with work? If the team is new to configuration management, your short term goal should be to let them work in a controlled manner with MINIMAL interference to their work. This means you need to split your personal configuration goals into short and long term goals. Be prepared to redefine you long term goals as the team learns!

2. Right now our environment, is not organized as it should be. A good configuration manager will always think this. The last thing you want to do is to give the perception that you prefer process over "real work" so keep moving and think evolution here, not revolution. Just like software, defining team process needs a "plan" and good communication.

3. I am also trying to get Trac working for our group. Good move. Initially, TRAC will allow your developers to see what is going on. But, it also has tickets, milestones, revision, priorities and a heap of other confusing tools that might baffle your developers. So, at first, use trac as a view of the svn timeline and a convenient diffing tool. Introduce tickets/milestones etc when they are comfortable with the toolset itself, and be prepared to never use these if they don't get/need it.

4. What should we do each person work on there own branch? Merge the changes back to the trunk when they are done? Eventually, maybe. But have you defined the problem that brancing/merging will solve for you? Remember, your team may not ever hit these kind of problems. My recommendation here is to wait until you face a problem and then solve it as a team under your guidance.

5. Or allow them to work off the Trunk and hopefully Teamcity would catch bad stuff? At first, yes. Then introduce all the good stuff you know about CM when you have problems, not before.

Remember - You're building a software product, not a great configuration management system. So, keep it simple, and only use tools/processes that let you build a better product as a team. You've obviously learned the value of configuration management along the way, so let your developers learn too. Guide them, don't force process on them. Start with the obvious stuff ("SVN lets us share the code in a controlled way") and go from there using your experience. Good luck!

Answer 6

I have used svn that way and never complained about that. I think that your strategy depends of what kind of software you are developping. In my case, it was a product used by many different customers and available for several different versions in critical environment (plant automation).

1. The trunk must always compile.
2. A tag for every release
3. All fixes and minor developments must be done on the trunk.
4. A branch for every release of a major version.
5. All major developments are done on a dedicated branch. They are merged after QA.
6. All fixes are also done on every branch of supported versions.

It may look heavy but it worked ok and it was possible to serve many users. For this kind of critical software, everybody wants to be sure of what is inside a new version.

If you don't have this kind of constraint, 1 to 3 may be enough. Working with branches is sometimes painful.

If you need to run several major projects in parallel, you may have to consider a DVCS like mercurial or git.