When you encounter Killed by signal 15. during svn up operations using svn+ssh, it typically indicates a SIGTERM was sent to your process. This is different from segmentation faults (SIGSEGV) or other fatal signals.

• Server-side timeout configurations
• SSH session limitations
• Resource constraints (memory/CPU)
• Network interruptions

First examine your SSH server settings. Many hosting providers implement session timeouts:

# Check SSH server timeout settings
cat /etc/ssh/sshd_config | grep -i timeout

# Common relevant parameters:
# ClientAliveInterval 300
# ClientAliveCountMax 2

Try these adjustments in your SVN client environment:

# Increase SSH connection persistency
ssh -o ServerAliveInterval=60 user@svnserver.com

# For SVN+SSH, modify your config:
[vim ~/.ssh/config]
Host svnserver.com
    ServerAliveInterval 60
    TCPKeepAlive yes

When working with large repositories:

# Try updating in smaller chunks
svn up --depth=immediates
svn up --depth=infinity subdirectory

# Alternative approach using checkout:
svn co svn+ssh://repo/path@HEAD --depth=empty .
svn up trunk

To identify where the termination occurs:

# Run SVN with debug logging
svn up --username yourname --password yourpass -v --config-dir /path/to/config

# Alternative with SSH debugging:
svn ls svn+ssh://repo/path -v --config-option config:tunnels:ssh="ssh -v"

If you have server access, check resource usage during operations:

# Monitor memory usage
watch "free -m; echo; ps aux --sort=-%mem | head -10"

# Check process limits
cat /proc/$(pgrep svnserve)/limits

For large repositories experiencing frequent timeouts:

• Consider repository pruning (svndumpfilter)
• Evaluate switching to HTTP/HTTPS protocol
• Implement svnsync for local mirroring

When you encounter "Killed by signal 15" during svn up operations using svn+ssh, this indicates your process received a SIGTERM (signal 15). This typically happens when:

• System resources are constrained
• SSH session timeouts occur
• Remote server actively terminates the process

Here are the most frequent cases I've encountered:

# Example of verbose SSH output that might reveal the issue
$ SVN_SSH="ssh -v" svn up
...
debug1: client_input_global_request: rtype keepalive@openssh.com want_reply 1
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
Killed by signal 15.

The remote server might be killing idle connections. Try these SSH client configurations:

# In your ~/.ssh/config
Host svnserver
    HostName your.svn.server
    User yourusername
    ServerAliveInterval 60
    ServerAliveCountMax 5
    TCPKeepAlive yes

Large checkouts might hit memory limits. Try these approaches:

• Update in smaller chunks: svn up -r HEAD:1000 then svn up -r 1001:2000
• Use --non-interactive flag to prevent potential terminal issues
• Increase memory limits on the server if you have admin access

For unstable connections:

# Use these SVN client settings in ~/.subversion/config
[tunnels]
ssh = $SVN_SSH ssh -C -o CompressionLevel=9 -o ConnectTimeout=30

If issues persist, consider:

1. Using HTTPS instead of SSH if available
2. Tunneling through a more stable connection
3. Setting up a local SVN mirror for large operations