On 6/5/11 10:58 PM, Nico Kadel-Garcia wrote:
On Sun, Jun 5, 2011 at 10:19 PM, Les Mikesell<lesmikes...@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
lesmikes...@gmail.com
