doc/file-conditions
branchdebian
changeset 172 5dd3698fad54
parent 118 107906bfe2c6
parent 171 7b69d1d86254
child 174 f141a4b9d5a9
equal deleted inserted replaced
118:107906bfe2c6 172:5dd3698fad54
     1 FILE CONDITIONS
       
     2 
       
     3 Read configuring-access before you read this.
       
     4 
       
     5 mercurial-server supports file and branch conditions, which restrict an
       
     6 operation depending on what files it modifies and what branch the work is
       
     7 on. However, the way these conditions work is subtle and can be
       
     8 counterintuitive - if you want to keep things simple, stick to user and
       
     9 repo conditions, and then things are likely to work the way you would
       
    10 expect.
       
    11 
       
    12 File and branch conditions are added to the conditions against which a rule
       
    13 matches, just like user and repo conditions; they have this form:
       
    14 
       
    15     file=<globpattern> - file in the repo
       
    16     branch=<globpattern> - name of the branch
       
    17 
       
    18 However, in order to understand what effect adding these conditions will
       
    19 have, it helps to understand how and when these rules are applied.
       
    20 
       
    21 The rules file is used to make four decisions:
       
    22 
       
    23 - Whether to allow a repository to be created
       
    24 - Whether to allow access to a repository
       
    25 - Whether to allow a changeset on a particular branch at all
       
    26 - Whether to allow a changeset to change a particular file
       
    27 
       
    28 When the first two of these decisions are being made, nothing is known
       
    29 about what files might be changed, and so all file conditions automatically
       
    30 succeed for the purpose of such decisions. This means that doing tricky
       
    31 things with file conditions can have counterintuitive consequences:
       
    32 
       
    33 - You cannot limit read access to a subset of a repository with a "read"
       
    34 rule and a file condition: any user who has access to a repository can read
       
    35 all of it and its full history. Such a rule can only have the effect of
       
    36 masking a later "write" rule, as in this example:
       
    37 
       
    38    read repo=specialrepo file=dontwritethis
       
    39    write repo=specialrepo
       
    40 
       
    41 allows all users to read specialrepo, and to write to all files *except*
       
    42 that any changeset which writes to "dontwritethis" will be rejected.
       
    43 
       
    44 - For similar reasons, don't give "init" rules file conditions.
       
    45 
       
    46 - Don't try to deny write access to a particular file on a particular
       
    47 branch - a developer can write to the file on another branch and then merge
       
    48 it in. Either deny all writes to the branch from that user, or allow them
       
    49 to write to all the files they can write to on any branch. In other words,
       
    50 something like this will have the intended effect:
       
    51 
       
    52   write user=docs/* branch=docs file=docs/*
       
    53 
       
    54 But something like this will not have the intended effect; it will
       
    55 effectively allow these users to write to any file on any branch, by
       
    56 writing it to "docs" first:
       
    57 
       
    58   write user=docs/* branch=docs
       
    59   write user=docs/* file=docs/*
       
    60   read user=docs/*
       
    61 
       
    62