Mercurial file permissions




















This is not a problem of too strict permission, as others have had trying to sync Hg repos. Nor is it an issue of Mercurial NOT copying the file permissions. Hg used to copy only the eXecute bit, but now copies all permissions. Does anyone have a solution to this problem? Could I do a post-update hook on the Linux box to chmod find.

Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Permissions are too open after pushing from Windows to Bitbucket, then pulling to a Linux server?

Ask Question. Asked 9 years, 4 months ago. Active 9 years, 4 months ago. Viewed times. This section configures external merge tools to use for file-level merges.

This section has likely been preconfigured at install time. Use hg config merge-tools to check the existing configuration. Also see hg help merge-tools for more details. Setting used to control when to paginate and with what external tool. See hg help pager for details. If neither pager. Settings used when applying patches, for instance through the 'import' command or with Mercurial Queues extension. Options are symbolic names defining the URL or directory that is the location of the repository.

These symbolic names can be used from the command line. Options containing colons : denote sub-options that can influence behavior for that specific path. When hg push is executed without a -r argument, the revset defined by this sub-option is evaluated to determine what to push. For example, a value of. Specifies default handling of phases. See hg help phases for more information about working with phases.

Specifies profiling type, format, and file output. Two profilers are supported: an instrumenting profiler named ls , and a sampling profiler named stat. In this section description, 'profiling data' stands for the raw data collected during profiling, while 'profiling report' stands for a statistical text report generated from the profiling data. The profiling is done using lsprof. This is equivalent to passing --profile on the command line. Profiling format. Specific to the ls instrumenting profiler.

Profiling format for the stat profiler. Minimum fraction of samples an entry must have for it to be displayed. Can be specified as a float between 0.

For the hotpath format, default is 0. For the chrome format, default is 0. Maximum fraction of samples an entry can have before it is ignored in display. Values format is the same as showmin. Mercurial commands can draw progress bars that are as informative as possible. Some progress bars only offer indeterminate information, while others have a definite end point. Valid entries for the format field are topic , bar , number , unit , estimate , speed , and item.

Alias definitions for revsets. See hg help revsets for details. The order of compression engines determines their priority, the first having the highest priority.

If a compression engine is not listed here, it won't be advertised to clients. If not set the default , built-in defaults are used. Run hg debuginstall to list available compression engines and their default wire protocol priority. Older Mercurial clients only support zlib compression and this setting has no effect for legacy clients. This requires compatible client version 4. Old client will use 'strict'. Like bundle1. Large repositories using the generaldelta storage format should consider setting this option because converting generaldelta repositories to the exchange format required by the bundle1 data format can consume a lot of CPU.

Integer between -1 and 9 that controls the zlib compression level for wire protocol commands that send zlib compressed output notably the commands that send repository history data. The default -1 uses the default zlib compression level, which is likely equivalent to 6. Setting this option allows server operators to make trade-offs between bandwidth and CPU used. Lowering the compression lowers CPU utilization but sends more bytes to clients. Integer between 1 and 22 that controls the zstd compression level for wire protocol commands.

The default 3 should be significantly faster than zlib while likely delivering better compression ratios. Subrepository source URLs can go stale if a remote server changes name or becomes temporarily unavailable.

This section lets you define rewrite rules of the form:. Groups can be matched in pattern and referenced in replacements.

For instance:. Relative subrepository paths are first made absolute, and the rewrite rules are then applied on the full absolute path.

If pattern doesn't match the full path, an attempt is made to apply it on the relative path alone. The rules are applied in definition order. This section contains options that control the behavior of the subrepositories feature.

See also hg help subrepos. Security note: auditing in Mercurial is known to be insufficient to prevent clone-time code execution with carefully constructed Git subrepos. It is unknown if a similar detect is present in Subversion subrepos. Both Git and Subversion subrepos are disabled by default out of security concerns. These subrepo types can be enabled using the respective options below. When false, commands involving subrepositories like hg update will fail for all subrepository types.

