Re: Setting up first repository

[Pierre Asselin]

Roddie <address@hidden> wrote:
> I'm new to CVS, and I've been reading up about it for some weeks.
> [ ... ]
> I'm a one-man website developer. As things have turned out, I do relatively
> complex on-going work on a small number of sites. Development is on my OS X
> Mac laptop, and deployment is on my own RH Linux co-lo.

> The repository could be on either computer, but I plan to put it on the
> co-lo.

You may want to dry-run this on your laptop.  Run cvs init to start a
repository, use it locally for a while, wipe it out when you have
enough experience to init a new repository on your co-lo.

The dry run is just to play with cvs commands for a while.  You have
a pretty strong incentive to switch to your final repository so you can
distribute files to the live site through cvs.


> [ ... ]
> The shared directory holds libraries and other files needed by all the other
> sites. Each site uses symlinks so that the shared files appear to be in the
> correct place for that site.

Sometimes it helps to think of your sandbox as the *source tree* of your
web site rather than the web site itself.  Planting the symbolic links
is now a trivial "compilation step" that you perform after checkout or
update.  This should be scripted, and the script should be part of your
sandbox, under revision control like the rest.


> I plan to have the sites directory as the project. There would be three
> sandboxes to start with: a development sandbox on the Mac laptop; a test
> sandbox on the co-lo (to iron out any Mac<>Linux issues); and the live sites
> in a sandbox on the co-lo.

Sounds good.

> Normally, development will take place on the Mac, be committed, the test
> sandbox updated, tested and committed, and then the live site sandbox (and
> the Mac if necessary) updated.

Or you could have a scripted installation step to copy the test sandbox
to the live site, which may or may not be a CVS sandbox.


> Occasionally I make changes direct to the live site. These are usually
> trivial updates of content, but remembering to make them also in the
> development files is a nuisance. In this instance I would make changes to
> the live site, commit them, and then update the development sandbox.

Then your live site should be a sandbox, and it should be on a branch.
Otherwise, you won't be allowed to commit your trivial tweaks without
first running an update, and that would force you to deploy changes
sooner than you would like.

Having a release branch is pretty standard.  You fix bugs on the branch
and merge them back to the trunk so you don't have to fix them twice.
When your trunk is good, you cut a new release branch and update the
live sandbox to the new branch.  Post again if the process is not
clear to you.


-- 
pa at panix dot com