The original message was received at Tue, 23 Oct 2007 07:26:11 -0400
from office.home.jay.fm [192.168.1.151]
----- The following addresses had permanent fatal errors -----
<dev@subversion.tigris.org>
(reason: Can't create output)
----- Transcript of session follows -----
procmail: [2596] Tue Oct 23 07:26:16 2007
procmail: Assigning "LOGFILE=/var/log/procmail"
procmail: Opening "/var/log/procmail"
550 5.0.0 <dev@subversion.tigris.org>... Can't create output
Reporting-MTA: dns; server.home.jay.fm
Received-From-MTA: DNS; office.home.jay.fm
Arrival-Date: Tue, 23 Oct 2007 07:26:11 -0400
Final-Recipient: RFC822; dev@subversion.tigris.org
Action: failed
Status: 5.3.0
Diagnostic-Code: X-Unix; 73
Last-Attempt-Date: Tue, 23 Oct 2007 07:26:16 -0400
Subject:
Re: New (1.5) feature questions -- things we need to address before a
release can happen
From:
Jay Levitt <lists@shopwatch.org>
Date:
Tue, 23 Oct 2007 07:25:59 -0400
To:
Jack Repenning <jrepenning@collab.net>
CC:
Karl Fogel <kfogel@red-bean.com>, David Summers
<david-dated-1193541277.a83b35@summersoft.fay.ar.us>,
dev@subversion.tigris.org
On 10/23/2007 2:25 AM, Jack Repenning wrote:
> On Oct 23, 2007, at 11:38 AM, Karl Fogel wrote:
>
>>> Karl had some suggestions about a couple of different ways to fix it.
>>>
>>> Is this something that would be "easy" to do?
>>
>> ...
>> An alternative (for less load on the slave) is for the client to
>> notice the particular error from the slave, and contact the master
>> itself. But that might have working copy metadata implications.
>
> Or even network topology challenges. It would be easy to set up a
configuration where the clients are firewalled away from the master, can
only speak to the slave (and only the slave can speak to the master).
I'm not sure I believe it would be a good idea: basically you're putting
your server into the network DMZ, but your server's the data you want
best guarded, not least! But just 'cause I don't think it's a useful
idea does not mean some crazy IT manager won't do it. Indeed, simply
because it's called a "Proxy" might make this more likely, as that word
is also widely used for "the computer in the DMZ that the clients talk
to in order to get to the Internet."
Actually, that probably won't be all that uncommon, if you think of a
company with multiple data centers, instead of "inside/outside". I can
imagine a network where your west-coast and east-coast data centers can
talk to each other, but your west-coast office can only talk to the
west-coast data center, and the east-coast office can only talk to the
east-coast data center.
Jay Levitt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 23 13:50:21 2007