Suggestions and pitfalls for a development/deployment setup.

Hi all,

I am currently designing a SVN setup to use for our website and backend.
This is the first time I am going to use SVN for a serious project, so
I'd like to get it right the first time! I hope somebody with experience
can give me some comments on the viability and possible pitfalls of a
setup like this. I'll try to be as brief as possible!

My goals:
- Develop on a test server, and do controlled deployments to the
production server.
- Do periodic releases where all changes from the test server are merged
into a production release.
- Support for doing "hotfixes" on the production server and backporting
them to the development machine; this should be as easy and painless as
possible.

I was thinking of the following:
- Set up a SVN repository with a trunk and a release branch.
- Check out a local copy of the trunk on the test server.
- Check out a local copy of the release branch on the production server.
- Development use cases:
  1. the developer works on local copy on the test server, and commits
  this to the trunk.
  2. when an urgent bug is noticed that cannot wait for a release, work
  on local copy on the production server, and commit this (changes go
  into the release branch), then merge these changes back into the trunk.
- Release use case: merge all changes from trunk into the release
  branch, then do an 'svn update' on the production server.

Possible problems:

- The various scripts and libraries under version control live in
various locations on the production/test server. For instance, some
files live in /usr/local/, some go into /www, some in /home et cetera.
It seems I should make subdirectories in the repository, checkout the
relevant parts of the repository at all the root points, and make a
script to walk through all these directories on the production/test
server and do a 'svn update' there. But can I also do the same for a
commit, keeping all the created changes in one singular commit (instead
of executing a 'svn ci' for every dir, creating several commits)?

- I would like to have developers use their own login/password when
committing. But at the same time, they may be working from the
test/production servers which always have an existing local copy (not
checked out by the developer account itself). Someone gave me the
suggestion to have the test/production servers checked out anonymously,
so users would then be asked for their login while committing. Will this
work? Is it also possible with a non-anonymously created local copy (for
instance with a 'testserver' account)?

- Merging changes to a different branch (releasing or backporting a
hotfix) seems to require knowing the revision number of the first change
after the previous merge. I think it's probably easiest to create a
merge-script which merges in the specified direction and then stores the
resulting revision number in a text file, so that the next merge in this
direction will be from this point. So I'd have to keep track of two
revision numbers for the latest trunk->release merge and the latest
release->trunk merge. Is my thinking on this correct?

- Are there any pitfalls in doing this kind of setup, or is there an
easier way to go abou this than the scenario?

Sigh. I guess this message is long after all. Anyway, I've tried to
google a bit for this kind of scenario, but I wasn't very succesful. Any
tips would be welcome!

Kind regards,
Walter Hop
Transip BV

-- 
  Transip BV | http://www.transip.nl/
  Hoogwaardige Innovatie | Aangename Zekerheid
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org