-1

There's an SVN repo hosted in a server behind multiple ISPs, and depending on the ISP connection, the admin of that SVN server changes the repo's IP address and announces "hey, our IP address changed. Please relocate all of your stuff to xxx.xxx.xxx.xxx, kthnxbye".

Most days, this isn't too much of a hassle. Just a short script that relocates all of my working copies. But on some days, the repo's IP address changes a few times a day or flip flops within a span of minutes which is work-breaking.

I have no power to tweak the network that hosts the SVN (add load balancing etc.).

How should I handle this efficiently on my end?

Like a hosts file where instead of assigning multiple host names to one IP address, one host name handles multiple IP address automatically.

Reposted from superuser.com since it sounds more like a serverfault question.

Helix Quar
  • 99
  • 2
  • 4
    Your admin shouldn't be hosting services if they can't guarantee connectivity and their connectivity problems shouldn't be solved by their end-users either. – HBruijn Jun 18 '15 at 06:19
  • @HBruijn Well said but It can't be helped. I guess what I'm looking for is a work-around. – Helix Quar Jun 18 '15 at 06:47
  • 2
    Run something like HA-proxy which queries the back-ends and can route your traffic according their availability. Configure your client to talk to the HA-rpoxy instead. - But simply move the SVN repo to a cheap VPS. – HBruijn Jun 18 '15 at 07:11
  • 2
    You should be accessing the server by hostname rather than IP address. – kasperd Jun 28 '15 at 18:21

1 Answers1

1

This is not pure client-side solution, but it can work

  1. Create IN A records in some zone, which your hostmaster can manage, on DNS-server, which is primary-DNS for your side (worse - any remote DNS under hostmaster's control) with minimal possible TTL (mandatory)
  2. Relocate your WC to this new URL of repo (name-based)
  3. On changing ISP-connection IN A must be changed according to new IP (question of effective communication of affected sides is outside of scope for current question)
  4. On repo-reconnect: after timeout not longer than TTL in worse case (your DNS-server doesn't hold the zone and must to get data from authoritative-NS) client will be able to communicate with repository
Lazy Badger
  • 3,067
  • 14
  • 13