Home/ Questions/Q 6319925
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T15:53:04+00:00

I have a mercurial repository with the following directory structure: / /system /applications /applications/client1

  • 0

I have a mercurial repository with the following directory structure:

/
/system
/applications
/applications/client1
/applications/client2
/applications/client3

I am serving the repo over an apache subdomain over http (no ssl yet) and want to restrict access for push, pull and commit of course. Generally i dont want some users to see the directories at all and also not the history of the directories!

  1. Is there a chance to restrict access to a directory in a mercurial repository.
  2. How can i give access to the client 1 folder only for client1, client2 only for client2 on a linux based system? Note: I dont want to split the repository into sub repositories if not necessary!
  3. If this is not working without sub repositories, can someone please tell me how to do this with sub repositories in this case with my directory structure.

I am lost 🙁

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Since you have everything in 1 repository, then no.

    tl;dr: A repository is always complete, and if you can clone it, you can see everything, there is no way to restrict access to content in a local clone, only to a central server-hosted clone.

    A Mercurial server can deal with authorization in two ways:

    1. It can restrict access to the repository
    2. It can use hooks to prevent pushes with content that that user is not allowed to modify

    The first type would make the whole repository read-only, or unavailable. However, if a user has read-access, he will be able to clone, and see, the whole repository, history and files alike.

    But, you could prevent that same user from modifying the central copy by prohibiting pushes to it. This would mean that that user could do whatever he wanted to with his own private clone, but he would not be able to push those changes back to the central clone.

    The other type would allow you to control where changes was allowed to happen a bit more fine-grained. However, note that again, a user will be able to clone, and see, the whole repository.

    Additionally, the user will also be able to do whatever he wants to with his own personal clone. However, whereas pushes to the central repository is not totally prohibited with this type of authorization, a hook would look at the changesets being pushed, and if, say, you decide that that user is not allowed to push changes to “client2” content, any such changesets that he tries to push will be aborted.

    In other words, the user is able to modify his private clone, including change things in “client2”, but if he commits a changeset with “client2” changes, he will not be able to push back to the central repository. He would then have to strip away, or otherwise get rid of those changesets, before his pushes would go through.

    So to summarize:

    1. You can prohibit the user from cloning altogether, this would make the whole repository unavailable to him
    2. You can prohibit pushes, but allow cloning
    3. You could use hooks to analyze incoming changesets, and prevent changes to content that user is not allowed to modify
    4. Regardless, if the user is able to make a clone, that clone is always complete, and unrestricted, on the users computer. You cannot restrict access in that clone, all you can do is point 1, prohibit the user from cloning to begin with.
    • 0