title: Looking for tips about SubVersion's best practices, branching and the social aspect
body: <p>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 =)</p>
  
  <p>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.</p>
  
  <p>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,</p>
  
  <ol>
  <li><p>Is there a way to prevent source conflicts in a social manner? If so, what is the best way to communicate about conflicting changes? </p></li>
  <li><p>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.</p></li>
  <li><p>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? </p></li>
  </ol>
  
  <p>For branching and tagging,</p>
  
  <ol>
  <li><p>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?  </p></li>
  <li><p>In what case branching a branch is a good idea?</p></li>
  <li><p>For tagging, my understanding is that tag symbolize a static point of the program ( ie : v1.0, v2.5) is that correct?</p></li>
  <li><p>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? </p></li>
  </ol>
  
  <p>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.</p>