SVN introduction

Question

I'm working with other developers using SVN. I'm new on SVN and I would like to understand better how is the best to use SVN.

At moment we have:

                            __ branch developer 1
Project 1                 /___ branch developer 2
      |                  /____ branch developer 3
      |____ branches---- \____ branch developer 4
      |                   \___ branch developer 5
      |____ tags           \__ branch developer 6
      |
      |____ trunk

They asked me, before start to develope, to:

Update my Branch
Merge my branch from other branches and solve conflicts, so I have to merge from dev1, dev2, dev3 and so on... Commit my works

Now, my question is... is this the right approch? It takes a lot of time to do so many merge... every time. Or we should use only one branch for all developers ? I'm really new on SVN and I don't want do something wrong... so I'll really appreciate you help to put me on the right way.

http://stackoverflow.com/questions/34975/branching-strategies — Kinjal Dixit, Jul 05 '12 at 09:20
http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html — Kinjal Dixit, Jul 05 '12 at 09:20

score 3 · Answer 1 · answered Jul 05 '12 at 09:31

No, it's not the right way to use SVN. There's no reason for every developer to have its own branch.

Typically, everybody works on the trunk. If some feature is long to develop and must not be done on the trunk to avoid disturbing the other developers, a specific feature branch is made. Changes from the trunk are regularly merged to this feature branch, and once the feature has been developed completely in its own feature branch, the branch is reintegrated into the trunk, and deleted.

If everybody has to constantly merge from everybody else's branch, it's no different than working all on the trunk, except it's much more painful. And it doesn't scale to more than 2 or 3 developers anyway.

I suggest reading the freely available SVN book which explains all of the above in details, and discussing with your coworkers to make them adopt the traditional best practices.

Thanks JB! I was really confused about our strategy.. and you are confirming my doubt: merge contantly many branches is like to work in a single trunk... I agree! Thanks! Now I would like to ask to 'stack' how extend a day to 48 hrs :) — Uncoke, Jul 05 '12 at 09:59

score 2 · Answer 2 · answered Jul 05 '12 at 09:38

I personally think that the current implementation above is insane. At the moment there are 7 branches (one for each developer), each one requiring seven merges before any work can be started.

As soon as more developers are added in to the team, the merging strategy becomes incredibly cumbersome and prone to more errors. You run the risk of having to edit conflicts in X number of branches before you can even start development yourself.

I would get every developer to work on the trunk of the repository. It's easier to manage conflict resolution and merges when dealing with just the one repo directory.

Ideally you want to work in an Agile workflow (small bite-size manageable chunks of work) that will only take a few days maximum to complete. Any projects longer than that could potentially deserve their own branch folder, purely to separate the code and extensive refactoring from the trunk so as not to disrupt the workflow of the rest of the team.

Once that large task has been done, you only then have one branch folder to merge back in to the trunk (which has been constantly updated by the other developers as their work has been completed).

Source control systems should be used to make development workflow easier, not more complex.

Thanks, you are confirming my doubts. I agre with you. – Uncoke Jul 05 '12 at 09:56 — Uncoke, Jul 05 '12 at 09:56

score 0 · Answer 3 · answered Jul 05 '12 at 10:23

I agree with the others that your strategy currently is insane! ;)

Personally, I'd prefer to keep the trunk as the stable 'live' version, and keep all development to one branch, that way all developers work on the same branch, you only have to merge when your feature or project is ready to go live, and you know the trunk hasn't changed since you branched.

Whilst the options above will work, I would worry that you have to keep updating branches every time something changes on the trunk, and you increase the possibility of conflicts (and broken sites/products if the trunk is live code).

eckes · Answer 4 · 2012-07-05T11:01:43.620

Like the other answers tell you: this approach is simply braindead. You'll waste your time merging from different branches before you could finally commit your work.

Apart of this: if you want to split up things for every developer, why not use a distributed VCS like mercurial or Git?

If you have to learn SVN (and are not yet spoiled by), you could learn mercurial or Git too. And there are good reasons to switch over.

I dropped SVN for Git two years ago and didn't regret it a single day. Instead, I enjoy cheap branching, working merges, rework commits before they go into master and all that.

Everybody works locally, when it comes to merge things back into master (aka trunk in SVN), the devs merge and then push to a central repo. You don't have to waste any thought about which-developer-shall-work-on-which-branch.

Regarding branching, there's one quite popular article about A Successful Git Branching Model here: http://nvie.com/posts/a-successful-git-branching-model/

Maybe you could convince your colleagues that switching over would be a real benefit for their work. I'm working with one that insists on manual merging even although we're using Git. It takes us 2 to 3 hours every week to sync our work. The work of only two persons. If you'd be merging from more, it'll take a lot more of time that could be used better.

SVN introduction

4 Answers4