9

I know it is not possible to create Mercurial repositories remotely using HTTP(S), for instance:

$ hg init https://host.org/repos/project

or

$ hg clone /path/to/local/project https://host.org/repos/project

But, what's the reason? Security issues? No need for it? Simply because nobody has implemented it yet?

Rationale for this question: In my company we share most resources via HTTPS, i.e. access permissions are managed by Apache only and regular users cannot login via SSH on the server. That's just perfect as long as repositories need to be served only (for that purpose we are happy with hgwebdir.cgi). However, we also want to allow the remote creation of repos, without the need to maintain additional/patched scripts on the server and extra tools on clients.

To be clear: This question does not ask for solutions to our particular problem but for the reason why Mercurial does not support this feature itself.

UPDATE

Here's a more technical description of the situation I'm thinking of. Supposed hgwebdir.cgi serves a collection of repositories in /path/to/repos at https://.../repos (with pushing enabled). Every user allowed to access this URL (as configured in Apache) may pull and push changesets, effectively this means that hgwebdir.cgi (and thus hg) edits and creates files below /path/to/repos. Now, what's the barrier in letting hgwebdir.cgi also create new repositories below /path/to/repos?

Community
  • 1
  • 1
Oben Sonne
  • 9,893
  • 2
  • 40
  • 61
  • Didn't you already give the answer yourself? The whole web setup (especially permissions) is managed by apache, Mecurial couldn't know how to configure or extend your particular apache setup. – Zarat Feb 08 '11 at 13:30
  • @Zarat: AFAIK `hgwebdir.cgi` runs `hg` on the server side which then edits/deletes/creates files within a repository (usually as the webserver user, e.g. *www-data*). Shouldn't `hg` be able to similarly create new repositories within a directory specified in `config.web` (and, of course owned by *www-data*)? – Oben Sonne Feb 08 '11 at 13:36
  • Well, I think it's a borderline case, I've just setup a multi-repository server myself yesterday and you need multiple cgis for different permissions. I guess the problem is that the server setup is partially outside the cgi/hg responsibility. – Zarat Feb 08 '11 at 13:48
  • I agree that this would be a useful feature. At the moment our current workflow for creating a repo on our master server is to logon (via RDP) to our master server and then do a manual clone of the developer's repo which he is `hg serve`'ing. It doesn't take long to do I admit but it would be better if maybe the webdir application exposed some way to initiate the clone operation via the web page. Then we wouldn't need to worry about giving devs direct RDP access to our master server. – nbevans Feb 08 '11 at 13:49
  • @Zarat: Yes, I know we'd need multiple CGIs for different permissions. But supposed `hgwebdir.cgi` serves a collection in `/some/path` at `https://.../repos` (pushing enabled), then technically it shouldn't be a huge problem to allow everyone with access to this URL to also create repos below `/some/path`, right? – Oben Sonne Feb 08 '11 at 13:56
  • @NathanE: Exactly, our admin is not willing to allow users to login to the serving machine (for good reasons). – Oben Sonne Feb 08 '11 at 13:57
  • @ObenSonne: That may work for your environment, but eg. at my server I'd need to separate "create repo" from "push" rights. While you could map the create-repo operation on a restricted virtual path it looks like a hack. I think it's better handled by making a custom web form which is tailored to the specific environments needs. - Your approach ofcourse still would be useful to opt-in (via extension?) for simple setups where you don't need advanced rights. It's just not a good general solution. – Zarat Feb 08 '11 at 17:13

3 Answers3

5

I think the reason is that adding support for creating repositories will bring in a fair amount of baggage:

  • if you can create repositories you would expect to be able to delete them. While that might seem simple, it would be a big step away from the safe manner in which Mercurial normally works -- there is no destructive commands in standard Mercurial.

  • people would also want to edit the .hg/hgrc files to set the description and contact information -- standard Mercurial never changes the config files, so this would again be a new thing.

  • people would also want to manage users' access to the new repositories -- this means editing .htaccess files or the equivalent for other webservers.

... and so on. Implementing this "little" feature will open up for a lot of extra feature requests and we only have a few Mercurial developers that are also sawy web developers.

However, there is now an excellent open source solution: Kallithea gives you a "mini-Bitbucket" that you can deploy on your own server. It will do all of the above. I would install that on my server if I needed something more powerful than plain hgweb.cgi. It supports both Mercurial and Git.

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
  • I see your point. Tough the creation of repositories could be enabled with relatively little effort, almost everybody would expect more - and divergent - features on top of that. – Oben Sonne Feb 19 '11 at 22:12
  • Yeah, it's an eternal struggle between keeping the core of Mercurial lean and maintainable and giving people all the features they ask for. I think it is okay to refer people to third-party sources here so that we can focus on core issues in Mercurial. – Martin Geisler Feb 21 '11 at 13:08
  • So then, you create them easily, and hide them easily. Who says you EVER need to delete them? I will write exactly such a feature, if nobody else does first. (Users will want lots more things, if I do this, is not a valid excuse for making workflows that users need, easier.) – Warren P Jun 23 '11 at 21:14
0

As far as I know, none of the SCM alternatives allow the creation of remote repositories natively. SVN, CVS, Git, et al.

That's usually the job of a hosting provider: SourceForge, Google Code, BitBucket. All of them implement the repository creation on top of their authetication infrastructure.

For example, Debian's Mercurial hosting is limited to Debian Developers, and to create a new repository you need to login via SSH to the server and create the repository on your local home folder, much like Apache's public_html directory.

vz0
  • 32,345
  • 7
  • 44
  • 77
  • Though, it is possible to create repositories using SSH: `hg clone /path/to/local/repo ssh://host.org//absolute/path/repos/project`, so prinicpally the idea of creating repos remotely seems to be accepted. – Oben Sonne Feb 08 '11 at 13:43
  • @Oben, Over SSH is easy since Hg have full shell access, executing an `hg init` command remotely on the SSH shell. Doing the same over HTTP means adding additional complexity to the protocol, having the need to implement custom rules. It's too much trouble for something that's easily solved by other means. – vz0 Feb 08 '11 at 13:54
  • How does this differ from HTTP, where `hgwebdir.cgi` also just runs `hg` (but as the web server user)? – Oben Sonne Feb 08 '11 at 14:04
  • @Oben, I see your point. This sounds a bug/feature/enhancement and you probably want to file one on the BTS: http://mercurial.selenic.com/bts/ – vz0 Feb 08 '11 at 14:39
  • You're right, meanwhile I also had the idea that this question probably fits better in the mercurial mailing list. – Oben Sonne Feb 08 '11 at 15:47
0

Various answers (including your own) give some pretty good reasons why the functionality isn't there (separation of concerns mostly), but if you really want to add it you could do so with just a line or two of shell. Here's a hideously unsafe example I gave quite a while ago showing how to add that funcionality in high trust environments: Remote Repository Creation in Mercurial over HTTP

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • Yeah, I've already read your post (it's linked in one of the question referred to in my question). Indeed we currently use an own CGI script, but concerning maintainability an integrated solution would be much better. – Oben Sonne Feb 08 '11 at 19:12