8

we are small team of 3 developers (Boss, me and another developer working mostly remote), and I am tasked to setup a repository server for Mercurial HG.

It seems like I can simply put our centralized repository on a shared network drive. It will extremely easy to setup, but seems like there is a risk that any one of us could abuse the convenient of working/modify the source repository directly. That is why I am thinking about using HgWebdir server as a way to control access to central repository. So directly access to the central source repository is not encouraged, but the shared drive will be here just in case.

I guess it is a question of defined our in-house version-control procedure, not a really version-control question, but I am still go ahead and ask the question. As I don't feel I am experienced enough to make the decision, and if I am not 100% sure that my reason and means a valid, it is probably hard for me to enforce the way version-control system should be used by other developers.

Edit:

I can see that there are potential issues on shared folder working with Version-control software. But anyone care to explain bit more what happened behind the scene, when pushes to shared folder? My understanding is that shared drive is essentially a shared link/shortcut, so for a shared drive, Mercurial on local machine is only hold the lock for that link, but the fact is that each users machine could had a different instance of Mercurial holding the links' lock, while the server's Mercurial instance will hold its own link on physical drive. I can see it is complicated, but how it is going to fail? I can understand the conclusion, but couldn't by myself link the facts to the conclusion

Paul L
  • 2,240
  • 5
  • 36
  • 55
  • Another point to consider is that network drives often has strange filesystem semantic which do not play well with SCMs. At least that's been the case that there was corruptions with network drives involved (it's probably fixed not). – tonfa Jul 26 '11 at 07:33
  • 1
    I'm guessing that hosting the code off-site, like on a private repository on bitbucket or kiln is out of the question? – Lasse V. Karlsen Jul 26 '11 at 07:39
  • @Lasse No, not now. By the way, anyone know whether it is viable to host your None-open-source source code in Bitbucket? I know it is an option by reasoning, but how can I convince my boss besides saying "Why not?" – Paul L Jul 27 '11 at 00:48
  • This is a different question altogether, I think you should try to look on programmers.stackexchange.com and here on stack overflow for existing questions which ask the same thing, how to convince boss/management/leadership to accept off-site source code hosting. – Lasse V. Karlsen Jul 27 '11 at 07:43

2 Answers2

7

You should not place the Mercurial repository on a shared folder on a network server because Mercurial cannot reliably hold locks in all situations in such a setup, and during pushes to that central repository, locks are crucial to avoid corrupting the repository.

In fact, I would remove the "not encouraged" and replace it with "not possible", and only serve the repository either with hgweb or hg serve, the former being the recommended setup for long-running servers.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
  • How about running HGWEB with the repository storage being located on a network share? – Omar Sep 18 '12 at 16:29
  • I can attest. Mercurial cannot be pushed and pulled to a shared folder without regular and irreversible corruption occurring. – Gary Stanton Oct 15 '18 at 16:02
  • Is it different for git? Saw another post—https://stackoverflow.com/questions/11635493—people are not discouraging it. (I prefer hg, but need to find a working solution for my team, and we can't easily set up servers.) – texnic May 02 '19 at 19:06
  • No, not really, the inability of mercurial to obtain locks in all circumstances on shared drives isn't specific to mercurial, but instead an issue with the shared drive system itself. That isn't to say that ALL shared network drives are bad, but if you're asking in the general sense, then the general answer is that it isn't recommended (by me). Whether git will corrupt the shared repository or just require some minor fixes if it happens I cannot say. – Lasse V. Karlsen May 03 '19 at 07:54
  • But "by me", I've read enough places about this recommendation to say that it is, in the general sense, not recommended. – Lasse V. Karlsen May 03 '19 at 07:55
  • Is using private repositories on places like github not an option? – Lasse V. Karlsen May 03 '19 at 07:55
  • The lead dev of Mercurial (Matt Mackall) seems to [disagree](http://mercurial.808500.n3.nabble.com/repository-on-Samba-Share-td927412.html#a928948): "Mercurial doesn't use such locks. We instead use atomic file creation, which tends to work pretty well." – Micha Wiedenmann May 03 '19 at 09:53
  • I can only speak from experience, and in my experience, using mercurial with shared network drives was flaky at best. But this is 8 years ago and I no longer use mercurial, so I can barely remember the whole issue. – Lasse V. Karlsen May 03 '19 at 09:59
2

If you have a centralized server you can install hgweb there and push and pull from it as a central and BACKED-UP source. We still have Windows 2003 servers (I am in no position to change that) and with a little searching on the web was able to find info on how to setup a hgweb on a Windows server though most of it referred to Windows Server 2007.

Mark
  • 452
  • 2
  • 9