How/Where to back up local checkout of a DVCS between pushes to the server?

I'm paranoid Besides our central repository (set up with git init --shared --bare ), I have another mirror repository set up on a network drive: cd /network/drive git init --bare cd /local/repo git remote add backup --mirror /network/drive git push backup I just occasionally push to backup and since it is a mirrored repository, it's essentially just a full clone of my local repository.

I'm paranoid. Besides our central repository (set up with git init --shared --bare), I have another mirror repository set up on a network drive: cd /network/drive git init --bare cd /local/repo git remote add backup --mirror /network/drive git push backup I just occasionally push to backup, and since it is a mirrored repository, it's essentially just a full clone of my local repository.

1 for this. Your working copy should only be for very temporary commits. With DVCS one should get into the habit of committing early and often, since it doesn't break things for anyone else.

Plus, when you do you commit and push to backup, you have a named and known state as opposed to having some random snapshot of an unknown intermediate state. Having crontab etc. Do the backups will lead to one spending a lot more time on picking up the pieces, than a sane backup repository will. – Kai Inkinen Jul 22 '10 at 20:34.

Funny that you ask this question because I just had a meeting last week where I heard some people were using commit/push of non-runnable even non-compilable code on the authoritative repository just to save it! (Note: it's different from what Mark says). It appeared so wrong to me and so getting in the way of Continuous Integration that we decided to install an rsync-based backup server so that the developers would realize how complementary version control and backup tools are!

I haven't yet installed the server, but if you have a spare Unix machine with an ssh server running on it, a simple crontab could do the job, e.g. Using ssh and rsync (if you have an NFS-mounted partition, it would even be simpler): $ crontab -l # m h dom mon dow command 0,15,30,45 * * * * if `ping -c 1 machine.domaine. Com > /dev/null 2> /dev/null` ; then export SSH_AGENT_PID= "`pgrep -l ssh-agent | cut -d' ' -f1`" ; export SSH_AUTH_SOCK= "`/usr/bin/find /tmp -path '*ssh-*' -type s -user name -group gname -name '*agent*' 2> /dev/null`" ; /usr/bin/rsync -avz -e ssh --quiet /home/name/src [email protected]:/home/name/backup/src ; fi (I assume that you can log in the machine using ssh, that you have an ssh-agent running and have used ssh-add). This way, every 15 minutes, on-going work is saved, and as rsync is quite fast figuring out what has changed, it shouldn't make your workstation too slow.. In case your disk crashes, simply log into machine.domain.

Com, use your backup-ed credentials :-) and continue to work... Hope it'll help. Cheers, Christophe. = Security is mostly a superstition.

It does not exist in nature. -- Helen Keller.

Yes, you should use a normal backup system in between your commits. In fact, version control has nothing to do with backups. By this I mean that you should put a backup system in place for all employees, whether they are developers, secretaries, managers, or something else.

The desktops should be backed up regardless of whether or not they are using a version control system. I see a version control system as a crucial tool used to structure software development and to enable many people to work together. It is an essential tool when you need to maintain several parallel releases, or when you need to investigate a bug.

You may be able to use a backup system to figure out when a bug was first introduced, but you cannot use a backup system to maintain several parallel branches. So a version control system gives you more than a backup system, and a backup system complements a version control system by taking care of all those uncommitted files. Now, you will of course want to make backups of the repositories themselves.

With distributed version control this is super easy -- you just push from your local repository to another repository on a remote backup server. This way the VCS will take care of locking and ensure that you have a consistent state on the backup server.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.