Git, Mercurial or Bazaar - which do you use most?

[jacmoe]

You sure sound like a fanboy, Betajaen.

As a subversion user, Mercurial makes perfect sense - Git doesn't. It bites you in the rear, if you're not careful.

< alright - I'll stop now >

[betajaen]

You sure sound like a fanboy, Betajaen.

Le Sigh.

There was another thing I wanted to say about Git and GitHub is; you don't need to download Git to download a Git Repo. GitHub has a wonderful, "download" button which will get the last commit and zip it up for you. It's not exactly amazing, but it's better to your intended audience than asking them to download a piece of software to download your source code.

I mean downloading a piece of software, which downloads a piece of software? Sounds a bit crazy.

[Devil N]

Don't forget that Git is quite popular with the Mac crowd now, particularly the Rails/Ruby developers. When writing the wiki code for NxOgre.org using sinatra as a framework, one of the amazing examples was creating a wiki using git as a backend for tracking and history. The implementation was really simple, and now NxOgre.org uses a Git backend to manage revisions of the pages - the actual ruby code for NxOgre.org is one file.

Github is the biggest reason why I switched to Git in NxOgre. Previously, I used Subversion for the reason that Ogre does and everyone else did at the time. I suppose I switched to Git for the same reason. The problem with Subversion was that I wasn't making enough commits, usually they would be a month old and in huge updates. Unfortunately NxOgre users at the time, got used to this and declared these releases as stable point releases.

The problem I was having with Subversion that I didn't have a repostiory that I could play with my hands, it was on server somewhere in the middle of America. Setting up a local SVN server was difficult and interfered with my workflow. Git on the other hand, I have the master repo. It's on my harddrive, there's no extra software running. No intrusive background process.

Instead; All the needed information contained in the ".git" directory in the NxOgre directory. I didn't have to install TortoiseSVN. I have a shortcut in the NxOgre folder to load up Git GUI. It automatically recognises my changes, I select which files to commit and a short message of the changes. I click the commit button to commit to the local repository then I click "Push" to commit the changes to GitHub. It uses SSH and my public key for authentication, so no passwords. It's so easy my Cat could do it.

Git is easier to me than Subversion. It encourages myself to do small updates in code, for small commits. It also allows me to go of somewhere and make a pigs ear of a branch without effecting the users or directory structure (the new Detritus branch). GitHub is excellent, it allows me to track back in time. It allows users to reference a commit and show the changes for that commit only - which is brilliant for debugging. Not only that it formats my textile files for me. I wrote python script to scan the source code, strip out the comments and generate the API documentation for me - like how doyxgen does it, but faster and can be run from a batch file. People don't usually have a textile parser on their computer, but Github does.

Don't get me wrong. I'm not a Git fanboy, I don't hate Subversion. I just find Git less intrusive on my computer, it fits into my workflow better and I like Github.

For some reason that story does not make a lot of sense to me. My main problem with Subversion and other centralized VCS systems is that I'm making too many commits, even when it's experimental or unfinished code that shouldn't really be published. Sometimes I want to quickly upload my work, when moving to a different workstation for example, without actually committing to the central repository. That's where distributed VCS systems make sense to me.

Where exactly your central repository is located is a choice you make yourself. If you want your code hosted externally, you can choose something like GitHub, Sourceforge, Google Code, or any of the other gazillion project hosting services around. If you want more control over your repository, you can host it on a private server, be it locally, on a dedicated machine or on a VPS somewhere in the cloud. The choice between VCS systems is moot in this one.

Concerning TortoiseSVN, it's not a necessity when using Subversion. You could even stick with just the command line if you really want to. TortoiseSVN is just one of many SVN clients that makes use of the regular Subversion infrastructure (i.e. the contents of the '.svn' directory). It just so happens that TortoiseSVN also integrates with Windows Explorer, which makes it easily accessible. The Git workflow that you describe still requires a client application, the only significant difference being that you access with a shortcut instead of a right click.

Your last paragraph only highlights the major difference between centralized and distributed VCS systems: a DVCS "allows you to go off somewhere and make a pigs ear of a branch without affecting the users or directory structure". All the other features you mention depend on your choice of repository hosting. For example, Sourceforge also allows you to reference a commit and show the changes of that commit. If you host your projects yourself, you can get all the functionality you want by installing the appropriate Apache extensions.

