I have some (local) repositories, an original and some clones. The original repository has been corrupted so I'd like to get rid of it and use one of the clones as the master for future development.
Is there a better way to break the connection between the new master and the original repository than simply deleting the default entry in the [paths] section of that clone's hgrc?
Similarly, in the other clones, can I simply change the default entry in their hgrc files' [paths] section to point to the new master repository?
All clones are independent, but they remember where they were cloned from. As you have found out, this is stored in the .hg/hgrc file. You are free to edit this file as you like. You can even add more paths if you want.
So in your case you just delete the original repository and replace it with a good clone.
The idea is either:
to define a new default path in the paths section
or to define a new path (see this SO question)
But in both cases, that involves modifying the hgrc files.
Related
I'm trying to set up subrepo remapping in Mercurial (2.1.1) to account for subrepo paths that may change in the future. I've been able to get the [subpaths] key to be read and processed properly when it is specified in the .hgrc file. However, when I clone or pull from that repository, the .hgrc file is not copied and thus the subrepo remaps are not brought over to the destination repository.
My first thought after looking at the SubrepoRemappingPlan was to put the [subpaths] in a .hg/subpaths file, which is supposed to be copied on clones/pulls. However, it turns out this functionality has been obsoleted, and the subpaths file has been replaced with a more general configuration-sharing mechanism via the Projrc extension.
The problems with the Projrc solution, though, are:
it's a separate extension that all team members need to have installed and enabled
additional configuration needs to be done to tell Projrc where it is allowed to pull from (and what it is allowed to pull), for security reasons
So, my question is, is there any built-in mechanism in Mercurial for implementing subrepo mapping that is preserved across clones/pulls?
Generally, the best method is to use relative paths for subrepos (see http://mercurial.aragost.com/kick-start/en/subrepositories/) so they never have to be remapped at all.
Example:
+ main repo
+ subrepo
+ .hgsub
.hgsub:
subrepo = subrepo
Adding the subpaths mapping to your .hgsub file should do the trick (as described in the mercurial wiki).
I have a repo in my VCS called CodingStandards. In it is a checkstyle.xml file along with findbugs.xml and it will no doubt grow in the future.
What I want to do is in my project FunkyApp is pull CodingStandards into the project and maintain the link to CodingStandards so that if I change it, I can pull & update in my FunkyApp.
Subrepositories are what you are looking for.
However they forces you to have these files in a subdirectory of your project. There's no way to add juste one file to a repository from another.
First of all setup the CodingStandards repo in .hg/hgrc to make life easier
[paths]
default = https://url/FunkyApp
standards = https://url/CodingStandards
Then you can force pull into your repository
hg pull -f standards
This will create two heads in your repo that need to be merged with hg merge and then committed into your main repo.
To be clear CodingStandards will be unchanged. FunkyApp will have all the files from CodingStandards imported in it. Anyone else who clones FunkyApp will get the files without knowing about CodingStandards.
We use tortoise hg with Kiln. In my vs 2010 c# project there are some files that are part of the repository but I would like tortoise hg to ignore them when I make a commit.
For eg., say in a login screen I may hard code the userid, password for testing. I dont really want this file considered during a commit. I understand .hgignore file but this really works for files that are not part of the repo. Any trick in tortoise hg to ignore files that are part of the repo ? (so they do not show up as modified (M) during a commit.) thanks
I always use a combination of .hgignore and BeforeBuild (in the .csproj file) for things like this.
In one of my pet projects, I have the following setup:
App.config contains my real hardcoded user id and password for testing.
App.config.example is identical, but with fake data like "dummy_user" and "dummy_pw".
App.config is not part of the repository, and it's ignored (in .hgignore).
App.config.example is part of the repository.
Then, I have the following in the BeforeBuild target in the .csproj file of my solution:
<Target Name="BeforeBuild">
<Copy
Condition="!Exists('App.config')"
SourceFiles="App.config.example"
DestinationFiles="App.config"/>
</Target>
All this together has the following effect:
the config file with the real data can never be accidentally committed to the repository, because it's ignored
the repository only contains the config file with the example data
if someone else clones the repository to his machine, he won't have the "real" config file...but if it's missing, it will be automatically created before the first build by Visual Studio / MSBuild by simply copying the .example file (and then he can just put his real login data into the newly created App.config file).
if an App.config with real hardcoded user data already exists, it won't be overwritten when building because the BeforeBuild event will only happen if App.config does not already exist
The answer by Christian is the right one, but I want to mention that TortoiseHg supports what you want with their Auto Exclude List.
One problem with an exclude list is that it cannot work with merges: you must commit all files when you merge and so you'll have to do a little dance with shelve, merge, commit, and unshelve.
When you do a TortoiseHG commit, there is a list of files with checkboxes by them. Deselect the files you do not want comitted.
Or, on the command line, do a commit of the form hg commit --exclude "pattern", where pattern is defined in the hg man page.
You could always use hg forget.
I'm offline a lot.
So normally, I use one local clone as a "hub" for features, bugs, etc.
hg clone local-hub bug-123
Works offline. Cool.
Can I use a similar workflow if that project contains remote subrepositories?
Because, if .hgsub says
sub/shared = http://server/hg/shared
hg clone says
abort: error: getaddrinfo failed
Note that once the clone is created (while connected), push and pull will use the path in the subrepo's hgrc (instead of the location in .hgsub). So I can point this to a local clone and everything is cool.
But clone looks at .hgsub (as it's supposed to). So if the "blessed" subrepo is on a server, I can't create new clones offline, even though the files I need are right there.
This is a problem, right?
Ideally whomever set up the project uses relative URLs in their .hgsub file like this:
sub/shared = ../shared
and then, of course, actually makes shared a sibling of the main repo. Then as long as you have cloned down the main repo and the subs (as siblings) then everything will work out.
If they've used absolute URLs in their .hgsub file you can work around it using the subpaths section in your .hgrc like this:
[subpaths]
http://server/hg/shared = ../shared
which provides a translation layer in your client.
The canonical way to use subrepositories is to have X = X paths in the .hgsub file:
sub/shared = sub/shared
That way a clone will structurally look just like the original -- and so you can use the clone to make further (local!) clones.
However, this is not always possible, for example, Bitbucket wont let you create the nested repositories on their server. In that case, the ../X style paths in the .hgsub file is better, and you can use the subpaths configuration section to translate these paths into paths you can use locally.
I have a project, which I have a bitbucket repository for, and it is dependent on another project that I incorporate as a subrepo. Now, I don't have push access to the subrepository, nor do I want or need to--it's a pull-only relationship.
I realize that when you push the main repository, it will try to push the subrepositories, as well. Since I cannot do that, I pulled a local copy of the dependent project, at the same level as the main repository's directory. In essence, I have the following layout:
Main/ ; pushes to https://mine.org/Main
.hg/
.hgsub
Lib/
SubRepo/ ; clone of Main/../SubRepo/
.hg/
SubRepo/ ; local copy of https://forbidden.org/SubRepo
.hg/
The content of .hgsub is something like,
Lib/SubRepo = ../SubRepo
Then I cloned,
~/path/to/Main $ hg clone ../SubRepo/ Lib/SubRepo
So far, so good. The problem is, after I set this all up and committed the changes, when I try to push Main Mercurial will try to push SubRepo to https://mine.org/SubRepo, which does not exist, thereby failing the whole push operation.
Is there something I'm missing?
Why not just create a https://mine.org/SubRepo -- if you don't want to advertise it you can always turn on hide for it in the [web] section in its .hg/hgrc file. This is the pattern I'm used to, where you clone down the main repo and all the subrepos in the same layout at each place you'll use them: both your development box and your web-facing hgweb install.
Alternately, you could use a [subpaths] section in Main/.hg/hgrc with something like this in it:
[subpaths]
https://mine.org/SubRepo = https://forbidden.org/SubRepo
which should let you intercept the derrived target for the push and point it at a place that which it won't let you push, will let you see nothing has changed so push can continue.
It seems like what Mercurial is doing is legitimate: using the paths listed in your .hgsub it's attempting to push to a directory called 'SubRepo' that exists one level up from Main. This is obviously not what you want, so you'll probably have to work some magic here. I can think of two options:
If you can support this, place the local copy of forbidden.org's repository at C:/Forbidden/Subrepo or something like that, and use this absolute path in your .hgsub. Mercurial will be able to push to this and it should work.
There's no problem including the actual forbidden.org url as your subrepo address if you don't make any modifications to this repo. If there are no changes to the subrepo, your push should succeed. Of course, this is a fairly manual option and on a larger team it would be impossible to enforce. If you did accidentally commit some modification to the subrepo, you'd have to go through and use histedit or MQueues to pull it out, and that can be tricky with subrepos.