I'm using Mercurial 1.6. I have a repo with a few subrepos (11). I would like to push the parent repo to the default remote repo without pushing the child repos. Reasons for wanting to do this include:
I'm using SSH repos, and it takes a long time to establish a connection and push nothing to each of the subrepos.
I have commits in subrepos I don't want propagated to the remote repos (yet).
Subrepos have named branches that should not be propagated to the repote repos (and there's apparently no way to pass branch names to the push operation of the subrepos).
However, I've been unable to find a way to accomplish this. I tried deleting the content of .hgsub and .hgsubstate (without committing), but still mercurial insists on pushing the subrepos.
How can I push the changes from the local repo to the remote repo and ignore the subrepos temporarily?
I think you'll need to make local clones of the subrepos.
The problem with pushing the main repo without pushing the subrepos is that the contents of the subrepos are not part of the main repo - only their states are. The contents are referenced from the original location specified in .hgsub. So your main repo's .hgsubstate says "subrepo A is at revision abcd1234", but abcd1234 is a change you made that you don't want to push... and now what would happen if you cloned the main repo? It'd try to clone the subrepo from its original location and update it to abcd1234, but that revision doesn't exist in the original location, so the clone would fail.
Instead, you can make local clones of each external repository and reference those as the external locations of the subrepos. Then when you push the main repo, the subrepo changes will only propagate to your local clones. When you're ready to share those changes, just go over to the local clones and push from there, and you'll be able to pass branch names and so on.
Related
I have a shell repository OriginalWithSubrepo with a subrepository Sub containing a bunch of actual files.
When I clone OriginalWithSubrepo like this
hg clone --pull --noupdate "C:\TestRepo\OriginalWithSubrepo" "C:\TestRepo\OriginalWithSubrepo-clone"
The clone thus created contains just a few mercurial housekeeping files, there is no actual data from the original Sub\.hg directory. I don't know what those files mean but apparently they are enough to recreate the repo because when I update the working directory in clone, the whole thing gets filled out with all the files, including inside the Sub\.hg directory. However, if I clone, then rename the original, and then attempt to update the clone, it doesn't work saying the OriginalWithSubrepo is not found, which means it's all based on links to the original.
This problem doesn't arise when I run clone with update, or when I clone a repository without subrepos.
It behaves the same when I clone to a network share, which is where I really want it to work.
So how do I make a fully independent clone of a repo with subrepos (w/o a simultaneous update)?
Windows XP, hg version 3.4.1
When you add the first subrepo to the parent repo, .hgsub is added to the parent repo. The subrepo only becomes a subrepo from the changeset that commits .hgsub.
When you do hg clone --noupdate --pull parent parent-clone, parent-clone is not at any changeset yet, and so not yet at a changeset at which the subrepo has been created
So how do I make a fully independent clone of a repo with subrepos (w/o a simultaneous update)?
I don't think you can do this as such.
But this may achieve what you're trying to do (I'm reading between the lines here, but I'm guessing to have the repo on the share, but without any files visible):
Create repos on your network share for your parent and sub \\fileserver\repos\OriginalWithSub\ and \\fileserver\repos\Sub\
Modify your local OriginalWithSub .hgsub set the remote path to be \\fileserver\repos\Sub\ and commit.
push your local repositories to their respective network share equivalents.
Both repositories now exist on the network share, without any files visible apart from inside .hg, and you can clone \\fileserver\repos\OriginalWithSub\ (with update) from another computer and get the full history of both OriginalWithSub and Sub.
I have a repository with a number of sub repos, and I wish to clone all of them without having working files. When ever I try to clone using --noupdate no of the sub repositories are available in the closed repository. Is this due to the lack of a .hgsub file in the cloned repository?
That is sort of the reason why.
More specifically, subrepos are implemented not as their own repos, but as part of the working copy their parent repos ( conceptually, you can think of a subrepo as being just a single file existing in your main repo ). However as soon as you update, the repo and subrepos will be at the same state as if you had cloned without using -noupdate.
I am in the process of setting up some third-party subrepositories under a Mercurial repository. One subrepo is another Mercurial repo hosted on Bitbucket.
Since it is a public repo, and I am not a contributor to it, I don't wish to push back to it. However I would like to still have the repository automatically cloned when I clone the parent repository. For one thing, I'd like to have access to the collective history of the subrepository so I can see what may or may not have changed over time.
So, I made an entry in the parent repo's .hgsub file as follows:
thesubrepo = https://bitbucket.org/user/repo
and cloned the repo using
$ hg clone https://bitbucket.org/user/repo thesubrepo
I made a commit to record the subrepo state. I then went to push my parent repo back to it's server (Kiln) only to discover that it was trying to push the subrepo I back to the Bitbucket server. The push to the Bitbucket subrepository appears to not do anything, though.
I did not observe this behaviour when I made a Git subrepo in the same manner (hosted on Git hub) using an entry in .hgsub like this
abc = [git]git://github.com/xyz/abc
Is it best for me just to do this by not setting up a subrepository, and just let Mercurial store the files as files? Or (preferably) is there some setting somewhere that I can use to tell Mercurial to never actually push the contents of this subrepo back to it's source location?
I'd rather be able to configure it to only push those subrepos manually, so if anyone can shed some light on this, I would appreciate it.
I found a reference to commitsubrepos = no in another stack overflow answer, which as far as i can tell is about commits, and not pushes of sub repositories. I then looked this up on the mercurial website, in the hope there might be some reference to a setting pertaining to pushing subrepos, but... no
You cannot (currently, as of version 2.0) ask Mercurial to not push subrepositories.
The fundamental problem is that Mercurial must ensure that you have a consistent state on the remote repository when you push. It would be unsafe if you could push back to Kiln and then have a changeset there that references a revision on Bitbucket that isn't there. Mercurial doesn't know if a changeset you have locally is published or if you created it — so it has to (try to) push.
We're currently working on a concept called phases. With that in place, Mercurial will begin tracking if a changeset is created locally or already published. That can be used for subrepositories too: if there are only changesets in the "public" phase in a subrepo, then there's no need to try pushing!
Here is what I did:
Cloned a remote repository to my local computer. Created a second clone from the first clone. Made changes in the second clone. Never touched anything that resides in the first clone.
Now what happens if I directly push to remote repo from the second clone? A new branch is introduced in the remote repo?
Maybe a stupid question but I can't test it because there are other developers working on the code and I don't want to mess anything.
Thanks.
Now what happens if I directly push to remote repo from the second clone? A new branch is introduced in the remote repo?
What you would want to do in this situation is clone the central repo again (in case any other programmers made changes) merge your changes with those, and then push that back to the central repo.
This ensures that your branch is now part of the main branch again.
Metropolis
EDIT
Maybe this will be a little more clear
Clone repo1 to your machine
Make a clone of repo1 on your machine to keep the original in tact
Make changes to repo2 on your machine
Pull changes from repo2 to repo1, merge (if needed)
Clone CR again (in case other programmers made changes)
Pull changes from repo1 to the newly cloned repo (merge if needed)
Push newly cloned repo back to CR
Clone CR again and remove all of your repos to get the newest copy
I have recently switched from Subversion to Mercurial for source control and in doing so have split up one repository into several. I used subrepos to manage the dependencies between repositories. The problem is that pull is not suprepo aware so I have to go into each subrepo and pull changes in order to update a repository. Is there a better way to do this?
pull is not suprepo aware
hg pull should be subrepo aware, provided it is used with the -u (--update) option.
The hg update should, when it comes to subrepos, take them into account:
Whenever newer Mercurial versions encounter this .hgsubstate file when updating your working directory, they'll attempt to pull the specified subrepos and update them to the appropriate state.
Subrepos may also contain their own subrepos and Mercurial will recurse as necessary.
The OP CoreyD adds:
That has not worked for me.
I create two repos /repo and /sub and I clone sub into repo (/repo/sub).
Then I create an .hgsub file in /repo with this a line like this sub = ../sub and commit it.
When I make changes to /sub and then do an update in /repo /repo/sub is unchanged.
Am I doing something wrong?
That looks about right:
SubRepos or submodules (for Git) are all about referening a precise configuration (changeset ref for hg, or commit ref for Git, as explained in this SO question)
When you change anything outside of /repo, you don't change the .hgsubstate file within /repo recording the exact configuration (changeset reference).
Hence no change at all.
You could rather do your /sub changes directly in /repo/sub, commit them, then commit /repo.
Then, a clone of /repo would have the new configuration.