Subversion - should anyone be developing off the t

问题:

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?

回答1:

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!

回答2:

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.

回答3:

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

回答4:

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.

回答5:

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.

回答6:

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

回答7:

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.

回答8:

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.

回答9:

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.

回答10:

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.

回答11:

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

回答12:

yes, that should be your working copy for release. All of your branches should be previous release versions of your code.

回答13:

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.

回答14:

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

回答15:

I think if you are agile and release in small increments within a few weeks, you should develop in trunk. This way, you have the latest in trunk, it gets built constantly, may be it gets broken, but would get fixed soon and when you are ready to release, tag it and release it. This way, there is no headache of merging from branches too.

I think I'd also like to add that if you are developing in branches, you can't be agile. Developing in branches works only in waterfall.

回答16:

I think the tools you use are a big factor here as well.

• If you are using Subversion, unstable trunk will probably work better for you.
• If you are using GIT, stable trunk will be much easier than Subversion.

回答17:

In my company we have adopted stable trunk development model with code being developed and fully tested on branches before being merged up to the trunk. But i am finding this practice pretty daunting because it often takes months for the validation team to get around to fully testing the feature branches. So we end up with these branches lingering around for months before we can merge them back into trunk.

The flip side of this would be to use unstable trunk development with all changes going into the trunk all the time, but then our validation team starts complaining that they don't have confidence in the code because everyone's changes are always in there and there is no isolation.

So seems like neither one of these approaches is really optimal. Is there a more optimal approach for a team where validation can take a really long time?