Have you tried TortoiseGit? http://code.google.com/p/tortoisegit/

How is that shaping up? Ready for production use? For people who don't know too much about version control?

I don't consider SVN user-friendly. It might use pretty fonts in the UI, but one wrong move, and your data is lost forever. ("svn update" is especially bad about this.)

With git, any operation I perform can be reverted via the reflog. Even reverts can be reverted! That beats any shiny UI any day.

Any more details on svn update being especially bad at killing your data forever? We've been using svn for 5.5 years now and I've never personally lost data with any of the available clients. (I can admit that svn revert does irretrievably destroy client-side changes, but that's what the command is designed to do, so...)

Consider the (common) case where you modify some files, want to commit them, get the "your tree is out of date, run svn update", run svn update, and then have the svn update merge fail; some files updated, others conflicted.

Once you run svn update, your working tree is gone forever. And often, you can't save your changes until you risk blowing them away. That is Very Bad.

In git, you can't destructively update your working tree (via a merge, anyway) until you have committed it. Once you commit, you can "git pull --rebase", fix the conflicts, and push the resulting tree. This is svn's workflow, except that if you don't like what happens you can just say "git reset --hard HEAD@{0}" and try again later.

Interesting, I've used svn for about four years and have never "lost" anything I've changed in my working copy. I've certainly had some cases of merge conflicts that were tedious to resolve, but my changes were all "there". And if you're working in a branch and commit to your branch before you try to merge back into trunk, you can always get everything back if something goes awry.

I'm not saying git doesn't handle this better; I have not tried it yet myself. But in my experience it's possible to use svn without risk of losing your changes.

When you run svn update and get a conflict on file foo.c, the contents of foo.c indeed have the conflict markers, but svn helpfully leaves you a file called foo.c.mine, which is your originally modified file.

I'd hardly call that "gone forever".

No, I'm saying your tree is gone forever. The files that did not have conflicts have already been merged, but the files that do have conflicts are in their old state. You can't always go back to the "before svn update" state.

(This is why I use mercurial.)

There's an eclipse plugin, if you use eclipse. But yea the user-friendliness of Git needs work. If you setup some web manag frontend for git it might make some parts of it easier. Using trac+git or redmine+git would allow you to at least visualize the repository.