Irrlicht Engine

http://www.ogre3d.org/2010/03/21/ogre-h ... -mercurial

Any comments, discussion? Does anyone think it would benefit Irrlicht to use something like Mercurial instead of SVN? DVCS are becoming very popular lately, and using one with Irrlicht may solve some of the issues the developers are encountering (Having to create a branch for every major add-on and then merging them again).

On the other hand I think that Irrlicht's dev team is fairly small and doesn't require all this complexity. The time it takes to convert the current system could be put to better uses also.

I've switched all my private projects to Mercurial already some time ago. But I've only started working with other people together recently and still learning to avoid some troubles (and occasionally running into one).

I think switching to Mercurial would be worth it. Right now patch-management means that every few weeks hybrid has to merge all patches from the branches to trunk and while doing so we get each time one fat update in the branch messing up it's history and making it very hard to find single changes without browsing back to the branches. Mercurial works with patches instead of versions, so it would allow merging while keeping the history intact.

Also certainly it would make it easier for other people to develop independent and exchanging patches with them.

So I am for switching at some time - the basic model of mercurial is just better than that of svn as far as I can see it (but I would prefer getting some more experience with hg before doing the switch - I still run in too many problems in my daily work because I don't know all the corners yet).

Also, code management needs to be much more active. And at least I don't want to invest all the time into repository maintenance - at least not more than now. The problem is that with distributed systems, every commit is its own branch. And everyone is fine to work on one or the other. Even though merging one into another is simpler, you still need to know which change is where. And not only that, you also need to document and communicate that.
BTW: git is also an alternative. But IMHO both have the same chances to lose code somewhere in one or the other branch.

I suppose with "each commit is its own branch" you mean that hg commit only changes your local branch. But you can still have a central server like svn. You can push your changes from your local branch to the central branch with hg push (and hg pull to update it from a central server). So that is basically like the svn commit and svn update from svn. Only that you might have made 10 patches in the meantime locally (or maybe even some branches) and when you push one branch then all patches are send to the server. One by one, including your local history and not just your latest version as one big block as in svn.

So there is some overhead. Instead of svn commit you would have "hg commit" (for local) + "hg push" (for server). And instead of svn update you have "hg pull" + "hg update" (although that can be made into one command). More flexibility - but a little more complicated.

We still would have the same branches on the server. Only changes between them are way easier to exchange because a distributed system like mercurial does keep the patch information. It would also be possible for example that two of us just do exchange a patch. One does maybe add another change and push it to the server. Because a distributed system gives each patch a unique number the other person can now update from server and it will only give him the latest change because it finds out he already has the original patch. That's something svn can't do to my knowledge.

But as mentioned in my post above - I'm still learning to work with servers. I mostly worked locally the last year and so the server-stuff is also rather new to me.

We've been using Mercurial for a few months now, and it is worlds better than SVN. We only have two programmers here, but I've heard Mercurial is supposed to scale very well. We have it set up where there is a central server and we both pull/push from/to it, and so far it has gone without incident. (Whereas SVN tends to eat its self alive in my experience.

Because DVCSes are generally centered around the concept of branching and merging constantly, it is very easy to do.

I would advise not to use GIT, while it has many of the benefits of Mercurial, it does not work well on Windows and is much slower and fatter. You also have to clean up the repo in GIT constantly or it goes even slower.

hybrid wrote:BTW: git is also an alternative. But IMHO both have the same chances to lose code somewhere in one or the other branch.

I would also advice against Git. While it's not bad per se, I experienced it as quite complex (there are some commands with the same name and different actions in git and svn/hg).

Mercurial's commands are much closer to svn, apart from the added push/pull, of course.

But both systems do not lose code. Git has a very code merge systems, that prevents that.
In Mercurial, every merge must be especially committed by the user. So If something is lost, it's not the systems fault. Every conflict is shown to the user to decide what to do.

As long as you have not distributed local commits, there is always the possibility to straighten the history. That's called rebase. You can unapply local commits, insert the pulled commits from the server and reapply the local changes on top of that. If you already pushed your commits to someone this can mess up the history

Imho one of the biggest advantages over svn: Git and Mercurial are much faster. While it may(!) take longer to download the whole history, than doing a single svn checkout, you'll get that time back, when working with the repo. Especially merges are extremely slow in svn.
In this lays another difference between git and hg.
Git is sometimes perceive as slow, when working with a repo over a webserver. The git protocol is optimized for use with a special git daemon.
Hg on the other hand is optimized to make as few as possible http request and is quite fast even when using the hg's cgi script.

I personally use hg for every project I do. It even has some support scripts to work with svn repos.

Does anybody know how to manage per folder access in mercurial? E.g. there are two groups: artists and programmers, and artists are not allowed to read code. Is it possible via hooks, system file permissions or subrepos?

Don't know, but I'm also not sure if putting art into mercurial is really a good idea. It's optimized for source-control, it isn't good in handling large binary files. Also - if you actually have artists which also can read code that's awesome - just let 'em read it ;-)
I would ask in the #mercurial irc-channel - they are usually very helpful.

It makes life much easier if artist can make checkout of fully workable current game version from svn(mercurial?), replace some art or look at the game state and can't touch the code folders at the same time
Seems that acl extension can help, but how to modify for using with windows?

Lil Margin, I'd disagree with everything that guy said.

One: There should be no reason for committing even 1 GB of data, non distributed systems are better for giant stuff like that. Just because git can handle it doesn't mean it is useful.

Two: I do admit, Mercurial should track move/rename commands separately rather than a remove and an add, but git repos also grow rapidly unless you run garbage collection on them.

Three: If you format your entire drive you are currently running on with Linux because of a badly written command, does that make Linux bad? Also, the nice thing about a distributed revision system is general is that the backups are really redundant.


Also, Mercurial embraces cross-platformness, where with git I've felt like anything that isn't Linux was an afterthought.

I'd actually support a move to Mercurial, I've never used it myself but from what I've heard it addresses all the main problems with SVN yet doesn't marginalise casual users (ie, TortoiseHG).

It would be Hybrid's call of course, he's the main maintainer.

DtD wrote:Lil Margin, I'd disagree with everything that guy said.

One: There should be no reason for committing even 1 GB of data, non distributed systems are better for giant stuff like that. Just because git can handle it doesn't mean it is useful.

Two: I do admit, Mercurial should track move/rename commands separately rather than a remove and an add, but git repos also grow rapidly unless you run garbage collection on them.

Three: If you format your entire drive you are currently running on with Linux because of a badly written command, does that make Linux bad? Also, the nice thing about a distributed revision system is general is that the backups are really redundant.


Also, Mercurial embraces cross-platformness, where with git I've felt like anything that isn't Linux was an afterthought.

Found the link on a blogpost and since it was related to this post i post the link

I've made some bad experience with git so far, so I'm very cautious with those tools. The most problematic thing that I see is that the code base can easily branch up into many different heads without intention.
Moreover, the intentional branching should be as separate as they are now, at least from a conceptional point. We have a clear merging strategy, which shouldn't be undermined by a too strong relation between the repositories. Otherwise you easily come up with a horrific strongly connected graph which contains all your branches in one huge code base. Ever looked at the funny git graphs from a loosely coordinated project?
We'll try to get a conclusion in the dev team first, and see how far the planning meets our requirements. This is not something which has to be made in the next days.

@Lil Margin
Yeah, I know. Just saying my opinion about the blog post

@hybrid
Yeah, I would like it if Mercurial supported intentional branches and natural ones, that way when you "hg merge" it doesn't try to merge the main branch with some named branch that was made several months ago and terminated. However, Mercurial notifies you if you are going to create a branch when you push and requires you to re-run the command with "hg push -f" to continue, so branches shouldn't get created on accident.