The way to deploy from repos in svn

Question

Hi, we are 5 developers working in an svn environment. every programmer can work on small bugs and commit whenever he wants. after the work has done, i want to give them the way to deploy to the production without considering the other programmers and their deployment. for example: while i am committing, other user is committing too but he did not finish to commit. his revisions 1,3 my revisions 2,4

if i will deploy the HEAD(4), ill also deploy his work. and i will deploy 2 and 4 i will include his files as well.

how can i free every programmer to deploy his files only?

Thanks

Answer 1

This really depends on your deployment method. If you are keeping a versioned code-tree on production, that is, you did an svn checkout onto your production machine, then the easiest way to do this is to have the programmer simply use svn update --revision REV on production, where REV is the revision that programmer wishes to update.

However, this method is prone to human error.

If each programmer needs to be uploading different versions of the program based on their own code all the time, without uploading other programmer's code, then I would set up each programmer with their own branch. The programmers can check in to their own branch whenever they want, and when it's ready to go to production, they can merge their branch back into trunk (or another release branch), and trunk can be copied up to production via svn export or svn update. This kind of process is used to guarantee that you have a working release branch at all times, and is especially useful if you have programmers that have a habit of checking in code that's not done (ie. at the end of each day).

Answer 2

What I think you're trying to do, is isolate some changes from deployment, so bugfixes can get deployed, but new features aren't deployed yet, because they have to wait for a new version.

You can achieve this by creating a release branch, and deploy from that. In this situation, all users commit their changes to trunk, and some changes are merged to the release branch.

I don't think it's useful to deploy only changes from 1 guy, because the whole idea of version control is to work together on a project, and get changes/bugfixes done together.

Take a look at Branching & Merging in the svnbook.

Answer 3

The obvious solution is to use one branch per developper and to merge to the trunk only after the work is completed. This will add considerable overhead, though. Additionally, the integration costs will go up as bigger chunks of code will be integrated.

Ideally developers would only commit finished work. But committing and integrating often is important to keep the integration efforts down.

Maybe you should consider using a distributed version control system. Developers can commit and revert their local repository as they please and push and pull after the bug was fixed.

Deploying to a production server without tagging makes me nervous.

Answer 4

You might want to look into working with a trunk and branches. In particular, it sounds like feature branching may work for you.

Answer 5

Thanks, im looking now into branching.