Roy Tang

Programmer, engineer, scientist, critic, gamer, dreamer, and kid-at-heart.

Blog Notes Photos Links Archives About

Some background: We’re working on projects that involve projects across 2 different countries, and we’ve been using CVS. Developers in the country not hosting the CVS server will take forever to connect to the remote server, so we’ve set up this system to have 2 separate CVS servers in each country and have a sync job that keeps them in sync every hour or so.

Given this, we’re looking at migrating to a distributed version control system, mostly because we’ve been having problems with the sync job failing and the limitation that for a given set of files only one side can have the writelock for it at a time.

We’re currently looking at Mercurial for this purpose, so can anyone help tell us if:

a. Will Mercurial be a good fit for our use case above? How easy will it be for devs to make the transition, i.e. will they still be able to work the same way? etc

b. Can Mercurial support branching a specific folder only?

c. We also hold a lot of binary docs in version control, will they be suitable for Mercurial?

d. Is there support for getting the “writelock” of particular files? i.e. I want no other people to update these particular files while I’m working on them

Thanks!

Comments

a/ and d/: yes and no. Yes, a DVCS like Mercurial is a good fit for distributed development, but by nature, there is no more “writelock”, since there is no one “central server” which would be notified each time you want to modify anything.
You will pull (or check incomings) regularly from the remote repo.

b/ no, this isn’t how a DVCS works, since a branch is no longer a copy of a directory.

c/ binaries are best kept outside a DVCS (since it will be cloned around, and binaries would make its size grow too fast)
See “How is Mercurial/Git worse than Subversion with binary files?

I’m a big DCVS fan, but perhaps another option is to look at remote hosting of CVS (or Subversion) so that developers in either country have sufficiently speedy access.