Ryan
Ryan

Reputation: 1119

switching svn working copy to commit to two different servers

Good Day Stackoverflow

I have an SVN working copy of my admin system on my local machine.

The working copy is checked out from our production server. So any commits from me or my team mates make goes to the production server repo.

What I want to do is to create a repo with the production server code on our development server. So that me and my team mates can commit everything to the development box. when we are all happy with the code i want to switch my local repository over to commit to the production server

Is such a thing possible. If so... how?

Upvotes: 1

Views: 668

Answers (2)

David W.
David W.

Reputation: 107030

Why does production have a version control system, but not the developers?

Version control is for the developers. You should be able to checkout, update, make changes in the code, add features, make mistakes, do stupid stuff, etc. It's what version control is for!

Production, if they get the code from the Subversion repository at all, should be checking out the code from a tag. A tag is what you want the world to see. It's something you hope has been purged of your mistakes, errors, and other bumblings through careful and rigorous testing.

Move your Subversion repository from Production, and put in into your development environment. That is, unless you mean production that it's being backed up and maintained -- Not that people who are on the production environment (like customers) actually use Subversion. In that case, let the repository stay in Production, but developers shouldn't be afraid to use it.

Some sites use trunk strictly for release code. This is not a good idea. Release code should be put into the tags directory. The trunk and branches are for the programmers to do programming.

Upvotes: 2

Lazy Badger
Lazy Badger

Reputation: 97270

While using branches on the single server is more manageable way, you can have two repositories and switch between them, as requested

  1. Create full dump of Production (svnadmin dump PROD-PATH > DUMPFILE)
  2. Create DEVEL repo (svnadmin create DEVEL-PATH)
  3. Load dump of PROD to DEVEL (svnadmin load DEVEL-PATH --force-uuid < DUMPFILE). --force-uuid is mandatory in order to have the same UUID in both repos (thus allowing to relocate single WC between repositories), "svnadmin create" assigned unique UUID to DEVEL
  4. Relocate WCs to DEVEL
  5. Code-commit-test...

In order to return code back to PROD

  1. Get clean WC, updated to the DEVEL HEAD
  2. Relocate WC to PROD
  3. Update WC to the PROD HEAD, merge changes
  4. Commit all changes accumulated from DEVEL in WC, as one "big bang" commit to PROD
  5. Go to to part I, step 4

Upvotes: 1

Related Questions