views:

69

answers:

2

Until now, I was always working on my own for PHP-projects, but at the moment I'm working in a small team (2-3) persons on those projects. Accidently, we did some overwriting of work from the others ... To prevent this, we thought of setting up a SVN-repository, so at least every version is stored in a safe place.

Technically, the SVN is running smoothly n we've got a Trac-install to do the tickets and stuff. Now we're struggling with how to use the svn best in a practical point of view...

  • How to branch?
  • How many commits? Every day? hour? I've read: Commit often, commit early
  • How to move the latest (hopefully best) code to the live environment?
  • ...

I've been reading on the internet, but they fast move into the technical aspect and I'm looking for the practical one. Do you have any tips where to start reading? Or tips to start.

Thanks!

+1  A: 

The best approach seemed to be if you think your code is more or less read you can start a release branch (Feature Freeze) and do only bug fixing on that branch. After some time you recognized there no bugs found for a time and than this can be delivered to a customer not to forget to tag this state. The release branch can be put on a "Test Environment" and after done you can transfer this to the live area or make some kind of delivery (tar.gz / zip archive or whatever) to the customer. Commit often is a very good advice (as mentioned) with the suggestions made. BTW: I would suggest to use Redmine instead of trac cause it's supports many projects etc. with a single installation.

khmarbaise
A: 

in my workgroups we only commit working code, NEVER EVER something that doesn't work.

In general we commit regularely, e.g. every day or every friday and on demand.

poeschlorn