Subversion - should anyone be developing off the trunk?

Question

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 conti

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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".

Answer 6

Yes.
it does not make any sense to make your latest branch your most recent release. Then, your trunk becomes outdated from your branches.