I'm not saying that you should have stuck with Subversion or anything, switching to a DVCS clearly has advantages over the old centralized solutions. It's just that your arguments concerning your workflow don't have much to do with the choice of VCS, but rather with how you choose to use them.

[betajaen]

I suppose what I was trying to say is; Git is more gentler on my workflow and computer than SVN has ever been.

I don't want a background process, or a shell extension. I want a program that I can run which using no configuration files scattered around my computer, or a big database to understand what my changes are and look after them. I also want my changes to be mirrored on a central server. I'd like a GUI program which can handle 99% of my needs managing the history, and additional tasks. If it can't then then additional tools via the by command line.

Git fits my needs perfectly, and I like Software to be neat and gentle.

[jacmoe]

<angry rant>

I really hate that lousy pile of shit which is TortoiseGit.
It (supposedly) looks pretty, but it's totally flaky underneath. It sucks memory, and it hangs, fails, dies.. Not exactly production quality work.. Much of this is maybe due to Msys Git.
And trying to make this pile of junk work with ssh keys - bah. Forget it.
I've booted into Linux more than once because of Gits crappyness on anything other than Thorvald's OS.

</angry rant>
Ah, I feel a lot better now.

[aerique]

<angry rant>
I really hate that lousy pile of shit which is TortoiseGit.
It (supposedly) looks pretty, but it's totally flaky underneath. It sucks memory, and it hangs, fails, dies.. Not exactly production quality work.. Much of this is maybe due to Msys Git.

I liked TortoiseCVS and -SVN but the Git version is shite. I've been using MSYS Git for a good while now and I like it since it's pretty close to how I work in my main development environment (Unix). Just "Git Bash here" and that's it.

Also I recall reading comments about Git not being used in big projects but how can the Linux kernel not be a big enough project? It's exactly why Git was made since all other VC systems they had tried failed.

edit: I see the last paragraph is not quite correct after reading the Git Wikipedia article. Git's author modelled it after Bitkeeper which was the only VC system he liked.

[CABAListic]

Heh, from the Wikipedia article, I find this the most interesting passage:

Git was originally designed as a low-level version control system engine on top of which others could write front ends, such as Cogito or StGIT. However, the core Git project has since become a complete revision control system that is usable directly.

If it was (originally) never meant to be used directly, that might well explain why its command syntax is so different from everything else... Maybe they should have stuck with that approach.

[sinbad]

<angry rant>

I really hate that lousy pile of shit which is TortoiseGit.
It (supposedly) looks pretty, but it's totally flaky underneath. It sucks memory, and it hangs, fails, dies.. Not exactly production quality work.. Much of this is maybe due to Msys Git.
And trying to make this pile of junk work with ssh keys - bah. Forget it.
I've booted into Linux more than once because of Gits crappyness on anything other than Thorvald's OS.

</angry rant>
Ah, I feel a lot better now.

Strange, I honestly don't recognise the sources of this rant. I came to TortoiseGit expecting it to be bad, but actually found it worked great. It's never hung or crashed for me yet. What problems have you had with SSH keys? Mine worked out of the box. I just pointed it at my PuTTY key (helpfully linked on the clone dialog) and Gitorious, which I'm testing on right now for my remote experiments (I intend to test GitHub too, but I like that Gitorious' code is open source), just accepted it first time, secure pushes worked fine, completely painless. So far I've done the majority of my testing in Windows (TGit and command-line) because I wanted to expose any weak spots, but so far it hasn't raised any issues at all, surprisingly.

And yes, I'm talking about Git a lot right now, that's only because that's where I am in my detailed evaluation right now and doesn't represent a final preference. Once I've finished testing with Git I'll repeat everything with Mercurial and see how it compares (I started with Git since it was the more complex one, better to get the learning out the way early). I might not bother with Bazaar since this review takes a lot of time and it seems to have little community support. What I've found so far is that Git is a lot nicer to use in practice than it appears on the surface, and this is from someone who was very biased against it to begin with.

[betajaen]

So far I've done the majority of my testing in Windows (TGit and command-line)

If your going to try it out in Windows. Please have a peak at msysgit. I had initially had doubts when I first downloaded it, but was presently surprised on how well it integrated neatly into Windows. The Git GUI program although a bit simple to look at, is quite powerful little application, and you have the full wealth of git commands at commandline without the need of installing cygwin or some obscure shell program.

[mkultra333]

