When using Subversion, should developers be working off the trunk or should the trunk be only used for merges from each individual developer's branch and watched by a continuous integration service?
+17
A:
Depends on how extensive the changes are. A general good practice is that trunk should always be compilable, but that doesn't necessarily mean developers can't work on the trunk for small changes/bugfixes - after all, that's one of the reasons for having a working copy; you can make sure something compiles before committing it.
Larger changes or feature additions should almost always be pulled off into branch until they're ready for integration so as not to interfere with other development.
Amber
2009-08-11 17:27:32
Sounds pretty reasonable to me, thanks.
Otávio Décio
2009-08-11 17:40:29
+6
A:
I think it really depends on the scale of your operation. Up to maybe 5-10 developers everyone committing to trunk should really be OK. But of course everyone should keep in mind that the trunk needs to always be compileable. If they're working on major changes that won't compile for a while, then they should move off to a branch.
Baxissimo
2009-08-11 17:29:09
"move off to a branch" ... isn't that what the working copy is for .. both small commits and extensive development?
Aiden Bell
2009-08-11 17:53:47
@Aiden, what do you mean? You can't commit to the working copy. If you're doing extensive development, sooner or later you'll want to commit, and if that commit is going to destabilize the code, it makes sense to be committing to a branch instead of to trunk.
Joe White
2009-08-11 18:25:54
No, Aiden, the working copy is *not* for extensive development, because no developer should have to temporarily throw away revision history for files just because they're working on an extensive change that would take a while before it could not destabilize trunk.
Amber
2009-08-11 18:38:05
@Aiden Bell, you wont be able to share your changes with other devs otherwise.
Loki
2009-08-11 18:42:30
@Aiden, what you point out is one of the big motivations behind distributed revision control systems. Yes, often you'd like to just be working in a local working copy, but you want revision control too. If you want revision control, then the Subversion way is to make a branch on the server. The distributed way (Mercurial, bzr, git) is to allow you to create a branch locally. But that branch can also be shared with others if you like, or later uploaded with full history to the central server, if you have one.
Baxissimo
2009-08-14 21:41:24
+1
A:
I have developers who create project branches or change request/bug branches off of trunk, and then merge back, so in a way yes, I have developers working off of trunk, but what goes into "merge" branches is controlled through some build-control tool or process.
I think this is pretty well covered by this question
Chris Kaminski
2009-08-11 17:29:28
+2
A:
I've almost always worked on teams that developed on the trunk--works fine. I'm not saying it's the best idea or anything, just not something that's worth opposing if it's going to get you fired.
However, our system is always buildble and often uses CI as well. Each developer must be aware of the update/rebuild/retest/commit cycle (not that it's foolproof, but it works well enough).
Hmph, it hurts when I think of how many of our software practices work "Well Enough".
Bill K
2009-08-11 17:30:13
I'll take "works well enough" any day if the alternative is "almost never works"
Otávio Décio
2009-08-11 17:46:17
+9
A:
When using Subversion, it's common practice for everyone to work out of the trunk. If a particular developer is working on a large or "experimental" feature, it can be wise to create a separate branch for that work, which can be merged back into the trunk later.
Although, the method you are describing, with each developer having their own branch, is closer to Git than Subversion. If this is the way that you prefer to work, I would highly recommend using Git instead.
With Git, it's not necessary to use some sort of continuous integration server to watch the separate branches. Instead, each developer has their own branch, which they can just merge back into the main branch whenever they want.
bcwood
2009-08-11 17:31:34
+46
A:
There are two basic strategies:
- unstable trunk - the trunk always contains the latest code, branches are made to do releases
- stable trunk - code is developed in branches and checked into the trunk only when fully tested and releases are performed from the trunk
Which you use is to certain extent a matter of personal preference. But alongside either of these, individual developers should be using branches for their own experimental developments.
So as usual, no definite answer!
anon
2009-08-11 17:33:37
Thanks, Neil - so at the end of the day none of these options are necessarily verboten, it's more a matter of how we want to manage the development process. I am leaning towards leaving the trunk being watched by CI so we guarantee an always compilable trunk, having small development done against the trunk and larger (to be defined) work for branches.
Otávio Décio
2009-08-11 17:39:47
The company I work for I follow option one, in another department they follow the 2nd strategy. Personally I prefer option 1.
RichardOD
2009-08-11 19:21:44
A warning about developing in branches: you delay merging with development in other branches. To mitigate it, always merge changes from trunk into your development branch. This is why I advocate development in trunk and using branches for emergency fixes on old releases for customers that dont want to upgrade to latest-and-greatest just yet.
Christian
2009-08-11 20:35:53
My group has definitely been of the STABLE trunk mindset. It's a fairly large pain to be running BAU fixes when you have other work in the trunk, or setting up new developers when the trunk isn't stable
MattGWagner
2009-08-11 20:52:29
A stable trunk permits a single place to go to get the released source code. Also, it permits experimentation, and the possibility of forgetting to branch the previous release before someone starts messing with the trunk is not a possibility, making it impossible to lose the production source if needed for a rebuild/rollback.
Robert C. Barth
2009-08-26 20:35:37
Another thing: how do you do parallel development with a dynamic trunk without becoming inconsistent in your process? Static trunk permits this as you just create another branch, same as always. What happens if you're using dynamic trunk, and need to release a hotfix after development has started on a new version? Now you have development going on in both the trunk and in a branch, breaking consistency in your dynamic trunk model. IMO, dynamic trunk works find for small teams; once the team/product becomes larger, the static trunk model works much better.
Robert C. Barth
2009-08-26 20:50:52
+7
A:
There are a number of methods for working with version control systems for parallel development. There's nothing wrong with the one that you suggest above - but there are advantages and disadvantages attached to each. I've worked in both ways.
Developing off trunk and cutting release branches is fine, but if you need to perform an emergency production release you end up having to patch the release branch and releasing that again - means building a branch in your CI system.
Working in branches and preserving the main trunk (monitoring with a continuous integration system) is also fine, but can lead to conflict issues with developers in multiple branches making changes.
Take a look at the following site also:
http://www.cmcrossroads.com/bradapp/acme/branching/
It discusses a number of branching patterns for parallel development including:
- S1. Mainline
- S2. Parallel Maintenance/Development
- S3. Overlapping Releases
- S4. Docking Line
- S5. Staged Integration Lines
- S6. Change Propagation Queues
- S7. Third Party Codeline
- S8. Inside/Outside Lines
Jon
2009-08-11 17:43:56
+2
A:
There's an argument to be made that developers should be required to work on trunk.
If you let them branch off, some will be tempted to maintain those branches indefinitely and cross-sync with trunk at regular intervals. This will inevitably lead to complicated merge operations, and these in turn produce bugs.
By forcing everyone onto trunk, they have to keep pretty close to the head, so there will be less risk of bugs being introduced with bad merges. Also, since everyone runs up-to-date code, they're more likely to notice bugs as they creep up, and fixes will get committed faster.
Ofcourse, sometimes a large feature needs to be staged separately, but in those cases a specially approved exception can be made.
Joeri Sebrechts
2009-08-11 17:47:27
+2
A:
Our trunk is only to merge and fix urgency bugs. When we have a new project, we branch the trunk, develop over the branch, rebase from trunk if any other branch was merged into the trunk and when we are done ready to test, we deploy the branch. When test is OK, we merge to trunk, and release to beta. Before the merge, we do a version on the trunk to avoid problems.
After beta was OK, we release to prod.
Rodrigo Asensio
2009-08-11 17:49:53
Incidentally, the only thing that makes the trunk "special" is it's name. What you've just described is essentially the same thing as developing on the trunk while maintaining a stable release branch. You just happen to name your stable branch "trunk" and give your development branch a project/release-specific name, while many teams use the opposite naming convention.
Darryl
2009-08-11 19:39:12
+2
A:
Hi, I'm working on a version 3.0 of our product today and checking in my code changes into the trunk. The release is still several weeks ahead.
A coworker is experimenting with some features that might make it into 4.0, but definitely not into 3.0. She is checking her stuff into a separate branch. It would be wrong to check in that kind of stuff into the trunk.
Another coworker is fixing bugs in version 2.5, which we already shipped to a customer. He is checking them into the 2.5 branch for obvious reasons.
So, to answer the headline question (Should everyone be developing off the trunk, my answer is no. HTH
P.S. about merging. We could selectively merge some stuff from 2.5 branch to the trunk later, but not from the trunk back to the branch. The merging between the trunk and the 4.0 branch can go both ways.
azheglov
2009-08-11 18:03:19
+3
A:
As Neil Butterworth said, it depends; several valid ways exist.
However, personally I would recommend having a stable trunk, and doing all major development on temporary branches. (I.e., only small, independent changes that will be completely done with a single commit should go directly to trunk.) To avoid longer-lived branches getting too far from the mainline, (auto)merge everything that goes into trunk to all the development branches, at least daily. Oh, and everything should be watched by CI — not just trunk but all development branches too. Especially with Hudson it's a snap and causes very little overhead.
If interested in how we've applied this, there are some more details in this answer. (I'd hate to repeat myself too much... :)
I'd actually recommend this approach even if it's just one team working on the codebase, and even if everyone is working on the same feature/change. Why? Well, because in my experience (unless things — like release schedules, requirements, and so on — are very predictable in your environment) it definitely pays off to have your trunk in a releasable shape, all the time.
Jonik
2009-08-11 18:20:22
Addendum, after reading question more closely: **dev branches should generally exist per feature/bugfix**, not per developer. Except for some personal side-projects, maybe, or if you simply have everyone working on different projects (which in most cases would be suboptimal IMHO, but I digress...)
Jonik
2009-08-11 19:03:13
@Jonik - that is correct, I was trying to establish if any work (by any developer) should be done off the trunk or off a branch.
Otávio Décio
2009-08-11 19:11:51
Right; the bit "each individual developer's branch" just stood out, and prompted me to add that :)
Jonik
2009-08-11 19:29:46
+3
A:
yes, that should be your working copy for release. All of your branches should be previous release versions of your code.
Matt
2009-08-11 18:21:42
+1
A:
It depends entirely on your release schedule. If all the work currently being checked in periodically is intended for release at once, they can all be checked into one area, like the trunk. If there's some work which will be held back while other, as yet unfinished work, has to go out first, the first code to go out could be committed to trunk, and the next code in it's own branch, OR vice versa.
You should find that merging and refreshing branches can be a hassle where things occasionally go wrong. So naturally trying to minimize that would make sense. The overall idea of source control is that everyone can work in one place.
Often when you get larger teams, the release schedule is organized by sub-teams and their projects and these have their own branches.
dlamblin
2009-08-11 18:30:22
+3
A:
Yes.
it does not make any sense to make your latest branch your most recent release. Then, your trunk becomes outdated from your branches.
Abraham
2009-08-11 20:20:22