views:

67

answers:

5

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 keep locally modified stuff backed-up before they are checked back into the main repo.

+1  A: 

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.

Pondidum
Having a repo on your own machine isn't a safe backup.
Guillaume
But what happens if the hard drive on your machine dies, dragging your local git repo with it into oblivion? Having a local SCC is great as long as it works, but as Guillaume says, it's hardly a safe backup (though it's definitively better than having just the source files, which an accidental override can render their modifications lost forever).
eran
but like other posters have said - even if its only an hour it goes to source control. with git this is very quick for me, so usually things are in more than one place very quickly
Pondidum
And with distributed you can come up with the most elaborate ways to push your versions to another place, and still not lose the state. Ever tried restoring backups, and find out that nothing looks like you expected and you don't know when the backup was from? With dvcs you get all the vcs benefits, but without the backup hassle
Kai Inkinen
A: 

Some SCC (like Vault) provides shelving.

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

Guillaume
I've heard of that, and IIRC TFS has a similar feature. Is it significantly easier than creating a private branch? Do you know if any of the free SCCs have that kind of feature?
eran
http://msdn.microsoft.com/en-us/library/ms181283(VS.80).aspxThis is a lot easier but you loose versioning, I don't know about free SCC.
Guillaume
+1  A: 

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.

Jonathan Leffler
There are 8 programmers on my team. If one put half-done work into the VCS and another gets the latest version of the code (or pulls, or updates, or whatever...), his codebase might contain errors. Having private branches or so would solve the problem, but how much of a hassle is that I don't know. Is that what you do?
eran
@eran: At the office, we use ClearCase; all feature development - and most bug fixes - are done on private and quasi-temporary branches with unrestricted checkins on those branches because it make sense to keep everything safe. When ready, the branch is merged into the appropriate main-stream branch. That may be direct into the main branch or a staging branch for current development, or into a post-release branch for maintenance of previously released products.
Jonathan Leffler
+4  A: 

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.

anon
I can imagine the responses I'll get for saying this, but still: I've mostly used VSS so far. I know how harmful it is considered. I know branching and merging should not be an issue, but I don't have much hands-on experience with that. So, for a two days job, say, would you create a branch and then merge it as a whole? what's your threshold?
eran
@eran All changes I make to my projects get done in a branch which I then merge back into the trunk. It doesn't matter how long the changes take.
anon
Ok. Just wondering - do you create a new branch for every change, or do you maintain a private branch, which you occasionally sync with trunk? Which SCC do you use?
eran
@eran Not sure what you mean by a "private" branch - I create a nw branch for every change. And I use SVN, but currently looking at Mercurial for use on Google Code.
anon
+1  A: 

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.

Frank V