On 6/5/11 10:58 PM, Nico Kadel-Garcia wrote:
> 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.
Ummm, doesn't not having network access make you second class by definition?
My point is that bits are pretty lightweight and transporting working copies
would actually work as opposed to trying to keep 2 repos in sync, which won't.
You could, of course keep copies of the working copy at both places and send
diffs back and forth which would make it harder to steal the intermediate
transfers and easier to fit on a dvd, but external 2.5" drive are nicely
portable, go up to 1.5TB, and can be encrypted. But, the real problem is that
besides doing the commit, site B's working copies have to be updated with the
changes sent back and patched into place before they do any more work - and
someone at site A has to resolve conflicts which may leave some surprising
changes in the code coming back. The timing of that round trip might make it
impractical.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2011-06-06 15:08:51 CEST