On Sun, Jun 05, 2011 at 02:57:22PM +0000, Randolph, Christian [USA] wrote:
> I am looking for suggestions from the community as to how best address the setup issue outlined below.
> We have two sites wanting to use Subversion that are performing parallel development of the same software. Due to security restrictions, the two sites are unable to communicate electronically; all data transfers must be via media (CD-ROM/DVD). Site A is the main site and is responsible for overall configuration control.
> Is there a way to setup the two subversion repositories to somehow automate keeping the two repositories in sync? We are usually passing media back and forth once a week, but currently we are doing a manual sync process that is both time-consuming and error-prone.
> Any suggestions would be greatly appreciated.
One option would be to treat these projects as independent projects
and use a vendor-branch model to synchronise changes, which sounds
like what you are currently doing.
In essence this creates two different universes of your project,
universe A and universe B. Each universe receives a new version of
the code from the other universe whenever a disk arrives in the mail
and merges all new changes at once into their own version of the code.
There is a perl script that helps with this task (see above link).
Log messages and revision numbers are unique in each universe.
However, you could ship textual changelogs on disk to help people
with sorting out what happened at the other end (e.g. include the
output of svn log -v -rN:M when you ship changes made between revision
N and revision M).
Another option would be to use Mercurial or Git, and ship clones of
repositories around on disks. These systems have been designed to
preserve history even in case of offline operation (in your scenario
Site A is offline from the point of view of Site B and vice versa).
Subversion has not been designed for server-independent operation.
For proper operation you need either one central server or at least
a mirror server that can contact the master over a network connection.
Received on 2011-06-05 17:34:36 CEST