2

My development team recently doubled in size from one (myself) to two. As the sole developer, I was maintaining the trunk as the stable version of our software. I'd make changes in my working copy, test, and only push to trunk once I was sure it was stable.

With the new team member we are trying to come up with the best flow for co-developing the codebase. We have decided that trunk will stay stable; changes are pushed there only after code review and thorough testing. The teammate will create feature branches for features he works on; when he requests a code review, I will do it and then once approved, he will merge the branch into trunk and delete the branch.

We are both using eclipse and the subclipse plugin to manage our working copies.

The problem is that while I can view differences between my working copy and his branch (Team -> Compare To -> Branch), I do not know how to get the code from his branch to merge with my working copy. I want to be able to get his changes without losing any local changes I have made, run his code locally, and have none of this affect trunk. That seems to rule out the option in Eclipse/SVN to switch to another branch/tag/revision, since I need to have his code merged with mine (in order to make sure my working copy's code is consistent with my local database).

We've looked at the SVN Patch feature, instead of using branches perhaps he should send his changes over through a patch which I run?

So the concrete question here is: how do I merge/incorporate changes from a branch with my working copy without touching trunk? I would also be grateful to get suggestions on how we should implement our workflow in a way that takes advantage of the power of svn and eclipse in a way I am missing.

Neil
  • 7,042
  • 9
  • 43
  • 78

3 Answers3

3

Both of you should have checkouts of trunk and any branches you're both working on. When he is ready to have his branch merged into trunk, you should:

  1. Ensure that his branch builds successfully.
  2. Ensure that your trunk checkout is pristine (no SVN added, modified, deleted, unversioned or ignored files).
  3. Conduct the merge, resolving any conflicts with his help.
  4. Perform a code review, including ensuring that trunk is stable with his changes.
  5. Commit the merge.

Conduct the merge outside of Eclipse, using the SVN command-line. I've seen enough questions here on SO related to Eclipse and Subclipse that tells me the plugin is unreliable.

If it was me managing this workflow, I'd have two checkouts of trunk: one which is meant for merging and is always in a pristine condition, and another in which I can actively develop. That way, I wouldn't need to create a patch of my changes, then merge, then apply the patch.

Hope this helps.

Sameer Singh
  • 1,358
  • 1
  • 19
  • 47
0

The sad truth is that SVN will probably not be fit for this pattern. Branching creates a lot of pain in Subversion Check here to get more details.

Community
  • 1
  • 1
Jesko R.
  • 827
  • 10
  • 21
0

It was enough for me to update the branch from command line with 'svn up'.

flm
  • 960
  • 8
  • 14