Initial implementation design questions

[sv...@menschel.net]

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