Wednesday, June 25, 2008

Mercurial v.s. Subversion

This post is not quite accurate, strictly speaking

I had been using subversion and I started using Mercurial. Mercurial is one of distributed version control systems. In Mercurial, repository informations are distributed to each developer's environment, i.e. local machine. So each has its own repository and you can merge repositories to share changes done by multiple developers. (A repository is a place or data to hold/manage source code. In subversion, it usually exists on a server)

Mercurial has many advantages over subversion but it has also downsides.

Pros:

- You can commit changes without connecting to the server.
You can commit changes to the local repository, which is at the same directory where the source code exists.

- You can commit changes locally without affecting your co-workers' works
If you commit changes to the local repository and do not reflect it to the shared repository, others don't have to know your changes. So you can commit whenever you want without worrying about stopping people's works by your bug.

- Repository location is relocatable
You can clone a repository as many times as you want.

- Making branches, merges are fully traceable
When you make a branch, the branch knows where it is forked from.

- Commit is fast.
It doesn't need server communication.

- Written in Python
Easy customize

Cons:

- To share your changes to others, you need to update everything.
you'll often need to
1) commit your modification to the local repository
2) reflect your co-worker's changes to your repository.
3) merge them
4) if there's a conflict, resolve it
5) commit
6) Reflect your repository to the shared repository.

- Changes between you and others can be big.
It may take a long time until a conflict gets unrevealed after it's been created.

- Ability of local commit can make people not tempted to share their works for a long time
A bad developer may keep their changes not being shared for a year.

- Not good at binary differencing,
A repository can be big

- You need to have a full size of repository clone in the local disk
It takes lots of disk space if the project is large
(but one guy will try to implement partial cloning this summer. hurrah)

- Cannot commit an empty directory
To do that, you need to make a dummy file in a directory, or write a script to make an empty directry. I think it's important. As long as you version control only source codes it won't be a big problem, but when you start managing data that is associated with the sources, it becomes a problem. What if we want to include an example Maya project?

- More complicated than subversion


These are what I'm seeing now. There will be lots of other pros and cons.

No comments: