Backing up locally modified and new source files

I'm wondering how other programmers are backing up changes that are not under source control yet, be it new files or modified ones. I'm mostly referring to medium size jobs - hardly worth the effort of making a private branch, but taking more than a day to complete.

This is not a vendor-specific question - I'd like to see if various products have different solutions to the problem. I'd appreciate answers referring to SVN and distributed SCCs, though. I'm mostly wondering about that latters (Mercurial, GIT etc.) - it's great that you have your own local repo, but do you back it up on a regular basis along with your source files?

Note - I'm not asking about a general backup strategy. For that, we have IT. I'm seeking the best way to kee开发者_运维百科p locally modified stuff backed-up before they are checked back into the main repo.

---

When you say:

hardly worth the effort of making a private branch, but taking more than a day to complete

I would say you are wrong. Even if it only took an hour or so to complete, I would put it under version control.

---

Work: I use Git locally on my machine and the commit to our Vault repo when i am done. I get fast branching and merging, Build Machine et all get working code :)

Home: I use Git locally, and push to another Git repo on my network when i am done.

---

I 'back up' files that are more than, say, a couple of hours old by putting them into the VCS - if I might need to get back to this point. If it is of any value (sufficient to warrant thoughts of backup) then it goes straight into the VCS. Only if it is not important enough to matter does it remain out of the VCS. And I try to ensure that the VCS is itself backed up, of course.

---

I use Mercurial for home. The repository is cloned and maintained on my two work computers. Finally, I keep a set of hg archive files on an external hard drive which is created automatically by a Python script that I wrote. The archive is based on a set of repositories kept on the "home" machine.

I'm not doing anything ground breaking here, but the chances of multiple hard drives breaking at once are not likely. Further more, it's almost automatic because I switch between my two computer periodically.

If I have a large segment of code to change, I'll make continuous small commits in a branch clone and then push back when I'm done. I prefer to have my changes segmented in small, controlled groups. The branch would inherently get backed up because the aforementioned script identifies all hg repositories and backs them all up. In short, if they exist, they are backed up.

---

Some SCC (like Vault) provides shelving.

You can publish a changeset in the repository without commiting it.