If you don't use branches, you don't worry about merging at all; just keep doing the commit/push and pull. If you are on branches, then Code (Text): git checkout [branch to merge into] git merge [branch to merge] is all you need to do, and git (and Mercurial — but I've never used it so IDK) are usually better at doing merging than svn (which is why your worker friends call it sucking cock).
In both Mercurial and git, the merging programs can be customized because they are essentially scripts operating on top of the base repository interface, though git recently had most of them ported to C from Perl. In theory, it would be possible to write replacement merging programs. In reality, it just isn't worth it most of the time. Merging algorithms can get pretty complex, especially for revlog-based tracking (which Mercurial uses). Combined with the high number of edge case algorithms added to merging programs to help make merging easier, it would be pointless to write a new merging program. However, extending the existing merging programs is a far more realistic option and it has been done from time to time.
Given that this topic has died, can we at least narrow things down? I'd prefer Mercurial simply because it'd be easier to transition to. Is there any major argument for Git specifically over hg?
Going by the first post and what I've heard elsewhere, I'm being given the impression that Mercurial support is better on Windows and Git support is better elsewhere. So I guess it's ultimately a matter of which platform do you wish to support more.
I'd choose Hg, since I develop programs on Windows, for Windows. + - And I found a library so I can rewrite my IRC bot.
Among people that actually commit to the SVN: Andlabs, Flamewing, and Hivebrain don't care; Scarred Sun and I want Hg.
Not that it's going to happen, how about a poll with Git and Hg being the sole options? It'll force the SVN users to make a choice, or just abstain from voting. Probably won't work. Also, still going down on Hg here. EDIT: Now that I looked at the poll again, I guess my suggestion is really pointless based on only 4 people wanting to stay with SVN.
If the performance bottleneck for SVN is the result of the web interface and not the VCS itself, why not use both Git and Hg and attach the web interface to the lighter of the two sides? http://hg-git.github.com/
Wait seriously? ...I like this. It'll keep everyone happy. Git users can use Git, Hg users can use Hg. Cool suggestion, sonicblur!
Except.... hg-git doesn't actually work with repositories outside of github very well. I don't know why, but it doesn't. I've certainly tried! Also, hg-git doesn't work the way you seem to think it does. It doesn't emulate the full host interface that git uses, it just emulates enough of the basic protocol that you can do basic pulls and pushes, and unfortunately it is brittle as heck. I can't even get hg-git to properly switch branches or handle repository merging. It won't work right.
How would I go about downloading the entire svn repo, including all history? Or would I need to grab it off the server itself?
Yes but (apparently, as someone else tested it) running git-svn directly to the server didn't work (and is a bad idea anyway, apparently)...
Hello I am the reason the server messes up half the time please find a suitable replacement I have tried to convert the SVN to git in the past and it chokes on errors. I'm really tempted to just take a snapshot of the current revision and go from there on either git or hg.
Exasperated by how MSYS fails to handle Unicode, I decided to give Cygwin a try. The Cygwin libraries work with UTF-8, just like Linux does by default on most systems, so Cygwin-based applications automatically support Unicode. In particular, I tried git in Cygwin, and it works perfectly when I push a repository to Github: file names and commit messages are displayed correctly. I suppose installing Python and Mercurial in Cygwin would lead to the same results without having to use the fix-utf8 extension, but now that git works well with Unicode, I'd rather we switch to git. :P Scarred Sun, if you can't import the history from the svn repository into the new git/hg repository, would it be asking too much to keep the svn repository online (but not WebSVN), read-only, so we can retain that history? Alternatively, there's probably a way to make the whole repository available without keeping an svn server up.
That requires installing Cygwin and all the requisite crap it wants... I really don't think people want to do that just to pull from the repo...
I'm sure we (I?) could create an installer with the bare minimum (unless that already exists), for those who wouldn't otherwise use Cygwin. By the way, I tried git gui, and it sadly has some encoding issues. The file names and commit messages are processes using the system's ANSI code page; however, adding files with that wrong encoding seems to work just fine (it calls the git program behind the scenes). The only issue would be if you typed a commit message containing characters outside of ASCII. Maybe I could try making a Cygwin-based shell extension...