title: Version control "best practice"
body: <p>I've been reading all the questions here on the subject of version control, but I don't think i found a scenario that looks like my own.</p>
  
  <p>The scenario is:</p>
  
  <p>we've got a medium/large sized web application that has (at least it should have) a core that is deployed to all clients. When we make demos of the application to the clients almost all of them request changes to the layout, or the data in the listings, or fields in the data entry forms, etc... Almost all of this changes require changes in the remaining "layers" of the application.</p>
  
  <p>In our present situation we are using CVS (with tortoiseCVS) and we dont use branches, we use tags to differentiate the code changes to the application (yes I know it's pretty bad). This brings a lot of problems when we want to make a release to a specific client, and check-in changes, etc.... To prepare a release always takes around 1-2 days of work and sometimes it still breaks.</p>
  
  <p>Sometimes, a request from a client also gets included into the core to be distributed to all clients.</p>
  
  <p>So my question is: Are branches the best way to isolate the changes to the customized client versions of the application? Should we branch whenever a new client asks for customization? Or should we treat it as a complete different project, with a different repository?</p>
  
  <p>All the different versions will have to be maintained, and as I've heard that branches are "temporary" I'm having doubts if branching is the best solution.</p>
  
  <p>Thank you for the response.</p>
  
  <p>Antonio Dias</p>