2

For a new product release, we have following server/release structure planned.

release structure

For different management reasons, it is now a final management decision to have two different SVN reposatory; one on production server (Prod. SVN shown in red) running on Anazon EC2. Other is on local Linux server (Green).

I'm stuck how to achieve this technically. My problem is, local server codebase (Scaling codebase in above fig) should be updated from Local SVN but should commit to Production SVN. I could not find if achieving this is technically possible or not. Before I look other options, I'd like to ask the community if it is technically possible or not and if yes, how?

Kapil Sharma
  • 10,135
  • 8
  • 37
  • 66
  • It is not clear to me how you can keep the green and the red SVN in sync? If you're looking for SVN replication have a look at this: http://stackoverflow.com/questions/148625/how-to-get-master-master-replication-with-subversion – Anders R. Bystrup Oct 13 '12 at 08:54
  • Thanks @AndersRostgaardBystrup I'm going through the solution given on link. I'll get back soon with my findings & discussion with other team member here. – Kapil Sharma Oct 13 '12 at 09:05

3 Answers3

3

Contrary to previous answers

Pure SVN-way for workflow

With Sacling WC

svn up
svn relocate ProdSVN
svn ci
svn relocate LocalSVN

Without Sacling WC

If direct comminication LocalSVN -> ProdSVN will be possible, SaclingCodebase can be excluded from sync process (less chains, less errors):

or

or

Community
  • 1
  • 1
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
1

updated from Local SVN but should commit to Production SVN.

This is a common feature for distributed version control system DVCS like Bazaar, Git or Mercurial.

So, to my mind, two solutions:

1/ If you still want to keep SVN: use Bazaar/Git/Mercurial to checkout a SVN repo and push/commit to another SVN repository.
This is possible as most DVCS tools have a plugin to access (checkout/push) SVN repository.

2/ Change your system to a full DVCS like Bazaar, it is so close from SVN taht the users will not be lost !

Have a look to my following reply:
multiple source code repositories

Community
  • 1
  • 1
TridenT
  • 4,879
  • 1
  • 32
  • 56
1

One way of doing this is just having a single repo (probably on the green server), and having a release branch of that repo checked out on the production server.

So the workflow would be:

Checkout ^/trunk (or feature branches of trunk) on dev, and then cherry-pick revisions from ^/trunk to ^/branches/release.

John Carter
  • 53,924
  • 26
  • 111
  • 144
  • Well that's the easiest solution but not acceptable to Mgmt. Again Green server is a linux box in local office without public IP so Red server (Amazon EC2) can't be updated from there and giving **EC2 access to contract developers and freelancers is not acceptable solution** so we cant host SVN there too. This left us with only one solution, having two SVN repo. However if needed, we can switch to GIT or any other version control too, but first trying to do it with SVN as it is already setup on both servers, we have lot of code there and don't want to loose version history. – Kapil Sharma Oct 14 '12 at 20:27
  • @KapilSharma note that you should be able to preserve SVN history by using git-svn. – John Carter Oct 14 '12 at 20:54