RE: Re: Exporting/Importing to Multiple Repositories

> I guess not, because repositories by definition don't share any relation, so the two will be completely separated from each other. Just wondering, but > why do you even want separate repositories?

It's more of a security issue raised by management. The reasoning behind the second repository is to more control what gets released to UAT or Production and prevent developers trying to slip in last minute code changes that haven't gone through proper change/testing procedures. Only source code checked into the second repository will be compiled and released to our UAT/Production systems.

> Export from one and import into the other. This completely removes the connection between the code and the history and also the file/dir properties (svn > propset..), which you will have to copy in addition. Further, since the history is disconnected, each 'tag' will be a fully separate copy even though it > shares lots of data with the former tag, but SVN's algorithm of storing deltas won't detect this, so you should prepare for a rather big repository for > the tags. OTOH tags in the same repository are just copies which have a small, constant size.

This is what I'm scripting up to do now with Nant but do realise this second repository will not benefit from the cheap copies and will be much larger in size.

> Well, if you were using an svn:externals reference into the same repository, I would suggest replacing that reference with a normal copy when tagging. > > That way you have defined results and the size overhead is also negligible.

I hadn't considered that, it be much easier then trying to maintain two libraries in two repositories and keeping the svn:externals references correct.

Cheers,
Gordon

-----Original Message-----
From: Ulrich Eckhardt [mailto:eckhardt_at_satorlaser.com]
Sent: Tuesday, 20 May 2008 5:27 PM
To: users_at_subversion.tigris.org
Subject: Re: Exporting/Importing to Multiple Repositories

On Tuesday 20 May 2008, Woodward, Gordon (RBC Dexia IS) wrote:
> My company is in the process of moving all our source code to
> Subversion and what we are planning on doing is having separate
> repositories. One repository will be used by all our developers to
> manage their code with, the other repository is what will be used for
> storing all the source code that gets released to UAT/Production. In
> essence the second repository will be used as an external tagging system.
>
> Is anyone using Subversion is a similar scenario?

I guess not, because repositories by definition don't share any relation, so the two will be completely separated from each other. Just wondering, but why do you even want separate repositories?

> What process would people recommend in moving the code between
> repositories?

Export from one and import into the other. This completely removes the connection between the code and the history and also the file/dir properties (svn propset..), which you will have to copy in addition. Further, since the history is disconnected, each 'tag' will be a fully separate copy even though it shares lots of data with the former tag, but SVN's algorithm of storing deltas won't detect this, so you should prepare for a rather big repository for the tags. OTOH tags in the same repository are just copies which have a small, constant size.

> I've been investigating using a Nant script to do this process but
> have a couple of problems I'm trying to find solutions for. The dev
> repository makes heavy use of a common library with each project
> stored in Subversion using multiple svn:externals references to this
> library. When exporting the Dev code that is ready for UAT/Production
> release, I need to update these svn:externals to point to the common
> library held in the second repository. I've been looking at the svn
> commands and can save the svn:externals definitions to a text file but
> the sticking point is the actual updating of the svn:externals
> references back to Subversion. Any advice on the best way to do this?

Well, if you were using an svn:externals reference into the same repository, I would suggest replacing that reference with a normal copy when tagging. That way you have defined results and the size overhead is also negligible.

Uli

--
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
           Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
____________________________________
This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient(s) is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately and delete this e-mail.
	The contents of any attachment to this e-mail may contain software viruses or other defect which might affect your own computer system once received or opened. While companies under RBC Dexia Investor Services Trust and its affiliates take reasonable precautions to minimize that risk, we cannot accept liability or responsibility for any damage or loss which may occur or be sustained as a result of a software virus or other defect. You are responsible for virus checks before opening any attachment.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org