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!
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 use named branches in Mercurial.
In doing so I have created one branch called playground where I can try out various wacky experiments. I never intend to merge this branch into any others and I never want to push it to our main repository.
Since creating it, every time I do a push I am told I have added a new branch and I have to use the --new-branch flag. At this point hg push -b default (or whatever branch I'm pushing) works fine but it's annoying. Is there any way to suppress that message by letting Hg know that I am not interested in pushing that branch ever?
Starting with Mercurial 2.1 (released in February 2012), you can mark your changesets secret to keep them from being pushed to another repository. You use the new hg phase command to do this:
$ hg phase --force --secret .
This mark the current working directory parent revision (.) as being in the secret phase. Secret changesets are local to your repository: they wont be pushed or pulled. Pushing now looks like this:
$ hg push
pushing to /home/mg/tmp/repo
searching for changes
no changes to push but 2 secret changesets
There is no equivalent mechanism in older versions of Mercurial. There your best bet is to create a local clone for the changesets you don't want to push.
Update:
Mercurial 2.1 introduced the hg phase command which allows users to control what change sets are exchanged with remote repositories. #MartinGeisler answer to this question details this method.
Original Answer:
If you want to create a local branch of your code you have a couple options. You can hg clone the repository which will locally create a branch of the entire repository in your filesystem. The other alternative is you can try to use a Mercurial extension like LocalbranchExtension.
There are many ways to branch in Mercurial without using a named branch. Just find a method that suits your needs.
Further reading: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
In addition to the excellent answer above concerning phases, you can also specify 'default-path' (in the [paths] section of your .hgrc) to refer to the local repository:
[paths]
default = ...
default-push = .
This will cause all outgoing changesets to be compared to the specified repository. In this case, comparing outgoing changesets in your local repository TO your local repository results in nothing to push.
You can still pull/update/merge from the main repository, but no push will ever send anything back to that main repository.
If you work on multiple machines/repositories, you can set one up as described above, and configure the others to specify the 'default' path to point to the server that pushes to itself. In this way, the other machines can push/pull to your local central repository, and these changesets will never escape your carefully configured collection of repositories.
Summarised Question:
Are github-hosted sub repositories within a mercurial/kiln repository possible, and if so are they automatically updated/cloned when the parent mercurial repository is operated on by a hg clone or hg commit command?
Detailed Question:
Following on from my question that was answered so excellently here , some of my third party code is in folders I downloaded a while ago from opensource efforts on github. Since at that stage I was not using version control, those folders where just standard folders that now been incorporated as sub repositories in mercurial.
This is obviously not ideal, as for one thing, new versions of the libraries may have bug fixes, or new features I wish to use in the future. I also may need to locally customise some of the libraries.
I can see from reading this link that it possible to have mercurial "know" about those git server urls (and revisions), so I can then have mercurial clone the github hosted libraries direct from their parent repos.
Am I right in saying that when I clone the parent (mercurial) repos, those files will be pulled from github, without having to separately manage this using git?
What is also not clear is, if I were to do this, and it transpired that code might need to be customized from within that github-cloned repository, would I need to use git to manage revisions of the local files, or would mercurial do that by proxy? eg id I were to hg commit -S would mercurial invoke git on my behalf to handle that?
Am I right in saying that when I clone the parent (mercurial) repos, those files will be pulled from github, without having to separately manage this using git?
Yes, clone of a Mercurial repository that contain subrepositories will trigger a clone of the subrepos too. It really happens on update. Mercurial notices the .hgsub file and issues the needed hg clone and git clone commands for you. It uses the information in .hgsubstate to know exactly what revision to checkout.
The subrepositories can be hosted anywhere. For a Git subrepository declared like
foo = [git]https://github.com/user/repo.git
Mercurial will simply issue the corresponding clone command:
git clone https://github.com/user/repo.git foo
It's then your reponsibility to later go into the foo repo and use Git to fetch new commits as necessary. After you fetch/pull new commits, you can make a top-level commit to record the new state of the subrepo in the .hgsubstate file. Use hg summary to see if a subrepo is dirty in this sense.
[...] would I need to use git to manage revisions of the local files, or would mercurial do that by proxy? eg id I were to hg commit -S would mercurial invoke git on my behalf to handle that?
When you edit files and make a top-level hg commit, Mercurial will make sure to commit the subrepo first (if you use hg commit -S or if ui.commitsubrepos=True). If you make a top-level push, then Mercurial will always push the subrepos first so that you always have a consistent set of changes on your server.
I'm starting with Mercurial. I'm reading the mercurial book but still have a question.
I've started my project month ago, and i have a lot of files and directories in it. Now, i want to use Mercurial and made myself an account in bitbucket. Now, i want to set this project up in Bitbucket. How can i add all those files to the bitbucket repo?
This is what i was thinking i could do:
I could try to (1) clone the empty repo (from bitbucket) (1) copy all files into that directory, (3) issue an "hg add" and after that (4) commiting.
Maybe you have a better way to do this.
Thanks!
(1)
hg clone https://ME#bitbucket.org/ME/myproject
(2)
cp existing-project/* myproject/
cd myproject
(3)
hg add
(4)
hg commit -u ME
(5)
hg push (i think i have to do this to make the changes visible)
You can simply hg init, hg add, and hg commit in the original project folder, then edit ~/project/.hg/hgrc to add a default-push location of your bitbucket repo (you can clone it to a temporary folder to get the hgrc created for you which you can copy into your project, even, without needing to RTFM for the right syntax.)
Because of the distributed nature of mercurial, this hgrc entry is the only thing relating your local repo to bitbucket at all; you can even hg push https://ME#bitbucket.org/ME/myproject without making the link explicit anywhere. Each copy of a repository is completely self-sufficient.
Wooble's answer is ok, but it's missing something, so I'm supplementing here.
When you first create an empty repository (by hg init or creating on bitbucket), it has no identity. However, as soon as it has any changesets, it has an identity and you can only push/pull between it and repositories that share that identity.
If you had 2 repositories A and B for separate projects, you wouldn't be able push/pull between them. Once you create a new repository on bitbucket you can push changesets from either A or B to that repo once. If you push changes from B that first time, the bitbucket repository is now related to B. You can't then push changesets from A into it, or pull changesets into A from it.
So when Wooble says,
...this hgrc entry is the only thing relating your local repo to bitbucket at all;
That is correct while it is still empty as it is not related to any repositories until it has changesets. And you still need that address to be able to push/pull between your local repo and the bitbucket repo, but once you've pushed changesets to it it also has that identity that relates it to your local repo.
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.