5

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?

1
  • I love the "version controls isn't supposed to be backup" part! Very well put! Dec 18, 2011 at 11:00

2 Answers 2

4

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.

3

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.

2
  • Thank you for your thoughtful answer. Unfortunately in my environment having local copies would be a major up hill battle. People won't want to change their behaviour that much and there are certain audit rules that frown on local copies. Oct 1, 2009 at 17:58
  • With all due respect, without having local copies, how do developers do their work now??? That seems like any changes would clobber someone elses work, particularly if you run a local server/app from your working copy. Feb 24, 2010 at 18:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .