2

I am wondering if there's a good solution to accomplish the following scenario:

  • 2 SVN repositories, Repo1 and Repo2
  • Repo1 only hosts the sources but nothing is going to be developed there.
  • Repo2 will be the main developoment repository (Code from Repo1 goes to Repo2)
  • Repo1 and Repo 2 have no physical connection to each other (never)
  • Code that has been modified in Repo2 should be merged back to Repo1 (No active connection and only the newest Revision)
  • The SVN-Source includes externals as well as other SVN-properties, that should be remained.

This scenario represents a case, where the source code is maintained at the customer side. Our customer would like to have new features and gives us some code from his Repo1. As a contracter we take the code and put in our own subversion Repo2 and extend the code. After our job is finished, we would like to give back the new release to the customer and he will merge it back into his Repo1.

I couldn't find an appropriate way with only svn tools to realise this szenario. Also the vendor branching concept isn't really working as it is using SVN-export. But SVN-Export will not keep the svn-properties.

Thanks in advance for any help.

Regards, Rainer

froudou
  • 21
  • 2

3 Answers3

0

You'rer looking for master-master replication in SVN. I'd recommend migrating to git or mercurial as SVN was never made to accomplish this. If impossible to abandon SVN, I'd recommend moving to SVK or git-svn. :

Another post outlines some more details on this: How to get master-master replication with Subversion?

Community
  • 1
  • 1
Ray
  • 40,256
  • 21
  • 101
  • 138
  • I tried using git-svn without success. Obstacles: 1. Git-svn needs to have a clone of Repo1. Repo1 is >50G. This takes a lot of time and space 2. Other compnanies make changes to Repo1 as well. Hence conflicts occure at Repo1. But developers can not access the customer site to resolve them. 3. git-svn needs to have all the revisions to merge back successfully changes. I'm only allowed to give back the newest Revision (HEAD). 4. New requirement: Company related information are not allowed to be synced (e.g. commit-comments,author etc..) I guess SVK/GIT will fail here as well. – froudou Mar 07 '14 at 10:42
0
  1. Vendor branches may use export or diff|path or externals (and, BTW, svn:externals) must be resolvable only on client side at checkout|update|commit
  2. You said nothing about simultaneous availability of both repos from client-side

In common case for simplicity (and pure SVN in game) I'll prefer svn diff -g|svn patch way:

  • Every must be transmitted revision exported on source with svn diff -c -g
  • Returned in target (through WC) repository with svn path

Diff (esp. in git extended format) will contain all metadata from exported revision

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
0

I ended up now using the vendor-branching concept but with dump/load instead of export.

  1. Dump a specific tree from Repo1 (only HEAD).
  2. Lock the tree in SVN authorization file of SVN-Repo1. Nobody can access it now at the customer side.
  3. Anonymize the dump with "svndumptool"
  4. Load the dump in our Repo2 to tag/xyz
  5. Merge the dump to trunk/xyz (Overwrite what might already be there)
  6. Adapt externals at Repo2
  7. Develop in Repo2
  8. Dump again all changes we have maid (only Head)
  9. Anonymize the dump with "svndumptool"
  10. Load the dump back into Repo1 to tag/xyz
  11. Unlock the Tree in the SVN authorization file.
  12. Merge the dump to trunk/xyz (Overwrite what might already be there)
  13. Adapt externals at Repo1

...and voila our customer has the newest release. All those steps can be scripted pretty neat and easily automated.

I know is not a nice solution, but is also not a nice task to accomplish ;-)

Anyway, thanks a lot for all your efforts.

froudou
  • 21
  • 2