Our distributed team (3 internal devs and 3+ external devs) use SVN to manage our codebase for a web site. We have a branch for each minor version (4.1.0, 4.1.1, 4.1.2, etc…). We have a trunk which we merge each version into when we do a release and publish to our site.
An example of the problem we are having is thus:
A new feature is added, lets call it “Ability to Create A Project” to 4.1.1.
Another feature which depends on the one in 4.1.1 is scheduled to go in 4.1.2, called “Ability to Add Tasks to Projects”.
So, on Monday, we say 4.1.1 is ‘closed’ and needs to be tested. Our remote developers usually will start working on features/tickets for 4.1.2 at this point. Throughout the week we will test 4.1.1 and fix any bugs and commit them back to 4.1.1. Then, on Friday or so, we will tag 4.1.1, merge it with trunk, and finally, merge it with 4.1.2. But, for the 4-5 days we are testing, 4.1.2 doesn’t have the code from 4.1.1 that some of the new features for 4.1.2 depend on.
So a dev who is adding the “Ability to Add Tasks To Projects” feature, doesn’t have the “Ability to Create a Project” feature to build upon, and has to do some file copy shenanigans to be able to keep working on it.
What could/should we do to smooth out this process?
P.S. Apologies if this question has been asked before – I did search but couldn’t find what I’m looking for.
The way we do it is that all development happens in trunk. You only even commit to trunk and then any fixes required for 4.1.1 get merged from trunk to the 4.1.1 branch. The branch for 4.1.2 is only created when testing on 4.1.2 begins – once the 4.1.2 branch is made, work continues in trunk and if any fixes are required for 4.1.2, they are made in trunk and then merged into 4.1.2.
It’s very rare that we ever make a change in a branch that needs to be merged back into trunk (or anywhere else, really).