We are planning to develop a ASP.NET Web API project starting soon. For source control we use svn. We typically follow the pattern of the trunk being stable and doing all of our work in the branches.
Most of the time we are lucky that one developer is working on the project. For this Web API project there are at least two, possibly three developers working on different parts. By this I mean that one may be working on a set of controllers for working with document models while the other developer is working on a controller or controllers for user authentication and maintenance.
Seeing that these two should not have overlapping work what are advantages/disadvantages to both developers working on a single branch with daily “updates to latest version” to keep both working copies consistent versus each developer working on an individual branch and merging the two branches back into the trunk when they are complete?
It seems to me that a single branch would be better in that the daily updates will keep each developer up on what the other is doing and this can possibly help share code. My main concern is with performing trial and error coding. What happens when some code is committed that really probably should not be pulled down by the other developer? Should that even be a concern?
Another thought I had was that with each developer having their own branch if either developer has code that the other can use that is stable enough we merge that back to the trunk. Then the developers would update daily from the trunk instead.
Finally I had a thought that maybe we create one branch for this “feature set” and then each developer branch from that branch. They would then push stable features back to the main branch and update daily from the main branch. This would keep the trunk clean and stable until the feature set is released.
Those are my thoughts and sorry for the long question. I really want to start this project right and any guidance would be greatly appreciated.
3
Just use one branch and don’t complicate things that are simple. Configure CI server, run unit tests after each commit. Two programmers on one branch is not a problem at all. We have six programmers and there are no problems. What problems are you afraid of? I really don’t understand.
You can also read about ‘trunk development’. It says that you should not create your local branches and work on trunk instead. It works for many teams!
Seeing that the two developers should not have overlapping work, I cannot imagine what advantage there could be to working from a common branch instead of working in separate, individual branches. If the work will not overlap, working in separate branches seems like a natural solution consistent with Subversion’s design. Working from a common branch, meanwhile, seems like a recipe for daily merge conflicts, especially nasty tree conflicts. Not to put too fine a point on it, but having multiple developers work from a single branch seems to defeat the purpose of version control.
For status updates, using a tool that tracks changes in a newsfeed might be helpful. Many are available, both to set up internally and to use via a cloud-based service. These often work with or are a part of a continuous-integration system, which you might also investigate.
1
My main concern is with performing trial and error coding. What happens when some code is committed that really probably should not be pulled down by the other developer? Should that even be a concern?
Yes, it is definitely a concern. But you’re going to have that problem no matter what methodology/technology you use. Developers shouldn’t be committing “trial and error” coding – whatever that is 🙂 If you don’t want your code to be pulled down by other developers, don’t commit it.
Like Peri said – use one branch and don’t complicate things and it’ll be fine. If the code isn’t compiling/running don’t commit it.
If multiple developers work on the same branch, they have to merge changes directly to their uncommitted working copy. That means that if anything goes wrong with the merge, SVN can’t help them retrieve all the work they done since the previous commit.
Merges from multiple branches can still go wrong – in fact, each merge has a higher chance to go wrong, since you don’t have to merge on every single commit and the differences between the developers’ working copies have more time to accumulate between merges – but at least all the work is already committed so rolling back and redoing the merge is possible.