Greetings.
We're looking to update our development environment to include svn as
our source change control mechanism. We developed our current
mechanism back in the very early 1990's, and it's done OK, but has
problems. I've used svn as a user on various open source projects, and
would like to implement it in our company's IT department as well.
It appears that the most critical aspect of implementation will be the
structure of the repository. Let me therefore discuss our
environment, and a possible respository structure, so you can tear it
apart and help me put it back together again.
We have five main production categories:
- Programs written in C
- Programs written in our database engine's 4th generation language
(4gl)
- Shell scripts, SQL scripts, awk scripts, perl scripts, report
scripts, and the like -- basically anything which is interpreted
rather than compiled.
- production data (not to be versioned)
- database
Ignoring the last two, our current structure and activities are:
Prod: -- Our production computer system; almost never edited directly
(and direct edits are getting more and more uncommon as we
tighten things up)
Prod:/u -- root for the three areas under version control
Prod:/u/scripts -- All our scripts go here, each significant
"application" in a subdirectory of its own.
Prod:/u/scripts/appl/new -- Within each application directory
there's a "new" directory into which we place all scripts
for validation before moving them to the production
directories above.
Prod:/u/src -- All compiled source code goes here
Prod:/u/src/4gl -- All 4gl source code is found here, each
major application having its own subdirectory, with
another subdirectory reserved for common functions.
Prod:/u/src/c -- All C code is found here, again, each major
application having its own subdirectory, with another for
functions, and another for our schema-describing *.h files.
Prod:/db -- root for our database and execution structure
Prod:/db/prod -- our production database
Prod:/db/prod/cbin -- All compiled C code executables are found here
Prod:/db/prod/4bin -- All compiled 4gl code executables are found here.
Prod:/db/qa -- our Q/A database -- all programs are executed,
tested, and validated against this database before being
placed into the above production directories
Prod:/db/qa/cbin -- All compiled C code executables are found here
Prod:/db/qa/4bin -- All compiled 4gl code executables are found here.
Dvlp: -- Our development computer system. All program changes are
initially developed and tested on this system. The directory
structure is identical to the production system above.
Given what I think I've learned about svn, I'm thinking of
implementing this type of structure:
Prod:/svn -- root of everything controlled by svn, including all of
the script and source code modules above. This will be a single
repository, containing all source code, all applications, all
languages.
Prod:/svn/prod -- All production modules are stored here. Only our
program librarian will be able to commit files to this area.
This is like a development tag, a major release, except we
don't issue releases -- we just move applications or programs
into production when they are ready.
Prod:/svn/qa -- All modules which have been tested by the
development team and are ready for Q/A will be committed to
this branch. Except for modules which have just been released
to Q/A by development, this area will be an exact duplicate of
the svn/prod production area.
Prod:/svn/trunk -- All working copies will normally be created from
here.
Within each of svn/prod, svn/qa, and svn/trunk, we'll have
subdirectories for scripts, src.4gl, and src.c, indicating the types
of modules.
Dvlp:/dvlp will be the root of all development work. Within this area,
we'll have directories for each developer, eg: Dvlp:/dvlp/bob
Dvlp:/dvlp/bob/scripts, /dvlp/bob/src.4gl, and /dvlp/bob/src.c will
be the development areas in which "bob" does his work. These
will be his working copies of the source modules.
Dvlp:/dvlp/qa will be our permanent Q/A area. For the most part it
is a complete check-out of Prod:/svn/qa. When a developer
indicates that modules are aready for Q/A, he will provide the
list of modules, and the Q/A team will copy those modules from
the development area to this Q/A area, and then commit to
Prod:/svn/qa
Dvlp:/dvlp/prod will be our permanent image of the production
system. When the Q/A team passes updates for implementation,
the program librarian will copy those modules from the Q/A area
to this prod area, and then commit to Prod:/svn/prod
Mechanisms and procedures:
- We'll create Prod:/tempsvn/prod, with a complete working copy of our
production environment. We'll then import this as revision 1 to
create Prod:/svn/prod.
- We'll use "svn copy" to create Prod:/svn/qa and Prod:/svn/trunk from
Prod:/svn/prod
- We'll use "svn checkout" to create Dvlp:/dvlp/prod from
Prod:/svn/prod, and will secure this working copy so it can be
updated only by our Program Librarians.
- We'll use "svn checkout" to create Dvlp:/dvlp/qa from Prod:/svn/qa,
and will secure this working copy so it can be updated only by our
Q/A team.
- Each programmer will have his Dvlp:/dvlp/$name working area, and
will check out modules from Prod:/svn/trunk as needed.
- Programmers will work with modules from Prod:/svn/trunk in their
private checkout areas, using "svn update" and "svn commit" as
appropriate during their work.
- When a programmer is ready to place work into Q/A, she will again
update from and commit to trunk, and will generate a list of all
files that need to be fed into the Q/A system.
- The Q/A team will use "svn merge" commands to merge the trunk copy
of those files into the Q/A branch, first with --dry-run to make
sure there are no obvious problems, and then to actually update
their working copy.
- The Q/A team will then compile and execute the modules within their
working copy to validate the change, against the Q/A database, on
the development machine.
- When Q/A passes on the development machine, they'll commit the
changes in the listed modules, updating Prod:/svn/qa with these
changes. They will then repeat the validation against the Q/A
database on the production machine.
- The Q/A team will then pass the list of modules to the program
librarian, who will again do an "svn merge" to merge the Q/A files
from the Q/A branch into the "prod" working copy.
- Assuming that merge succeeds, the program librarian will commit the
changes to the production system. They then become live.
Does this look like it will work?
Are there any obvious ways in which it can/should be improved?
What types of things do we need to know or keep in mind as we develop
this system?
Thanks for any/all suggestions and comments.
Bob Menschel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 14 05:27:51 2006