[UPHPU] Where to put repository

[Walt Haas]

Wade Preston Shearer wrote:
> I am interested in opinions on where best to locate a repository.
> Concider the following situation:
>
> There are individual development environments for each developer. They
> commit their code to the repository. Code is updated on a common "dev"
> server from the repository for testing. When updates or releases are
> ready to by published, the code involved is then updated on a beta
> ("staging") server (that identically matches the production servers)
> from the repository where it is confirmed to be ready. Once verified,
> the code is then updated on all production servers (behind a load
> balancer) from the repository.
>
> Myn question is where would you put the repository? All servers have
> to have access to it. I like the idea of putting it on the dev server,
> but for security, the production servers can currently only
> communicate with beta. So, with my current setup, the repository would
> have to be on beta.
>
> If you were setting up a system such as this, how would you do it?
>   
If you are using Subversion via Apache and WebDAV, you have all the 
Apache tools available to do security.  If you want to use all the 
Subversion tools for history, merge etc. then it makes a big difference 
whether or not two versions of the code are in the same repository, 
because that's what determines what automatic tools you can apply.

Given all that, I set up Subversion for DharmaTech's site as follows:

   1. There is one repository for each piece of software that we work
      with.  By "piece of software" I mean software development project
      with a release schedule.  Thus Drupal and TinyMCE are two pieces
      of software since they are developed independently by different
      groups.  Drupal uses TinyMCE and Drupal brings in its copy of
      TinyMCE by using an external reference to the TinyMCE repository.
   2. Within each repository, the setup is basically what is described
      in the Subversion book:
          * vendor/ for the code as it came from the developers, with no
            local changes
          * trunk/ for the latest stable, tested code, basically the
            contents of vendor/ with our modifications
          * tags/x.y.z/ for versions of trunk that represent  known
            fixed points  of stable, reliable functionality
          * branches/something/  for work in progress.  We create a
            named development branch for each line of development by
            making a copy of trunk/.  When development on a branch has
            reached its conclusion we merge the changes back into trunk/
            (or throw them away, depending :-)
          * branches/clientname/ for each client.  If we did this on
            Fantasy Island we would never need to make a custom code
            change for a client.  Since we work in the real world,
            however, we set up a client by creating a branch for them
            from the latest tags/x.y.z version then do what we need to. 
            If an important security patch comes out, we start by
            applying it to vendor/ (if it came from the original vendor)
            then merge it in to trunk/, the next incremental tags/../
            and clients as needed.  This gives us the ability to do an
            orderly merge and back the change out if necessary.

Each client's site is a working copy of their branch.  If we need to do 
development for a client that is in production, we will create a branch 
from their production branch, develop the changes on their branch, then 
merge the results back into their production branch.

Since our software is free software and openness is one of DharmaTech's 
core values, you can have a look at our repositories here:

  https://justice.dharmatech.org/svn/drupal/
 
  https://justice.dharmatech.org/svn/civicrm/

  https://justice.dharmatech.org/svn/tinymce/

-- Walt