I started using msysGit and TortoiseGit two days ago, and was using no versioning system prior to that. I had used subversion just to download code, but an initial attempt at using svn on a local project was a mess so I never bothered.

After initial mild frustration, I was surprised how easy it was to get up and running with msysGit and TortoiseGit for a local project. I barely read any documentation or manuals, but got the hang of local commits, reverts and branching pretty quickly. I like how there's just the one .git folder too, instead of annoying svn folders everywhere. I will admit though, I've only just started and I've not attempted anything complex.

I was oblivious of all the fuss with the Git-AntiGit crowd. Initial impressions are quite good. There's been a lot of complaint about "Git fanboys" in this thread, but it looks to me like there are some fanatical Git hateboys too.

Anyhow, whatever Ogre ends up using, I hope it's at least as easy to come to grips with as I've found Git to be.

[aerique]

What I've found so far is that Git is a lot nicer to use in practice than it appears on the surface, and this is from someone who was very biased against it to begin with.

I've read this whole thread but I really don't understand what puts people off from Git initially. What's the exact cause?

[xadhoom]

Checkout Sinbads Blog about Git/Mercurial...

[mirlix]

I've read this whole thread but I really don't understand what puts people off from Git initially. What's the exact cause?

I simple tried both, mercurial and git for personal projects. Git gave me some strange error messages and didnt work out in the end so we switched to svn back because everyone on the team new it and we had little time to spend learning a new version controll.
On a different project we used mercurial and it simply did what we wanted. Merging an sometimes be a bit strange but with a bit off experimenting anything could be solved in under 5 minutes.

Of course I know if you spent more time reading how the different systems work you probally will get the hang of it, but thats simple time I dont want do spend when I have a equal software where I dont need to read the whole manual to use it.
For both systems I use tortoise, so I dont have any experience messing in the shell.

[Jorgon]

I am curious, how much of Steve's problems come from using sourceforge? I run my own svn server on my own website, and it seems rock solid. Granted, I do not have the codebase or needs that ogre has. I can see how moving to DVCS would be a great step forward.

[sinbad]

I am curious, how much of Steve's problems come from using sourceforge? I run my own svn server on my own website, and it seems rock solid. Granted, I do not have the codebase or needs that ogre has. I can see how moving to DVCS would be a great step forward.

The performance is definitely a lot to do with Sourceforge. But also when merging between branches Subversion regularly screws up, not properly setting the properties it needs to do line ending conversion properly, sometimes mysteriously forgetting to add or delete files from the other branch, and getting in a right mess when bi-directional merges are needed. I've had it screw up its own checksums in the working copy before too, requiring manual fixing. For simple merges it's fine, but for anything complicated it just seems to randomly explode and require lots of manual fixing up, which frankly I'm getting tired of. It's been fine for me too on my local servers where I have a simple setup, but for open source when you want to create many branches and merge lots of external changes in, it can really be a pain. There's nothing wrong with Subversion for many projects, but the more complex things get, the worse it seems to cope.

If your going to try it out in Windows. Please have a peak at msysgit.

Yeah, it's mandatory when using TortoiseGit anyway and so is providing my command-line version. I'm using both right now during my evaluation.

I've read this whole thread but I really don't understand what puts people off from Git initially. What's the exact cause?

For me it was mostly the attitude. Anti-SVN, anti-Windows, using different nomenclature to every other system I'd used for seemingly no reason (reset instead of revert etc). The rhetoric from much of the vocal fan base and much of the documentation is very hard-line, and very arrogant - sort of like "Git is awesome in absolutely every way, and if you disagree you're a loser". That annoyed me, and reminded me of the Linux communities of old.

But, as it happens it seems that people have quietly been making Git work ok on Windows, and have written nice tools like TortoiseGit and eg to make day-to-day use quite reasonable. You wouldn't know it from the rabid talk that tends to orbit Git and some of the woefully fanatical advocates, but there seem to be enough pragmatic people around it to have tempered its original hardcore stance to something that's usable for normal people too. So, just like Linux then.

Personally I'm ignoring all the people that have an axe to grind (pro or anti-Git) and just evaluating based on real, everyday usage. Seems the best way.

[Klaim]

Did someone here had experience with using "externals"-like features in git and mercurial? I didn't yet tried (still in basic usage) but it might be very interesting for some projects with several external libs, for updating them easily than having a special copy in the project repository. The SVN "externals" is really far from perfect (I tried it a lot but in the end I went back to having a copy of ogre in my project repository), so maybe they did things better in git/mercurial?

