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

Re: Release Management

From: BRM <bm_witness_at_yahoo.com>
Date: Tue, 30 Sep 2008 07:03:13 -0700 (PDT)

While I agree with Todd's comments, a few other thoughts...

I would probably use a slight variation from what Todd suggested:

1. Stable trunk
2. Developers work in their own branch for working
3. Testers work in their own branch which becomes a specific release.

So: Trunk is stable, developers branch from trunk to do their work, and then merge the changes back in. This can be as micro or macro as you like; but I would suggest that it be as micro as possible.

When ready for the release, branch for the release. If testers find issues, then they can fix the issue in the branch and merge it back to trunk so future work gets the fix too when possible.*

This gives you a relatively stable trunk, and a lot of unstable branches for the developers, with 'code freeze' branches for the testers and eventual release.

This won't resolve the merge conflicts - but the developers doing the merge should be able to manage it. It should also make the process relatively maintainable in the long run too.


* Sometimes you want a quick fix that you don't want to actually continue with b/c of having a better solution that takes longer to implement; in which case the release gets the quick fix and trunk gets the longer fix.

----- Original Message ----
From: Daniel Becroft <Daniel.Becroft_at_supercorp.com.au>
To: users_at_subversion.tigris.org
Sent: Monday, September 29, 2008 9:36:23 PM
Subject: Release Management

We are
currently in the process of replacing our existing SCM with Subversion. We are
already using SVN for our new project(s), but are considering using it for our
current application as well. We have come against a process problem that we
can't seem to find a solution for. I thought I would ask the user community for
(a) past experiences and/or solutions; or (b) opinions/flak.
application is approximately 6 million LOC, across about 6000 source code files
(many of which are no longer needed, but we had no file delete
** Current
Our current
system uses a pessimistic locking approach. A developer will check-out (aka
lock) multiple files for a given ticket. No other developer can modify these
files until the ticket has been through the full testing cycle, and passed all
QAs (it can sometimes take several MONTHS before these files are available
again). When the testing is complete, these files are copied (in their entirety)
into the 'deployment' or 'staging' area. When we cut a patch or release, we
simply take the files in the staging area, compile, and ship. This is all a
single step process, with no manual intervention.
** New
We are tried
to use SVN in the optimistic method (ie minimal locking, if any). We will have
one main development and one main release branch per version (1.00-development
&& 1.00-release, 1.01-development, etc).
Developers will do the normal check-out, modify, commit cycle on the
'development' branch for the required version.
Testers will use a checked-out version of the development branch for testing
The problem
is: What is the easiest method of obtaining a version of deployed/tested code,
based on the deployed tickets Given that a file can be modified by multiple
developers now before being deployed, we should really only be shipping the
changes from the deployed tickets.
The solution
we have worked out so far involves the following:
1) Take a
copy of the last release/patch to be sent out.
2) Check the
eligible revisions to be merged to this branch.
3) If the
ticket for that revision has been deployed, then merge this change
This doesn't
solve the merge conflicts problem (ie trying to merge r132 of a file without the
changes from r130). As a result, we can't get around the 'manual intervention'
issue with this..
Has anyone
had to deal with these situations before? How do other people manage releases
with SVN, and only shipping 'deployed' code?
currently have no automated testing scripts in place, but this is on the
Received on 2008-09-30 16:03:39 CEST

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.