tags:

views:

41

answers:

1

I will be moving Git repositories from an older SCM server to a new one. My main concern (other than fidelity, of course) is to minimize downtime. Here is my plan:

  1. On the new machine, clone each repository using git clone --mirror
  2. Copy over repo hooks for each repository
  3. Disallow access to old server (we use gitosis, so remove access for all users except for the new server)
  4. Move the DNS entry so the DNS alias Git users use
  5. Perform git pull for each repository on the new server.
  6. For each repository on the new server, edit the config file to remove the remote "origin" section.
  7. Turn on access to new server

Questions:

  1. Does this look right? I am specifically concerned with step #6.
  2. Is there any way to do this that will reduce downtime?

Thanks.

A: 

I would (if there are no communication possible between old server and new server):

  • bundle each repo using git bundle
  • copy the bundle on the new server
  • create bare repos
  • git fetch from those bundles in each of the empty bare repo (no origin to set)
  • copy hover the hooks
  • Disallow access to old server
  • make a last git bundle on each repo (incremental bundle, very quick)
  • copy those small bundles
  • git fetch the increment from the small incremental bundles
    </ downtime: no origin to remove>
  • restore access

If there is communication possible (through SSL) between the new and the old server:

  • I would create a special "migration" gitosis user, with all projects access
  • clone --bare each projects on the new server
  • copy hover the hooks
  • Disallow access to old server
  • make a last git fetch on each cloned repo
  • remove origin </ downtime>
  • restore access
VonC
Thanks for your help, VonC.There is connectivity between the two boxes, so I will be using clone to move the repo contents. Also, thanks for the pick-up on copying the hooks. I missed that.I think clone --mirror is better than clone --bare in this scenario since the mirror is the bare plus adding the origin to the config file. Is there something about clone --mirror I don't know which would cause you not to recommend it?
StretchyBill
@StretchyBill: `git clone --mirror` looks fine to me, already used in backup techniques like in http://stackoverflow.com/questions/1251713/backup-of-github-repo or http://stackoverflow.com/questions/1694608/making-cloned-repository-in-git-the-master/1694832#1694832
VonC