[aerique]

Well, this is cute: www.jukie.net/~bart/blog/pimping-out-git-log

[jacmoe]

Strange, I honestly don't recognise the sources of this rant. I came to TortoiseGit expecting it to be bad, but actually found it worked great. It's never hung or crashed for me yet. What problems have you had with SSH keys? Mine worked out of the box. I just pointed it at my PuTTY key

Actually, I just fixed it.
I was a fool, and chose to use PLink, instead of plain SSH. It's supposed to be easier, but it isn't..

So I installed (msys)Git, using the following installation options:

1. Use Git Bash only.
2. Use OpenSSH.
3. Use Unix style line endings.

And installed TortoiseGit, not using PLink, but plain SSH.

Now I can use my (Putty generated or Git Bash generated) OpenSSH keys with TortoiseGit.

So, ignore me.
I'm off to visit Mr. and Mrs Git in Dulwich. See ya!

[sinbad]

What problems have you had with SSH keys? Mine worked out of the box. I just pointed it at my PuTTY key

Actually, I just fixed it.
I was a fool, and chose to use PLink, instead of plain SSH. It's supposed to be easier, but it isn't..

I'm using TortoisePLink here with no issues. I've accepted all the defaults for everything in fact

Classic Python sketch though

[lf3thn4d]

Whatever the case, no mecurial please. As far as I know, Mecurial doesn't support resume updates. This is a big issue for me as I have horrible connection here that breaks every now and then.

P.S. No I can't switch to other ISP. There is only ONE ISP here. I've got no choice.

[jacmoe]

Whatever the case, no mecurial please. As far as I know, Mecurial doesn't support resume updates.

Of course it does.
If a clone interrupts due to a flaky connection, as simple hg pull will resume it.

If Sinbad decides on Mercurial, Ogre could offer Mercurial bundles for download, for those unfortunate people with limited net access.
Like Mozilla is doing:
http://www.rumblingedge.com/mozilla-mercurial-source-bundles/

So that, my friend, is not an argument.

[sinbad]

For info, I just posted an update on my blog concerning the conversion process from Subversion to Git and Mercurial for the full-size OGRE repository.

http://www.stevestreeting.com/2009/10/2 ... rsionland/

[xavier]

Well I think I see the primary reason you are dissatisfied with SVN merging:

Also of note is that the source repository is still at Subversion 1.3

It's too bad that the upgrade process is so onerous at SF -- at my last place when we upgraded it was relatively painless, but that was on a LAN of course. That said, 1.5+ offers better support in terms of merging.

[lf3thn4d]

Whatever the case, no mecurial please. As far as I know, Mecurial doesn't support resume updates.

Of course it does.
If a clone interrupts due to a flaky connection, as simple hg pull will resume it.

If Sinbad decides on Mercurial, Ogre could offer Mercurial bundles for download, for those unfortunate people with limited net access.
Like Mozilla is doing:
http://www.rumblingedge.com/mozilla-mercurial-source-bundles/

So that, my friend, is not an argument.

Hmm.. really? I did seem to have a lot of problems the last time I tried to grab Moz build to test their new JS code. Considering that my connection kept breaking within minutes/seconds, I believe this is indeed an issue. Compared with svn where it's per-file update, mecurial repository takes ages to update. I suspect Git works a lot better here being that they use diff based updates hence file size should be smaller. Anyways, just my personal opinion from a place where ISP is just pure shit here (broadband that acts worst than a dial-up).

[sinbad]

Well I think I see the primary reason you are dissatisfied with SVN merging:

Also of note is that the source repository is still at Subversion 1.3

Yeah, I'm not sure about that - having used 1.5+ for all my other repos, in practice the merging in 1.5 is pretty much identical in behaviour to svnmerge which I've been using for older repos for some time. The problem is not with the tracking of the merges (which is what 1.5 adds), it's how the core merge function behaves with certain types of change - particularly adds, deletes and property changes, which seem regularly flaky, even with a svn 1.6 client and an explicit merge command naming the revisions in question. All the 1.5 repo does is allow the tracking to be done server-side so less has to happen on the client - the actual results still a regular svn merge command at the end of the day, and it's that which I've had regular problems with even when doing the 'tracking' myself.