Using Trunk / Branches and Tag structure between multiple developers

Question

I end up getting confused when it comes to Trunk / Branches and Tags. Following is my query:

We have a team of developers working on a single project. The developers are often divided in groups and they work on various modules on the same project.

Currently, we have a simple SVN system (without any Trunk / Branches or Tags) where everyone works on the same local server and commits the files. But the problem starts when, a couple of developers work on future modules (which are not supposed to go live immediately). In this situation, they cannot commit the data because if they do, their development code will be uploaded on the live server and it will end up messing up everything.

So, now I am looking for some kind of solution where, these developers can work separately but on the same code. Something like this:

Developer A is working on New Module A Developer B is working on New Module B Developer C is working on Bug Fixes of Module C (which is already on live but few bugs needs to be fixed)

So, Developer A will have it's own copy on this machine and will commit to Developer A's repository. (Or Branch)

The same logic applies to Developer B but Developer C will be working on a common stable copy which will be somewhere in Tags and once the work is done, it will be tagged and pushed to the Trunk for the upload on live server.

Once Developer A is done with the work, he will push all his files to Trunk for live upload. (This should merge some common files in trunk too). Same logic applies to Developer B.

I am not sure if SVN will be the right solution for this or not. I don't even know if there is any simpler way to implement what I want.

Any kind of suggestions are welcome.

Thanks TTR

Answer 1

my opinion firstly is that if all your devs are working on separate pieces of the project, then you can do away with branches. It may take a little organisation (eg proper log comments and versioning) but that can be a lot less hassle than branching and merging.

Ok, but if you do want branches, they're easy. There are several approaches to this, but basically all involve a 'master' version where the final code ends up. this can be trunk, or some people prefer to make changes on trunk and then merge the code to release branches. The 'trunk is master' is the easiest concept to grasp though.

In svn, making a branch is easy - its a cheap copy so your only problem is filling up a directory with the things (I recommend deleting a branch once you're done with it). SVN gives you a special kind of branch for this type of work too - the reintegration branch. It is special as SVN tracks what happens to it, its designed that you create a branch from trunk, work on it, occasionally updating it with changes that have been made to trunk, and then reintegrate all your work on that branch into trunk in one final bang. Then you can start all over again. It sounds like this could be what you want - typically though, you wouldn't have a branch per developer, you'd have a branch for each package of work.

The trouble with per-dev branches is that as a branch lives longer and longer, the changes they make will be harder and harder to merge back. This is especially true if the developers do not merge the other dev's work into their branches regularly (as they are wont to do).

As svn does cheap copies, I would probably recommend branching the entire trunk for each developer. I find that its easier to remember that instead of branching individual directories, and you'll always be able to change shared or common files without having to worry if committing them will break a different branch. (ie if you branch /trunk/moduleA and later find you need to change /trunk/include/common_file then the common file will not be in your branch as you branched a sub-set. So just branch at the root as that doesn't cost you any extra)

Answer 2

In your question, you've just expressed the basic reason behind the whole trunk/tags/branches model - it's for managing exactly this situation, which is a normal situation for a development shop to get into after a short while.

One thing to plan is your migration from a trunkless model to a trunk model.

You say you don't have any trunk, tags, branches, etc. So I assume your model looks something like this:

/
 filea.html
 fileb.html
 dira/
  filex

A word of warning - don't try to branch the root directory under itself.

eg:

svn cp / /branchA

This would result in a directory that looks like:

/
 filea.html
 fileb.html
 dira/
  filex
 branchA/
  ...
 branchB/
  ...

Unpicking what's a part of the root branch and the sub-branches becomes pretty intractable pretty quickly.

Keep it clean - move all the code into trunk first. This is the kind of structural jump that will require everyone (and all your deployment systems) to delete their workspaces and get everything from clean:

svn cp / /trunk

Now you can make your branches:

svn cp /trunk /branches/branchA

Giving you a structure like:

/
 trunk/
  filea.html
  fileb.html
  dira/
   filex
 branches/
  branchA/
   ...

Once the branches have been made, the dev's can check them out and work on them. Your deployment system can point to trunk/ instead of the root folder and deploy that.

Any devs working on bug-fixes can checkout trunk. When they commit, the deployment system will deploy their changes just as they do now.

When branchA is finished, the devs can merge the changes into trunk just as gbjbaanb suggests.

Just a quick heads up, good luck with it.