Will mercurial work properly with multiple users using a single working copy on a share

I'm looking for a solution where I can install version control in a corporate environment in the least intrusive way possible. One possible solution I was considering was getting mercurial set up on each of the windows desktops and just setting up working copies of repos on the share. So there would be no server installation of mercurial. Obviously this doesn't solve multiple users on the same file at the same time but that's not a problem we are trying to solve. And this isn't backup, but then again version control isn't supposed to be backup. Plus we have plenty of backup.

Would this setup just work? Will usernames in the commit logs be recorded properly. Or would everything appear to be committed by the same user? Anyone have any experience with this setup?

Yes, you can do what you suggest. Modern versions of Mercurial don't really care where the working copies are stored — they can be stored on a local disk or a network filesystem.

We've had some problems in the past (before version 1.7.1) where Mercurial would fail to break hardlinks in repositories stored on network filesystems. The problem is that two repositories will be hardlinked on the server if you do hg clone foo bar. If a user push a commit to bar, and accesses the repository over the network share, then it's critical that Mercurial discoveres that the files inside bar/.hg/store are hardlinked to foo/.hg/store so that it can break the links. Due to various kernel bugs in Windows and Linux, this could fail with old versions of Mercurial.

So, to recap: your server does not need Mercurial installed if you just install Mercurial on all the clients. Create (I hope I remember the UNC paths correctly)

\\server\share\main

as the main repository and make clones for the developers:

\\server\share\alice
\\server\share\bob

Alice and Bob will work there and modify the working copies independently. They make commits as normal and when they're ready, they push back to the main repo. The usernames are stored in the changesets, so they will be retained when the changesets go into the main repo.

Create a shared baseline repository on a network share. Have all users do 'hg clone' to get a local copy of that repository and let them work (compile, edit, 'hg add / ... / commit') on the local copy. Whenever someone is ready to push their local changes to the shared repository, let them do 'hg push'. Whenever someone wants to get changes pushed to the shared repository by others, let them do 'hg pull' and 'hg update'. That's it in a nutshell.

A couple of notes:

• Concurrent read / write access to the shared repository is not a problem. As other similar systems, Mercurial has been explicitly designed to deal with that.

• Local copies of the shared repository are your backups.

• User names attached to commits have to be configured by hand in the 'mercurial.ini' files in each local installation of Mercurial. I don't know if there's a way to use something like %USERNAME% in that file, which would expand to the name of the current login, there might be.

• A common practice is to avoid multiple heads in the shared repository (just ignore this bullet for now if you don't know what it is talking about yet). To aid in that, users that are about to push their changes would normally like to first pull changes made by others and make sure their local changes are compatible with those made by others. The conflict resolution part is done by 'hg merge'. Most of the conflicts get resolved automatically, but some will require user intervention (eg, if you and me edit the same line in the same file, there will be a conflict and the slower of us will have to deal with that and edit the final line manually).

• Since we are dealing with Windows, I suggest forcing all filenames to lowercase (or to uppercase, if you like shouting). This might not be absolutely necessary with latest versions of Mercurial, but we still do that just to be on the safe side (and, yes, when something breaks because Mercurial thinks that 'a.txt' is not the same file as 'A.txt' on a Windows-based system, it breaks ugly).

Good luck.