[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Two-Site Subversion Repository Setup Ideas

From: Richard Cavell <richardcavell_at_mail.com>
Date: Mon, 06 Jun 2011 07:12:29 +0000

Just my two cents...

 How secure is "secure"? Is it to stop a source code leak like Half-Life 2, where millions of dollars in intellectual property is paraded on the Internet and they are publicly humiliated? Or are they designing software for guided missiles?

 I think they're going to have to communicate more often than once a week. Set up a trusted staff member to act as courier, who drives back and forth every day. If you're really paranoid, ensure that the CD is encrypted by a method unknown to the courier, by a second staff member who is that staff member least friendly with the courier.

----- Original Message -----
From: Nico Kadel-Garcia
Sent: 06/06/11 01:58 PM
To: Les Mikesell
Subject: Re: Two-Site Subversion Repository Setup Ideas

 On Sun, Jun 5, 2011 at 10:19 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote: > If it doesn't take too long for a round-trip, you could ship the working > copy from site B to site A, do the commit and update, and ship it back > before doing any more work at site B. Les, I'm looking right at his original post. > 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. If they're security sensitive, sending the working copies back and forth becomes a security nightmare. It also becomes a major performance bottleneck for the remote site, who may really not appreciate being treated as second class citizens.
Received on 2011-06-06 09:13:20 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.