I'm comming from SVN background and I'm having a problem of adding to my main repo a subfolder of subrepo. That means that I don't want to add the whole subrepo to my main project - only a part of it. In my situation I want to include only source files of my library excluding all unit tests.
I have created .hgsub file and wrote there:
libs/my_std_lib = https://myreposhost.com/my_std_lib_repo/src/main/java/
But when I'm trying to synchronize libs/my_std_lib folder I get such error: HTTP Error: 404 (Not Found)
When I try to synchronize without subpath (https://myreposhost.com/my_std_lib_repo/) - it works well.
So what do I do wrong or this is not posible in hg?
The answer is pretty simple : it's impossible to clone only a part of a repository with Mercurial.
By extension, you can't add only a part of a repository as a subrepo.
Sorry.
Related
Let there is a hg repository with the following layout:
./...
./sub
./sub/...
At the specific moment of time, one need to drop subdirectory sub, and put a subrepo with the same name on its place. How to do this correctly?
Straightforward approach makes the history unaccessible with the following error at hg up -r:
abort: path 'sub/sub' is inside nested repo 'sub'
"make the history unaccessible" is sadly bad and wrong idea
Read about proper creating and using of Subrepositories
When I try to make my Morea repository private, GitHub says that public forks cannot be made private. What do I do?
This was a bug in the original QuickStart instructions, which directed you to create a fork of the basic-template. They have now been fixed, but for those who have already set up a repo, please do the following:
(1) On your laptop, rename your morea directory (let's call it ics314f13/) to ics314f13-old/. Don't delete the directory, just rename it to something different.
(2) Go to GitHub, and delete your repository (i.e. ics314f13). You do this in the Settings page. While this appears scary, don't worry because you still have all your files in your local directory (i.e. ics314f13-old/). This step will mean that you've lost your commit history, but I assume that's not important. (If history is important, there are other more complicated ways to fix things, let me know.)
(2) Follow the revised QuickStart directions starting here:
http://morea-framework.github.io/quickstart.html#Createacourse
The new instructions direct you to create a new, empty GitHub repo. Use your original repo name, the one you just deleted (i.e. ics314f13).
You'll then download a new script (morea-vanilla-install.sh) and run it to initialize the contents of your empty repo with the contents of basic-template. The net effect is similar to a fork, but since you didn't actually fork, you'll be able to make your repo private if you want.
(3) Copy over the changed files from your "old" directory to your "new" directory.
You'll typically just copy over the file master/src/_config.yml and the entire directory master/src/morea/.
Advanced users like Cam might have created new navbar pages. He'll need to copy over these changes as well.
(4) Copy over scripts.
Copy over the morea-run-local.sh script from the "old" directory, and check to make sure everything looks OK.
Copy over the morea-publish.sh script from the "old" directory, and run it to push your changes to your new GitHub repo.
(5) Make your repo private.
You should now be able to go to the settings menu and make your repo private.
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'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 script that is in the top level of my working copy and would like to use it as a Mercurial hook. If I use an absolute pathname to the hook then everything is fine, but I want a relative pathname so the whole thing can be easily moved around, used in other working copies and other developers can copy the hgrc as is.
/space/project/.hg/hgrc contains
[hooks]
update = genid
The genid script is at /space/project/genid
The hook is invoked just fine if I am in /space/project but if my current directory is /space/project/src/tools then 'hg update' will give an error as the hook cannot be found.
Python hooks cannot use a relative path. Script hooks can like this:
[hooks]
update = ./genid
In certain cases, environment variables are expanded in mercurial configuration. So you can check out if you can use a environment variable.
[hooks]
update = $MercurialHooks/genid
See Faq (12) in https://www.mercurial-scm.org/wiki/TipsAndTricks
I had the same problem and couldnt resolve it. The workaround was easy though! I versioned the file in the repo and just copied it to my .hg folder! Not ideal but it isnt that likely to change and other repo users can still get a copy of the file