title: DVCS strategies for mixed-role small team?
body: <p>I've done a lot of reading, and have been trialing GIT, GIT Tortoise, Tortoise SVN and PlasticSCM, to find the right source control for our small team (5-10 users).</p>
  
  <p>Some background on our team: 6 copy writers/editors (2 remote), 2 developers, 2 graphic designers. We are not always working on projects together, sometimes up to 5 of us might be working on a given project. I'm unconcerned about the developers with DVCS, my concern is mainly around the other roles who are (in the nicest way) limited in their technical capability. Some of our copy writers update multiple source files (HTML, PDFs and adding concept graphics) to live, unversioned build directories (backed up as build.23.06.11.new.new.final.zip!). The copy and GD team will not have time, or to be brutally honest, the inclination to merge/resolve conflicts, or probably even remember to switch branches.</p>
  
  <p>A few SO questions have shed light on what what seems to be a fairly consistent approach - main trunk (no junk in the trunk!) with teams having their own branches, and having release branches etc.</p>
  
  <p>Every time I've re-read the links...</p>
  
  <ul>
  <li><a href="https://stackoverflow.com/questions/3854583/version-control-system-for-small-in-house-team">https://stackoverflow.com/questions/3854583/version-control-system-for-small-in-house-team</a></li>
  <li><a href="https://stackoverflow.com/questions/2658/version-control-getting-started">Getting started with Version Control</a></li>
  <li><a href="http://svn-ref.assembla.com/subversion-how-tos.html" rel="nofollow noreferrer">http://svn-ref.assembla.com/subversion-how-tos.html</a></li>
  </ul>
  
  <p>...and google in general, I still end up asking myself the same questions:</p>
  
  <ol>
  <li>Is it a Bad Idea to create role-specific branches for "trouble points" (copy team), where they can push to the repo, then our developers will merge their work into the actual project branch?</li>
  <li>Should I still try to enforce a task-per-branch for everyone else?</li>
  <li>Should I do task-per-branch for <em>everyone</em> but let the copy team create very broad tasks?</li>
  <li>Is there usually a team/group/person who is considered an "admin" role for a repo who does crucial merges?</li>
  <li>(is there an alternative suggested workflow where copy writers don't touch source?)</li>
  </ol>
  
  <p>Unfortunately, the copy teams play a vital role in updating files which in turn affect layouts and all sorts of things, on a continual basis during dev. Its not like I can keep them in a bubble until the end of a project and chuck their work in.</p>
  
  <p>... the good news is that hopefully, after a number of years, I'm ready to force everyone to move to version control! We've also settled on PlasticSCM for its intuitive GUI and Windows integration.</p>
  
  <p>The best answer to this question would try to answer the 4 points above - tackle point 5 if you like - explain weak points if possible, and provide advice, gotchyas, etc.</p>
  
  <p>cheers!</p>