By default Hg will not warn you about the files created, but not yet added. This can result in a situation where you have created a commit, but that commit does not include newly created files. Everything seems fine, but the push is incomplete.... and you transfer to a new machine and you're missing files, or your colleagues are confused. This happened to me a couple of times, so I looked for ways to avoid it in the future. Admittedly, it's not hard to check for status every time before a commit, but you can still forget it sometimes. I usually dealt with this with an com --amend option after realizing I forgot to hg add, but there is a saying "if something bothers you more then 3 times within a week, make sure to fix it." So, here's how.

Mercurial (Hg) is a powerful and sleek distributed version control system. It's quick and gives you the ability to do anything you'd ever want with source control. I have yet to come across a feature from the competing DVCS that you cannot do in Hg, and easier and quicker. It is an extendible platform; because it provides a base command set while more advanced commands have to be explicitly enabled. It is made to be user friendly, and makes sure you know what you're doing. Some user-made extensions can even be downloaded online and can become a part of your standard workflow. With that said, which extensions to choose and where to use them becomes a user's preference. Over the years, it seems Hg has integrated a large part of best extensions into the core distribution and all you have to do is enable them. The installation of other extensions is really simple; you just place a Python file somewhere and point to it in a config file.

How do you use a runtime class like WWW on the editor side without creating a blocking operation?

How to guerilla style Todoist app in your own browser.

If you are thinking about publishing your own Unity extension, I can give you some tips.

Code reviews and performance profiling is something you do every weekly right? Well, you should, because when the project grows unmonitored the changes will accumulate and cause an avalanche of refactoring later.

RhodeCode is one of the most popular options for hosting your own Mercurial repositories. It installs on Windows and Linux; works with hg, git and svn; offers an automated setup (even under Linux) and allows you to easily manage users and permissions without messing with configuration files and proxy scripts for Hg. Don't get me wrong, Bitbucket is great, but it allows only for 1GB storage (after that they will send you an email daily, and will cap out at 2GB). Since my last project - which was very simple - turned to be around 7GB heavy, I had a serious thought about self-hosting. RhodeCode is free for up to 25 developers which is more then fine in my case.

Today's article is going to be about a complicated topic that often gets overlooked in Game Development: Source Control. We will focus on my favorite tools: Unity Engine, Mercurial (Distributed Version Control System), SourceTree (as GUI for Mercurial) and CodeCompare (as external tool to merge files). Some of these combinations are not really well documented, so rather than rehashing documentation on my blog I will post my solution which I believe is optimal and unique.

It's no secret I'm a fan of Mercurial source control system, I use it in my Programming and Game Development projects. However, it is important to know what it is, and what it is not; there seems to be a bit of confusion about its relationship with Large files.

- "What is the best way to do X?"

- "Have you Googled it?"

- "Well, that's the problem... there are too many!"