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 03:36:32 CEST