There is a configuration file of repository in %path_of_repo%\.hg\hgrc
It has the following configuration:
[paths]
default = C:\STORAGE\REPOSITORIES\PROJ_FIRST
[web]
name = The First Project
encoding = utf-8
I want change property into conf-file an example. But commands like as:
hg config web.name=NewNameOfProject
It doesn't work (
What is the correct syntax for a command that edits parameters from the Hg Mercurial console? Thx
If I have understood your question correctly, it is asking how to use the Mercurial command-line modify its configuration files.
As far as I am aware, you have to edit the config files manually.
Its a little hard to prove that you "can't" do something... but looking at documentation etc. there are a few things which seem to corroborate this impression.
From hg help config:
Files ...
Mercurial reads configuration data from several files, if they exist.
These files do not exist by default and you will have to create the
appropriate configuration files yourself
From hg config --help:
hg config [-u] [NAME]...
show combined config settings from all hgrc files ...
With --edit, start an editor on the user-level config file. With --global,
edit the system-wide config file. With --local, edit the repository-level
config file.
Furthermore all the other instructions for hg config only explain how to get it to display configuration information, not how to modify it.
Using TortoiseHG, obviously in its File > Settings GUI it will allow you to modify certain values in the config files; but there is no general capability to modify any arbitrary value.
THG however does have a nice built-in editor for those files which is at least convenient to use.
So for web.name you would probably use the per-repository <repo>/.hg/hgrc file. It should include:
...
[web]
name=NewNameOfProject
...
for your example.
Related
The ClickHouse quick start guide says that when modifying config.xml: "It's not really handy to directly edit config.xml file considering package updates. Recommended way is to override the config elements in files of config.d directory."
I am new to ClickHouse (as well as daemon configuration). What does that statement mean? Where is the config.d directory? What files should go into that directory and what should the contents be?
It means that it's recommended to create a separate configuration file in the config.d directiory (that is located in the same path as the current configuration file; so /etc/clickhouse-server/config.d/ by default).
"considering package updates" means that if you update your clickhouse-server package, it may rewrite the /etc/clickhouse-server/config.xml, so you shouldn't put any changes in there - it'll be rewritten and lost.
It says so in the documentation:
The main server config file is 'config.xml'. It resides in the /etc/clickhouse-server/ directory.
Certain settings can be overridden in the *.xml and *.conf files from the 'conf.d' and 'config.d' directories next to the config.
So, you should create a /etc/clickhouse-server/config.d/ directory; then, create a configuration file there (like config.xml, my_config.conf or whatever else). There you should do all your custom settings, the ones that differ from the original /etc/clickhouse-server/config.xml file.
For instance, you could change the HTTP port from 8123 to 8663:
# cat /etc/clickhouse-server/config.d/test.xml
<?xml version="1.0"?>
<yandex>
<http_port>8663</http_port>
</yandex>
Please make sure to restart the daemon (if you're using Ubuntu, it's sudo service clickhouse-server restart) for the configuration changes to apply.
I am using spring cloud config server to host a centralized location for all the property files configurations to be used in the project.
I tried using the config files from a local file system using below and it works fine:
spring.profiles.active=native
spring.cloud.config.server.native.searchLocations=file://${HOME}/Documents/test-config/cloud-config-properties/
I also used the git repo using: spring.cloud.config.server.git.uri=ssh://xxxxxx.com:7999/test/cloud-config-properties.git
I would like to try using a combination of this in my project.
Example - for dev/test profile - i would like to use from local filesystem and for the production - I would like to use Git repository.
I enabled both the git uri and native profiles in my application.properties in config server application. But the properties are always picked up from the local file system. Is this possible?
Not supported out of the box, however there is a workaround for this. You can define the basedir for the configuration server, which is where it saves the files it fetches from the remote server, by setting the property (in the config server):
spring.cloud.config.server.git.basedir=<your_dir>
If you are working with docker, you can map this directory to the host filesystem.
Now whatever file you put in there will be picked up by configuration-server if it matches any of the application/profile in the request. For example you could put a file there called application-dynamic.properties, and have all your clients use dynamic as the last profile, for example
spring.profiles.active=systesting,dynamic
This way everything you will put in application-dynamic.properties will override whatever is defined in your config repo.
One thing to notice though is that you need to add the file only after configuartion server starts, because it deletes this folder during startup.
Needles to say, it's not a good practice doing this in production (for example a restart will cause the file to be deleted), but for test/dev this is the best option.
I'm trying to insert the mercurial_keyring file with my username and password in the .hgrc file but it doesn't exist in my user directory on windows. I have tortoise hg installed and even checked if it was installed properly on the command prompt yet I still don't have the .hgrc folder.
Can anyone tell me what might be the reason to it?
Thanks
Because it's %USERPROFILE%\mercurial.ini
Mercurial reads configuration data from several files, if they exist.
These files do not exist by default and you will have to create the
appropriate configuration files yourself:
Local configuration is put into the per-repository /.hg/hgrc
file.
Global configuration like the username setting is typically put into:
%USERPROFILE%\mercurial.ini (on Windows)
The .hgrc files are not created automatically when you install Mercurial or TortoiseHg.
You will need to manually create it at the location you need whether that is within the repository's .hg folder or your own C:\Users\username\ folder.
You will probably need to use the command line to create the file as it's not usually possible to create filenames that start with . in Windows Explorer.
https://www.selenic.com/mercurial/hgrc.5.html
I am writing a system script in Ruby.
I'm using the classic gem structure: lib, bin, spec for RSpec.
I want to build a configurable script: I want to be able to provide options like --set-stuff and alike. A perfect example is:
git config --global user.name "Andrea"
which writes the given information out to a file, in order to be able to retrieve this information later.
How can I do this in a clean way?
I'd rather not use the environment variable solution: I know I could just set an env variable to point to a configuration file, but then I'd have to save this env variable in, say, .bashrc. Then again, how do I deal with zsh? Or how do I deal with people (like me) who keep their .bashrcs super-neat or even have a separate .env-variables file in their system?
Just stick the configuration into a Hash and serialize it into a file in the user's home directory as YAML or JSON...
I have a ruby project, and the database host and port might be different on dev and production. I need a way to get different values for those into my scripts for the two environments.
The project should be complete - so there should be some way to specify default values. I don't want a clone to be missing the config files. So ignoring them completely won't work.
How do you solve this problem with git?
I would recommend using:
a template config file (a file with variable name in place of the host and port value)
a script able to replace those variable names with the appropriate values depending on the environment (detected by the script)
The Git solution is then a git attribute filter driver (see also GitPro book).
A filter driver consists of a clean command and a smudge command, either of which can be left unspecified.
Upon checkout, when the smudge command is specified, the command is fed the blob object from its standard input, and its standard output is used to update the worktree file.
Similarly, the clean command is used to convert the contents of worktree file upon check-in.
That way, the script (managed with Git) referenced by the smudge can replace all the variables by environement-specific values, while the clean script will restore its content to an untouched config file.
When you checkout your Git repo on a prod environment, the smudge process will produce a prod-like config file in the resulting working tree.