Whether Git subrepositories are allowed in the working directory. This option only has an effect if subrepos. Whether Subversion subrepositories are allowed in the working directory. Alias definitions for templates. See hg help templates for details. Use the [templates] section to define template strings. Mercurial will not use the settings in the. This issue is often encountered when configuring hooks or extensions for shared repositories or servers.

However, the web interface will use some safe settings from the [web] section. This section specifies what users and groups are trusted.

The current user is always trusted. When enabled, hg clone may download and apply a server-advertised bundle file from a URL instead of using the normal exchange mechanism. Whether failure to apply an advertised "clone bundle" from a server should result in fallback to a regular clone. This is disabled by default because servers advertising "clone bundles" often do so to reduce server load.

If advertised bundles start mass failing and clients automatically fall back to a regular clone, this would add significant and unexpected load to the server since the server is expecting clone operations to be offloaded to pre-generated bundles.

Failing fast the default behavior ensures clients don't overwhelm the server when "clone bundle" application fails. Servers advertising "clone bundles" may advertise multiple available bundles. Each bundle may have different attributes, such as the bundle type and compression format. This option is used to prefer a particular bundle over another. The template used to print the commit description next to each conflict marker during merge conflicts. See hg help templates for the template format.

Defaults to showing the hash, tags, branches, bookmarks, author, and the first line of the commit description. If the encoding of the merge markers is different from the encoding of the merged files, serious problems may occur. An optional external tool that hg import and some extensions will use for applying patches. By default Mercurial uses an internal patch utility.

The external tool must work as the common Unix patch program. In particular, it must accept a -p argument to strip patch headers, a -d argument to specify the current directory, a file name to patch, and a patch file to take from stdin. It is possible to specify a patch tool together with extra arguments. For example, setting this option to patch --merge will use the patch program with its 2-way merge option. Check for portable filenames.

Can be warn , ignore or abort. The committer of a changeset created when running "commit". Typically a person's name and email address, e. Environment variables in the username are expanded. If the username in hgrc is empty, e. Web interface configuration.

The settings in this section apply to both the builtin webserver started by hg serve and the script you run through a webserver hgweb. The Mercurial webserver does no authentication it does not prompt for usernames and passwords to validate who users are , but it does do authorization it grants or denies access for authenticated users based on settings in this section.

You must either configure your webserver to do authentication for you, or disable the authorization checks. For a quick setup in a trusted environment, e.

Note that this will allow anybody to push anything to the server and that this should not be used for public servers. Path to file containing a list of PEM encoded certificate authority certificates.

If specified on the client, then it will verify the identity of remote HTTPS servers with these certificates. To disable SSL verification temporarily, specify --insecure from command line. Otherwise you will have to generate this file manually. The form must be as follows:. Number of lines of context to show in side-by-side file comparison. If negative or the value full , whole files are shown. This setting can be overridden by a context request parameter to the comparison command, taking the same values.

Note: lots of HTML content sent by the server is derived from repository data. Please consider the potential for malicious repository data to "inject" itself into generated HTML content as part of your security threat model. Labels are exposed as a template keyword and can be used to customize output. How frequently directory listings re-scan the filesystem for new repositories, in seconds. This is relevant when wildcards are used to define paths. Depending on how much filesystem traversal is required, refreshing may negatively impact performance.

Web substitution filter definition. You can use this section to define a set of regular expression substitution patterns which let you automatically modify the hgweb server output. The default hgweb templates only apply these substitution patterns on the revision description fields. You can apply them anywhere you want when you create your own templates by adding calls to the "websub" filter usually after calling the "escape" filter.

This can be used, for example, to convert issue references to links to your issue tracker, or to convert "markdown-like" syntax into HTML see the examples below. Each entry in this section names a substitution filter. The value of each entry defines the substitution expression itself. The websub expressions follow the old interhg extension syntax, which in turn imitates the Unix sed replacement syntax:. The final "i" is optional and indicates that the search must be case insensitive.

