1

We are in a transition from source control Clearcase to SVN and we cannot find a similar workflow in svn as we had in Clearcase.

In Clearcase we had one integration view from where the builds were done. Each developer also has its own "developer view" where development is done. Periodically (when some work item is done), code from dev views is delivered into integration view. Then both views were synchronized together and we were good to go. The "developer view" can be used for years in this scenario.

We try to achieve the same workflow in SVN using branches but we are having the following problem:

  1. If, as mentioned in the svn doc, we merge into the trunk using the --reintegrate flag, our branch become useless and need to be recreated. It is not pratical, especially when using Eclipse (we do not want to recreate our workspace or even deleted the "old" project because the launch configuration is lost).
  2. If we merge without that option, we end up, few commit/merge later with various unexpected conflict like "local obstruction, incoming add upon merge" even if the file was added only once.

So my question is how can we have one branch per developper? If it is not possible, how do you work with Eclipse, SVN and branches. One last thing, we want to keep the trunk pristine, so working directly in the trunk is not and option :-)

Thanks for your insight,

-Martin

wohlstad
  • 12,661
  • 10
  • 26
  • 39
Martin
  • 261
  • 3
  • 12
  • Why do you have one branch for developer? What happens if you have 20 developer in your team? And how much time you spend to merge all changes coming from several different branches? The way you are doing does not sound a really nice way of doing it? – fmucar May 17 '11 at 21:51
  • See also http://stackoverflow.com/questions/1567135/clearcase-issue/1567308#1567308 on the "one branch per developer" theme ;) – VonC May 18 '11 at 04:08
  • @fmucar: one branch per dev allows them to work on their stuff "idependently" and then merge the code in the main (trunk) once they are done. After a dev delivers its stuff in trunk, the trunk and the dev branch should be identical. Each dev is responsible to do ttheir own merge (trunk->dev and then dev->trunk). It scales well and it is not very time consuming. One can argue that create one branch per bug/work assignment is also time consuming (and it is hell with eclipse). – Martin May 18 '11 at 12:27
  • @VonC: I understand the situation described there. In Clearcase, we had one view per dev (as the solution suuggest) and this is the kind of workflow I try to reproduce in SVN (without sucess so far: merge problems). – Martin May 18 '11 at 12:30
  • @Marin: you will always have one view per dev with ClearCase UCM (and/or base ClearCase). But all those views can reference one Stream or a few Streams per development efforts, not necessary one Stream per developer. One view per developer will translate in SVN into one workspace per developer. – VonC May 18 '11 at 12:32

1 Answers1

2

Generally, a branch per developer is frowned at and is definitely not the recommended flow in SVN. In DVCS like Git, Hg, developers can have local branches to work on and such branches are cheap. Maybe you can consider using git-svn or even shift to Git / Hg and have less painful merges.

manojlds
  • 290,304
  • 63
  • 469
  • 417
  • I began to understand that what I'm trying to achieve is not the recommended way, but I would like to know if it is at least possible, as if it is, how can I do it. How should I merge the branches and/or how should I massage them after merges to avoid conflicts in subsequent merges. – Martin May 18 '11 at 12:34