On Sep 14, 2013, at 18:22, Dan White wrote:
> Is is possible to push a checkout or update from a subversion server to a
> remote client ?
Nope, clients must initiate updates. Servers don't keep any record of who
checked out or updated what (expect possibly in logfiles).
Guten Tag Dan White,
am Sonntag, 15. September 2013 um 01:22 schrieben Sie:
> Is is possible to push a checkout or update from a subversion server to a
> remote client ?
As said, there's no such mechanism in Subversion, but if you describe
your problem more detailed, one can suggest workarounds.
The issue is that the client end of the transaction is in a DMZ
A connection from a DMZ to one’s internal network is a very high security risk.
What I was hoping for was a way to define a very specific connection from the
Subversion server to the DMZ client (push).
This is considered to be a much
Guten Tag Dan White,
am Sonntag, 15. September 2013 um 17:32 schrieben Sie:
> Searching for a solution found one possibility: Check out a copy on
> the subversion server and then rsync to the final client destination.
How is rsync more secure than accessing the client using SSH and use
svn update
On 15.09.2013 01:22, Dan White wrote:
> Is is possible to push a checkout or update from a subversion server to a
> remote client ?
You could try svnpubsub:
http://svn.apache.org/viewvc/subversion/trunk/tools/server-side/svnpubsub/
It includes a client implementation called "svnwcsub" which doe
> Guten Tag Dan White,
> am Sonntag, 15. September 2013 um 17:32 schrieben Sie:
>
> > Searching for a solution found one possibility: Check out a copy on
> > the subversion server and then rsync to the final client destination.
>
> How is rsync more secure than accessing the client using SSH and
On 9/15/2013 11:32 AM, Dan White wrote:
The issue is that the client end of the transaction is in a DMZ
A connection from a DMZ to one’s internal network is a very high
security risk. What I was hoping for was a way to define a very
specific connection from the Subversion server to the DMZ clien
The described solution is one we already use within our network space, but Security will not allow a connection from DMZ to the internal SVN server.It violates the whole purpose of having a DMZ in the first place.“Sometimes I think the surest sign that intelligent life exists elsewhere in the unive
On Mon, Sep 16, 2013 at 2:53 PM, Dan White wrote:
> The described solution is one we already use within our network space, but
> Security will not allow a connection from DMZ to the internal SVN server.
> It violates the whole purpose of having a DMZ in the first place.
>
There is always the tric
On Mon, Sep 16, 2013 at 4:51 PM, Les Mikesell wrote:
> On Mon, Sep 16, 2013 at 2:53 PM, Dan White wrote:
> > The described solution is one we already use within our network space,
> but
> > Security will not allow a connection from DMZ to the internal SVN server.
> > It violates the whole purpos
On Tue, Sep 17, 2013 at 7:11 AM, Nico Kadel-Garcia wrote:
>>>
>> There is always the trick of ssh-ing a command from inside the
>> firewall to the DMZ box that (a) sets up port-forwarding and (b) runs
>> the svn command as though the repo is on localhost. Technically, and
>> from the firewall's p
> First, it is kind of foolish to assume that anyone with an
unrestricted ssh login doesn't have complete access to all the data
that account can read (or reach from either side of the connection),
but also note that this is the opposite case, where the connection
origin and tunnel destination are
12 matches
Mail list logo