It sounds to me like you need to have developers working entirely in
private branches. Then your testers can pull from a private branch, and
when ready, commit to the "stable trunk".
As for dependency issues-if a developer needs to merge in somebody
else's patch, then this patch gets tested at the same time.
You will still have issues with merging since it can be so long before
changes get committed back to the trunk. When you find conflicts you'll
want to re-test.
Of course, none of this will save you from the possibility of
interactions between the various fixes...developer A's fix breaks
developer B's fix, and both were committed at the same time. You can
only find this with some kind of regression testing afterward, automated
or otherwise.
A complete alternative to this "stable trunk" mode of development would
be the "unstable trunk" where developers can commit at any time until a
"lock down" occurs. This gives freedom at the beginning of the project,
and stability at the end.
You can find both of these in more detail online, with some nice
graphics at
http://blogs.open.collab.net/svn/2007/11/branching-strat.html .
________________________________
From: Daniel Becroft [mailto:Daniel.Becroft_at_supercorp.com.au]
Sent: Monday, September 29, 2008 7:36 PM
To: users_at_subversion.tigris.org
Subject: Release Management
Hey all,
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.
Our 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 handling).
** Current model:
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 model:
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 purposes.
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 across.
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?
NOTE: We currently have no automated testing scripts in place, but this
is on the horizon.
Cheers,
Daniel B.
Received on 2008-09-30 14:51:31 CEST