how to layout the SCM tree when we always need a ready-to-releasebranch

[Database Administrator]

I'm looking for advice on how to organize our tree (we are using SVN),
considering the following requirements:
1. We have a single version for all our clients. For clients who don't
want a certain feature, we hide it through system preferences. We also
don't maintain old versions. If there is a bug in an old version, the
client is upgraded to the latest version that has the bug fixed,
together with any new features the new version might has.
2. Instead of the usual cycle of deciding on a feature set, completing
it, branching, tagging and releasing, we release new versions as soon
as certain bugs are fixed, sometimes when a feature is still in the
works and wasn't completed yet. Assume we are releasing on a regular
time interval, regardless if we completed a feature set or not. So we
need to have some branch which is always ready to be released.
3. All developers have write access to the tree. We don't have the
resources to review code before commit.

We thought of the following layout:

\trunk
\branches
\tags
\development

so that usual development is done on the development branch, and once
a bug is fixed or a feature is complete and tested, it is merged to
the trunk. If a feature is worked on a feature branch off the branches
folder, it will first be merged to development, tested, and then
merged to the trunk. Does that make sense? Maybe we'll call trunk
"release" and development "trunk".
The problem with this setup is that the development branch will have
code that is less stable than the trunk, so when we work on it, we
might encounter problems which don't exist in the trunk, and don't
need to be addressed, or that might interfere with the work.

so what would you recommend for the way we work?

Tsahi

[Database Administrator]

On 2008-08-10, Tsahi Asher wrote:
> I'm looking for advice on how to organize our tree (we are using SVN),
> considering the following requirements:
> 1. We have a single version for all our clients. For clients who don't
> want a certain feature, we hide it through system preferences. We also
> don't maintain old versions. If there is a bug in an old version, the
> client is upgraded to the latest version that has the bug fixed,
> together with any new features the new version might has.

So you don't have any clients with in-house change management who find
it far easier to get a patch past the "protections" than an upgrade?
(Not actually relevant to your real question, sorry.)

> 2. Instead of the usual cycle of deciding on a feature set, completing
> it, branching, tagging and releasing, we release new versions as soon
> as certain bugs are fixed, sometimes when a feature is still in the
> works and wasn't completed yet. Assume we are releasing on a regular
> time interval, regardless if we completed a feature set or not. So we
> need to have some branch which is always ready to be released.
> 3. All developers have write access to the tree. We don't have the
> resources to review code before commit.
>
> We thought of the following layout:
>
> \trunk
> \branches
> \tags
> \development
>
> so that usual development is done on the development branch, and once
> a bug is fixed or a feature is complete and tested, it is merged to
> the trunk. If a feature is worked on a feature branch off the branches
> folder, it will first be merged to development, tested, and then
> merged to the trunk. Does that make sense? Maybe we'll call trunk
> "release" and development "trunk".

You definitely have a release-line, so you should call it that.

> The problem with this setup is that the development branch will have
> code that is less stable than the trunk, so when we work on it, we
> might encounter problems which don't exist in the trunk, and don't
> need to be addressed, or that might interfere with the work.
>
> so what would you recommend for the way we work?
>

Development (or trunk if you want to call it that) obviously has to be
safe (i.e. usable) most of the time. You may not have the resources for
code reviews but presumably you manage to test before a release.

So, if development passes the tests, you would be able to merge it to
the release-line (and re-test!). If it doesn't, you need to decide which
piece of work is causing the problem, and either get it out into its own
branch, or fix it quick. The order of those was deliberate, you should
branch unless there is a very good argument (and a clear path to follow)
for fixing.

I think you should be testing more often than just before a release - if
you have or can create automated tests they should be run every night.
Otherwise you need to work something else out, perhaps a regular "test
day".

In summary, keep the development line in working order. And accept that
feature branches are good, but branching for conflicting bug fixes
should be a last resort.

Regards,

Eric