[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Branching Strategy

From: Tom Mornini <tmornini_at_infomania.com>
Date: 2005-04-24 18:04:39 CEST

Hash: SHA1

On Apr 24, 2005, at 3:36 AM, Eneko Gonzalez wrote:

> My idea is to have three branches: trunk (development), testing and
> production, where i can have the configuration files prepared for each
> environment.
> All the development should go to trunk brach, and testing and
> production
> should be used (with tags) when we have a new release.
> -> żIs there another (and better) way to do this?

Sure. Add a second extension to the config files (assuming they have one
already) like this:

program.cfg becomes:


Have a script that sets up the right files by mv'ing the right file
to plain and simple:


> Small fixes to a testing release would be done in the testing, and
> merged with trunk later. The same could happend with production fixes.
> -> żIs this safe, or is it going to be a merging-hell?

Without merge tracking, I wouldn't want to do it your way.

> If i want to test something experimental that can stop the other
> developers, i'd start a new branch, and delete it when finished,
> merging
> if it's worth the change.
> -> żIs this the correct usage of a branch?

Correct usage is in the eye of the beholder. Task branching as you've
described here is certainly a well understood branching methodology.

> Besides, i want to know if this strategy would need a lot of free disk
> space or not, as i'm going to have my project files in, at least, three
> branches.

No, little disk space required. Subversion is very good in that respect.

- --
- -- Tom Mornini

Version: GnuPG v1.2.4 (Darwin)


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Apr 24 18:40:17 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.