CODEWITHSUNDEEP
version-controlbranchbranching-and-merging
Eric
Eric

Reputation: 6016

Source control branching schemes for internal applications

I'm accustomed to a source control branching scheme where branches are created for each major version of a product. I may be overlooking some latent benefits of this model, but I think the main benefit is that this allows releases to be patched out-of-band.

It seems like this model is overly complicated for products that will never have patches for anything but the most recent release (such as websites and internal applications).

I'm considering moving our internal applications to a two branch model: development and production. The development branch would be for work on the next version of the product, and the production branch would be for patching the current version of the product.

Am I oversimplifying, or missing some other benefit of a versioned branching structure? What have other people used successfully for internal applications and websites?

Upvotes: 1

Views: 166

Answers (1)

Eric
Eric

Reputation: 6995

My development team uses a similar strategy, except we also use a third branch for testing. We have a small team and it works very well because we don't lose much time dealing with merging, working copies, and other time-wasting hassle. I don't think it would scale well if we suddenly doubled or tripled our team size, but we would have a lot more to worry about than subversion branching in that case.

I don't think you're really not missing out on many major benefits by pruning your branches. If your team is small and/or everyone has clearly defined tasks that don't interfere with anyone else's work, then save yourself the trouble of maintaining a bloated repository. The more people you have working on it, though, the greater chance of having to sort out merge conflicts.

Upvotes: 1

Related Questions