SVN: personal branches for each developer?

tags:

branch
svn

views:

704

answers:

+12 Q:

SVN: personal branches for each developer?

I'll be honest, SVN branches scare me. The last project that I worked on which used them extensively, I seemed to spend half my time testing my branch worked, doing a dummy merge into trunk, doing a real merge - only to find someone else had just committed while I was doing this and I had to update and start over.

On that particular project, branching was done per-developer... there was a trunk and then you had your personal branch, worked on a task and merged the range of revisions back in. It seemed horrific as you had to check each time what the last revision in your branch was that you merged.

Is this paradigm actually good, and I just didn't get it since I'm not used to command-line SVN usage? Or was it a terrible system?

+3 A:

To be honest, you probably want to something else, like git.

http://git-scm.com/

brindy 2010-01-04 22:11:04

Why? It would be helpful to offer some reason that git solves this issue better than SVN.

Eric J. 2010-01-04 22:13:30

Indeed, is this just a pro-GIT piece of zealotry, or a considered response to my specific question?

John 2010-01-04 22:15:05

John, it is actually a considered answer. Git is designed for what you're doing and much more. I didn't try to explain in detail because I won't do it justice ... let point you at someone who can ... Linus Torvald on Git at Google IO - it's a long watch, but you'll see what the fuss is about.http://www.youtube.com/watch?v=4XpnKHJAok8Sorry to distress!

brindy 2010-01-04 22:20:27

Basically, git is designed so that each developer has their own branch on their local machine, which are periodically merged with the main branch upstream.

R. Bemrose 2010-01-04 22:25:36

The whole point of git is that it's easy, easy, easy to branch and merge. Every new feature I write gets its own branch. I used to use SVN and Vault, but git is so much better for multiple developers. To your question, it doesn't matter if somebody else checks something in while you're merging. git does a fairly good job of auto-merging changesets, and there will only be a conflict if they changed the same lines of code as you did, and even then resolving a conflict is fairly straightforward.

Doug R 2010-01-04 22:27:24

I don't automatically believe everything Linus Torvald proclaims is the gospel truth. For example, see *why* he thinks C++ sucks and we should stay with C: http://advice.cio.com/esther_schindler/linus_torvalds_why_c_sucks

Eric J. 2010-01-04 22:35:02

brindy, how do you know what I'm doing? I mentioned ANOTHER project used branch-per-developer as an example, I never claimed I wanted to do it. I just want to know the right way to use branches in SVN. Also, I have no intention of listening to anything by Torvald, he's an arrogant egomaniac. I hear good things about Git but most people don't know it.

John 2010-01-05 22:22:34

I'm sure you can see that my hastily added opinion is fairly well supported. It's just that your self proclaimed (and justified) fear of SVN branches, and the paradigm you describe is addressed by SCMs such as Git. I would just as readily recommend Mercurial.

brindy 2010-01-06 20:08:28

+9 A:

I have never used branch-per-developer. The idea doesn't make sense to me.

To begin with, you should align your development team so that people tend to work on different parts of the source code. If everyone is constantly editing the same files, no technology will really help you keep everyone coordinated.

SVN does a great job of merging different people's edits for those times when people do work on the same files. Write unit tests to help ensure the merged code product still works.

I use branches to maintain the currently released version of the code while developing the next version.

Eric J. 2010-01-04 22:12:22

I agree, my main issue is the nightmare of merges for a team of more than say 2 developers. Plus it is a good idea to train developers to be cognizant about other developers work and the impact of merges.

omermuhammed 2010-01-04 22:18:48

It makes sense to me, but I agree that the best way to avoid conflicts is to not work on the same files if possible.

Michael Hackner 2010-01-04 22:22:42

TFS supports a concept called "Shelving", where a developer can store their work back on the version control server at the end of the day without actually checking in. It's somewhat a convenient feature, and eliminates the "I haven't checked in yet" problem when your laptop catches on fire. (I'm really not a fan of TFS, but that particular feature is quite nice).

Seth 2010-01-04 22:30:05