We currently perform working directory updates in parallel on Unix-like systems, which greatly helps performance. This manual page is copyright Bryan O'Sullivan. Mercurial is copyright Matt Mackall. Free use of this software is granted under the terms of the GNU General Public License version 2 or any later version. Description The Mercurial system uses a set of configuration files to control aspects of its behavior.

Troubleshooting If you're having problems with your configuration, hg config --debug can help you understand what is introducing a setting into your environment. Structure The configuration files use a simple ini-file format.

Files Mercurial reads configuration data from several files, if they exist. On Plan 9 and Unix, most of this file will be ignored if it doesn't belong to a trusted user or to a trusted group. Sections This section describes the different sections that may appear in a Mercurial configuration file, the purpose of each section, its possible keys, and their possible values. Note Some global configuration options such as -R are processed before shell aliases and will thus not be passed to aliases.

The following options apply to all hosts. The cookies file is read-only. Example: foo. If the prefix doesn't include a scheme, the match is performed against the URI with its scheme stripped as well, and the schemes argument, q. Username to authenticate with.

If not given, and the remote site requires basic or digest authentication, the user will be prompted for it. Environment variables are expanded in the username letting you do foo. If the URI includes a username, only [auth] entries with a matching username or without a username will be considered. Password to authenticate with. PEM encoded client certificate key file. Environment variables are expanded in the filename. PEM encoded client certificate chain file. Space separated list of URI schemes to use this authentication entry with.

Only used if the prefix doesn't include a scheme. Supported schemes are http and https. They will match static-http and static-https respectively, as well. One of auto , ansi , win32 , terminfo or debug. Any invalid value will disable color.

Valid values are abort , none , linear , and noconflict. Pros: standard feature in Mercurial. Makes it easy to setup the password used for all repositories on a given host. Cons: passwords are stored in a plaintext configuration file.

Care must be used if the file is shared with others. You can save the credentials directly in your Mercurial configuration file. You do this with the auth section :. The [auth] section contains a number of entries, and the entries are grouped by an arbitrary key chosen by you. Above, we used bb as the key for Bitbucket, but we could have picked anything. If you have more sites you want to store the password for, then you need to use different keys for each host:.

This final way takes advantage of a built-in feature in the specification of URLs: one can embed a username and password directly into them. The URL syntax is:. If the clone is succesful, then the full URL is stored as the default path in the. Because the username and password is stored in the URL, future invocations of hg pull and hg push will do the authentication automatically without any prompts.

When you work a lot with repositories on the same host, then it might become annoying to repeatedly type:. Mercurial has a standard extension that will help you shorten those URLs. You enable the schemes extension and can then add the following to your configuration file:. See hg help schemes after enabling the extension for the full syntax. Notice how this configuration even set the username for you, something that is particularly easy to forget when using SSH with Bitbucket.

We also used the oportunity to enable compression for the SSH tunnel, which will improve performance overall. If you are using Putty on Windows TortoiseHg does come with a bundled install of Putty then you can do the same by configuring and saving a connection. Create a private repository called test and clone it to your local machine.

Create a new repository on Bitbucket called hello and push the hello clone from your machine up to Bitbucket. Notice how you can push changesets into an empty repository. What happens if you try to push from your hello clone to your test clone on Bitbucket? How does Mercurial know if the repositories are related? Filesystem Permissions When you access a repository through the hgweb. Filesystem Permissions Because Mercurial makes a login on the server, it is the user on the server that must have read access to the repository files in order for you to make a clone or to pull changesets.

Keyring Extension In short: Pros: passwords are stored in a OS-specific secure backend, most secure option. Cons: requires third-party extension. Cons: password is stored in plaintext. Add and commit a file to the repository and push it back to Bitbucket.



0コメント

  • 1000 / 1000