GIT vs Mercurial

Started by
31 comments, last by Alberth 8 years, 1 month ago
another vote for git here. When I was still lost in Windowsworld, I used Source Tree as a git gui, but honestly, the git cli is so simple, the only thing one really need a gui for is to more easily inspect earlier commits. In addition to GitHub there is also BitBucket (who makes source tree) that provides free closed repos.
I'll admit git struggles with large binaries though.. :/ Never been an issue for my projects, but I onve tried to collaborate on a Unity project through git. *shudder*

However, its an important pro in my opinion that you don't need a server. Just 'git init' in a folder and add a remote when you want security, or want to collaborate.
Programmer of HolyPoly games.
Advertisement

At work we use Git with GitHub for source control. My vote goes to use a GUI tool with Git if you have no prior experience with it. Using the CLI is more powerful, but not newbie-friendly. Every time a new team member joins the team, the first thing to do is to force-push the master branch, deleting all history after his/her last pull... Yep, Git is that powerful at shooting yourself in the foot. smile.png Regarding large binary files, you might be better off using something else for that. We were forced to remove all DLLs of 3-rd party libraries from the repository and retrieve them from an artifactory instead, just to make the Git repository more lightweight. Git does not like committing too many binary files at all.

Have any of those complaining about subversion's branch/merge handling actually tried it with a version less than about 5 years old? Since SVN started noting branch and merge information in properties it has become much, much better at handling them. Haven't had any serious problems in a long time.


Pros:
- It doesn't create .svn folders everywhere.

Subversion hasn't done that for quite some time either.

Have any of those complaining about subversion's branch/merge handling actually tried it with a version less than about 5 years old?


It certainly has become much better since before but it's still very easy to land in merge-hell in my experience.

I've never used Perforce. Based on some quick looking it doesn't seem to provide significant benefit over Subversion. Is merging branches better or something?


Pros:
- It doesn't create .svn folders everywhere.
- It's more robust and is easier to figure out what to do when something unexpected occurs.
- Client specs are awesome.

Cons:
- Kind of a pain to use for personal projects with remote backups compared to git or svn. With git, there isn't really a server so much as remote locations you can push to if you want. SVN has various online hosting services. I don't know if there are any free private cloud services for Perforce due to its license. I haven't used Perforce in about 5 years, so something could be out there by now.

Assembla has free Perforce hosting (max 1 GB disk space) which is what I use for my personal project.

https://www.assembla.com/

From a slightly different point of view, some notes on maintenance of servers:

Git - A pain to set up a multi-user Git server such as GitLab and managing multi-user Git directly is quite awkward. Most people just use GitHub which is not ideal.

Perforce - Easy to set up server but works horribly with continuous integration (Jenkins / Bamboo). We changed from this because of this.

Perforce Git Fusion - A massive faff to set up but allows perforce to work nicely (via git) on Continuous Integration systems (and OpenBSD).

Subversion - My personal recommendation. Provides a single binary server which is very easy to set up. No thrills, just works. Text file config but you can use SCM Manager for web config (https://www.scm-manager.org/). SCM Manager Supports Git too but has too many more extra steps its not worth it. Works great with Jenkins and Bamboo.

Also, my friend helps run CodeBaseHQ (https://www.codebasehq.com/). You might want to check out their free hosting offers before you do decide on GitHub.

Overall, I highly recommend subversion, I actually find its branch system a bit more structured than Git. Rent a bare VPN server and just manage the svn server yourself. You can then take snapshots of the VPN virtual machine to make backups of your entire repo too.

http://tinyurl.com/shewonyay - Thanks so much for those who voted on my GF's Competition Cosplay Entry for Cosplayzine. She won! I owe you all beers :)

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.

My games are going to be art asset heavy, almost from the start, (the small games which I have made already are) so the data demands will be stacked thru the ceiling soon enough. From this thread, it seems that GIT is out. Subversion is out.

That leaves Mercurial or Peforce for me?

Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software. The better the workflow pipeline, then the greater the potential output for a quality game. Completing projects is the last but finest order.

by Clinton, 3Ddreamer


Subversion is out.

Why? It works well for binary assets. Or at the very least a lot better than GIT (or any DVCS for that matter).

My personal experience:

git:
Pros:

  • GitHub. Has a lot of good services: the best ticket system, the best free & paid continuous integration solutions, ZenHub (3rd party services that integrate to GH), etc.
  • Has good, fine-granulated history manipulation and multi-commit merging.

Cons:

  • Horrendously slow (for >= 1GB repos; or repos with many tens of thousands of files)
  • Extremely poor Windows support: Networking bugs (failure to push, failure to pull, authentication problems due to protocol issues), crashes, command line argument limitations causing commits to fail (when you have to commit many files). Substantially slower than its Linux/OSX counterparts.
  • Really poor handling of EOL when compared to Mercurial. autocrlf brings a lot of problems.
  • The repo can bet left itself in an inconsistent state and when that happens it can be hard to leave it in a working state again, sometimes being quicker to just clone the repo again from a working origin.
  • No good UI other than SourceTree (which is relatively slow)

Mercurial:

Pros:

  • TortoiseHg is really good and works identically in all platforms (also there's SourceTree, but it's still slow as with git)
  • Windows support on par with other OSes.
  • Relatively good EOL handling.
  • Really fast.

Cons:

  • No GitHub
  • Lacks advanced history manipulation or branch merging system. Sometimes this is a blessing, sometimes this is a curse. Using extensions to do history manipulation (other than strip) is often a bad idea.

Overall I strongly prefer Mercurial. TBH, if it weren't for GitHub, I wouldn't even consider git.

Github has actually been working on a git extension for large data files. They support it on their system, as well as on Gitlab. I don't know about whether Bitbucket supports it though.

You can find the git large file support extension here: https://github.com/github/git-lfs

This topic is closed to new replies.

Advertisement