I have not worked with TFS much but that does sound like a very convenient feature. Can you also diff vs. a shelved version?

Eric J. 2010-01-04 22:38:43

I can see the "branch-per-developer" approach being helpful when you have several developers working on several different features and one of them isn't ready to go with their feature but you still want to publish the other features that are ready. You could say "don't check it in if it's not ready", but then you have the issue of one developer checking out a bunch of files and making it difficult for other developers to work on those files if need be. However I definitely agree that going branch-happy is problematic as well.

Adam 2010-03-11 19:11:14

The problem with merging right into the trunk is that you don't know if your change is going to work everywhere, or if it relies on something specific to your machine. Using a developer branch I can check in, have my build server build my branch, check it out on my laptop and test my changes, all without killing the trunk if something breaks. I'm using Perforce, where merging branches is no harder than checking in code, so SVN may not make it worth it.

tloach 2010-05-21 19:55:05

@tloach: How bad this is depends on your team model. In a distributed (e.g. open source) development team I see that being a major issue. My team sits within shouting distance of each other, and this is actually a good thing as we very quickly resolve any issues. The CI process lets us know about 95% of issues right away and another developer speaks up if something breaks things in his environment. I just don't see how release management gets easier if everyone were using their own branch. First getting things synced into individual branches then into the trunk seems more error prone.

Eric J. 2010-05-23 16:45:12

+1 A:

The problem with developer branches is not the branches itself but (as you wrote yourself) merging. Unfortunately merging is still a pain with svn. While developer branches do make sense the tool is the problem. I'm using git (with git svn) since a while now and developer branches just become natural because the support for merging is way better -- you can just merge, and while merge conflicts still happen they are (from my experience) happening much less and are much less painful.

bluebrother 2010-01-04 22:13:41

+5 A:

It seemed horrific as you had to check each time what the last revision in your branch was that you merged.

I just wanted to point out that you no longer have to do this: SVN 1.5.0 and up support merge tracking.

Michael Hackner 2010-01-04 22:16:56

+7 A:

Per developer branches are a valid paradigm. The primary benefit I found was they allow you to check in work in progress and therefore get it backed up, accessed by others in case you're off ill etc without upsetting the main trunk.

Branches themselves are not really an issue, the problems are managing the merges. What I've done in the past is use a merge token (soft toy or action figure works well - he who holds the token can do the merge to trunk) or have merge queue on the dev wiki, basically have only one dev merging into trunk at a time.

Paolo 2010-01-04 22:17:21

I'm pretty sure I don't like the idea of using a version control solution to solve a backup problem. You have a good point about people being out of the office, but I'd still rather see that solved without a commit solely for the purposes of backup/availability.

Chris 2010-01-05 15:32:39

Lol, your merge token is basically like using Sourcesafe "hey, can you checkin file123.h, I need to make changes"

John 2010-01-05 22:24:43

@Chris I actually think version control can be a very helpful form of backing up because it maintains the history in a central location. The trouble with using a different tool to do backup along with source control is that you now have two different history time lines and that can get confusing when finding the correct version of the file to revert back to. If you're branching strategy is sound then you should be able to check in a buggy file (assuming no compilation issues) for backup purposes to a branch that isn't claiming to be "ready for prime time" yet.

Adam 2010-03-11 19:22:39

+2 A:

I've been working with CVS and SVN for almost 10 years and using branch per developer scares me too :).

All teams in which I was working used trunk for daily development and branches for frozen/beta/release version (sometimes large new, independent features were implemented in the separate branch).

Branches were merged back to trunk by one of developers (SVN) or by author (CVS).

And because merge as daily practice since Subversion 1.5 is easy there should be no problem to do a merge.

Grzegorz Gierlik 2010-01-04 22:20:29

+3 A:

The main benefit, as I see it, from having a branch per developer is that you can institute a policy of frequent checkins - certainly having everyone checkin code every night - regardless of the state of their code as they won't break anyone else's build, let alone the main development line.

This means that you have a nightly back up of peoples work, and it's easier for the developer to revert back to a (partially) working version of their development if they make a mistake or hit a problem with their implementation of an algorithm.

