Looking for tips about SubVersion's best practices, branching and the social aspect [closed]

Question

My team and I currently use Perforce for revision control. We used to submit everything into trunk until one day we needed to add several items into the program, so we created a branch for my boss and a branch for me and another branch for testing. Everything works well until we tried to merge the branches back to trunk. We Visual Studio (VS) and it generates solution files that for some reason, it doesn't work well with Perforce. After a lot of effort, we partially merged the branch into the trunk. I’m thinking to move to subversion. I have Subversion in my local pc and I have no issues with Visual Studio branching and maintenances. I suggested to my boss to move to SVN. While my boss is open to the idea to move half a million of line of code, I need to build a strong case for it. I’m the youngest-recent-grad-programmer, so let say that my ideas need more beef than the others =)

I decided to install SVN in one of our servers and passed the code to it. We are not going to get rid of Perforce anytime soon, but my goal is to kill it in a very slow manner and by perverting my teammates on how easy is SVN to use and I already have one person in my boat.

Since I would be able to configure SVN from scratch, I want to apply the SVN’s best practices. I read the red-bean book and I’m planning to follow their repo’s layout and their backup tips, but I have more questions related to social and branching issues. Below are my questions for social issue,

1. Is there a way to prevent source conflicts in a social manner? If so, what is the best way to communicate about conflicting changes?

2. I’m planning to install a CMS into that server as well. So my teammates can write or communicate that they have branches and the like, but I don’t know if there other tools to track the historic health and bugs of our project.

3. Even though my company practice the flat management approach, how can a rookie like me could convince or enforce social communication to senior programmers without breaking the invisible “senior” hierarchy?

For branching and tagging,

1. I don’t want other teams to do branching to add a “Hello, World!” code into the program. I want to treat branching as something out of ordinary. Can anyone give me a rule of thumb on when to add create branch? When to merge?

2. In what case branching a branch is a good idea?

3. For tagging, my understanding is that tag symbolize a static point of the program ( ie : v1.0, v2.5) is that correct?

4. If I create a branch and start writing my changes, should my team-mates start syncing from my branch? Or should they still develop in the trunk? Or should they create another branch for themselves?

I apologize for all my questions, but when it comes to revision control, I feel that I’m swimming the gulf of Mexico during the BP cleanup.

Answer 1

In no particular order:

• Your best defense against excessive conflicts is a well-designed project. DRY code that separates concerns makes it possible to implement changes without tearing apart the entire project. If a change in core code requires updates in 50% of your source files, conflicts will be common.
• When you make a change, tread lightly. Don't refactor a function that isn't part of your change requirements just because you don't like the look of it. It's perfectly reasonable for two developers to make changes to the same source as long as they're working on different concerns. SVN merging works very well as long as you're not trying to merge the same change implemented twice by different developers. Make refactoring part of a change plan.
• Evaluate tools that sit on top of SVN and give your team another perspective on code changes. Trac and Fisheye are examples.
• Judiciously use hook scripts to send out notifications or update a project wiki. This works better than reminding people to send notifications manually. Keep in mind, if you notify too often people will ignore your notifications.
• Consider continuous integration so developers are given immediate feedback on their changes. Hudson is a nice tool that integrates with SVN. Continuous integration tools sometimes include integration to social tools as well. Hudson's build notifiers are examples.
• Branches work well for changes that don't fit in a single release development cycle or when the changes will break the project for the rest of the team (always branch versus wait for weeks to check in). Opinions differ on when to branch. Just be sure your team agrees on an approach so the results are consistent.
• Tags are used differently by different teams but by version number or release sounds reasonable.
• Only the developers working on a branch's features should work in that branch.
• Merge early and often from trunk to branch. This makes the final merge back to trunk much easier.
• As long as you're making a change, evaluate distributed version control systems like Git or Mercurial before you make a decision.