It will also ensure that only fully approved and tested code (assuming you are doing code reviews and unit testing) gets checked into the main line.

I agree that the merging overhead could be onerous, but if everyone is constantly (well at least a couple of times a week, preferably once a day) integrating from the main line to their branch the impact of merging from the developer branch should be minimal.

ChrisF 2010-01-04 22:22:48

+1 A:

If you really need to do per-developer branches, you should really use Git, it is designed from the ground up to manage every developers "working copy" as a repository of its own and merging is built into the core of it.

fuzzy lollipop 2010-01-04 22:23:42

or Mercurial, or Bazaar.

jpartogi 2010-01-04 23:09:48

Try using Mercurial. It does not have central repository by design.

There are no commit conflicts too, because there is no push.

George Polevoy 2010-01-04 22:29:09

I've used a similar branch strategy in SVN on my last teams (small teams: current is 4 devs large) and have adopted the approach in TFS on my current team.

We branch per bug tracker work item.

This strategy provides the branch-per-developer benefit of an isolated source control environment for the developer where (s)he can bang away on code, revert, etc. using the luxuries SVN provides but never allows the developer to drift too far from the mainline in trunk. The development of long-standing features outside the trunk is quite discouraged. The idea being reinforced by stressing that the intended scope + duration of a bug tracking work item should not significantly exceed one business day.

In practice, I've found this results in small changesets being merged into the trunk fairly frequently. Given the small nature of my teams, we're rarely stomping on each others' feet getting a merge down so conflicts aren't typically problematic.

I will say, this system was quite comfortable in SVN: less so in TFS which doesn't seem to handle merges as gracefully as SVN 1.4 even, let alone 1.5+.

antik 2010-01-04 22:29:57

-1 The developer overhead for merging must be horrendous in this scenario. You seem to be trying to co-opt SVN to work like a distributed version control system like HG/GIT.

Ben Aston 2010-08-10 10:06:07

+6 A:

With Subversion, I use "work branch(es)" which are owned by a team and shared by all members of the team as described in the great Version Control for Multiple Agile Teams article and illustrated below:

alt text

I warmly recommend to read the whole paper, it's really worth the read.

With something else than Subversion, I may consider using "feature branches" but, to be honest, I don't see the point of personal branches per developer (and it doesn't make sense to me to go beyond the granularity of a feature).

Pascal Thivent 2010-01-04 22:49:13

Some places have a feature per developer...

TofuBeer 2010-01-04 22:58:03

@TofuBeer Your point? Feature branches would work in such places so I'd prefer to call them, well, feature branches. Even if the result is similar, the message they convey is really different: unlike developer branches, feature branches don't disallow collective code ownership in which I believe. No, really, I don't like the concept of developer branches and it doesn't make sense to me.

Pascal Thivent 2010-01-05 00:40:17

Upvoted for diagrams and a great reference.

Ether 2010-01-05 00:41:31

how do you stop merge problem with refactings that effect classes both teams work with?

Ian Ringrose 2010-02-10 10:28:36

+3 A:

I've used a similar practice in the past.

If multiple developers are all updating the same code files, it may not be a version control problem. I don't know anything about your code, but could it be that its too monolithic and not modular enough? That way, when the assignments are doled out, the developers are not always stepping on each others changes.

37Stars 2010-01-04 22:51:57

Good point about the code structure.

Michael Hackner 2010-01-05 02:14:45

Your paradigm needs to fit the affinity of the tool. Subversion is the wrong tool for that paradigm because merging in Subversion is a PITA. Change your paradigm or switch to Git or Mercurial.

dpurrington 2010-01-05 13:54:15

We use a single development branch for most day-to-day operations. We've learned through experience that when one developer is working on a really large project that expands multiple modules, he should create his own branch and work from that. Otherwise, we haven't had any problems running from a single svn branch, and it greatly simplifies things. Caveat, we have a small team of 3 developers + the occasional contractor.

gabrielk 2010-01-07 05:30:06

ansaurus

tags:

views:

answers:

SVN: personal branches for each developer?

related questions