We have two repositories: myapp and myapp-1.1. We merge myapp-1.1 into myapp.
To see if there are changes in 1.1 that need to be merged I do this:
cd c:\myapp (local clone)
hg fetch (fetch from remote myapp repo)
hg in ssh://hg/myapp-1.1 (see what needs to be merged in from remote 1.1 repo)
This works - but is there a better way? Is there a way to do this without requiring the local myapp clone?
Mercurial can't do much with remote repositories except for some variant of pushing to, or pulling from them.
As such, anything you want to ask Mercurial to do has to be done with a local clone.
So no, there is no way to have Mercurial check if two remote repositories needs to be merged.
What's the problem with having local clone, exactly?
If you want to isolate all operations on machine the repo is located, you could do the following:
$ ssh $hg_box
$ cd myapp; hg in /myapp-1.1
This may seem like the obvious response, but since Mercurial is a completely distributed source control system, and each repo is stand alone, is it possible for you to actually go to the box that has myapp and fetch directly from myapp-1.1? I know most dev teams keep some kind of centralized repository, but that doesn't preclude the use of Mercurial directly from the box that you have as your 'central' repository. It's all still local and remote repositories.
This assumes that you want to fully merge myapp and myapp1.1. Otherwise, pretty much by definition of what you're doing, you have to clone myapp to another full repository, then merge it with myapp-1.1.
Assuming neither the remote repo nor the local repo allows multiple heads per branch, this command should tell if the local repo has the head of the remote repo at a given branch:
hg log -r $( hg in -b branch_name -n -l1 -q --template "{node}\n" )
If local repo doesn't have that changeset, but has outgoing changesets at "branch_name", then typically it should be an indicator that merge is needed.
Related
I have read only permission to an hg repo and am trying to develop and test changes to it locally. The problem is that I am in the middle of changing dev machines and am caught in a weird/akward state across the two machines.
On my old machine I made lots of changes to the repo, locslly. I just cloned the repo on my new machine, but obviously that doesn't contain the changes from my old machine. I need a way to createe a patch/diff from my local working copy on my old machine, and then apply them to my local working copy on my new machine. The problem is that I already commited (hg commit -m "Blah") the changes on my old machine to the distributed repo on it.
What set of specific commands can I use to create a patch/diff of my old machine and then apply it to the repo on my new one?
Update
I commited all changes on my old machine and then ran hg serve, exposing http://mymachine.example.com:8000.
On my new machine, where I had made some different changes (locally) than the changes from my old machine, I ran hg pull http://mymachine.example.com:8000 and got:
myuser#mymachine:~/sandbox/eclipse/workspace/myapp$ hg pull http://mymachine.example.com:8000
pulling from http://mymachine.example.com:8000/
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 16 changes to 10 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
So I run hg merge:
myuser#mymachine:~/sandbox/eclipse/workspace/myapp$ hg merge
abort: uncommitted changes
(use 'hg status' to list changes)
What do I do now?!?
You can use:
$ hg diff > changes.patch
To create a patch file, then:
$ patch -p1 < changes.patch
To apply that patch file on your new machine.
Well, that's actually fantastic, mercurial is a distributed version control system and you do not need to go via any patch file at all: simply pull the changes from your old machine to your new machine:
hg pull URL
where URL can be any network URL or also ssh-login, e.g.
hg pull ssh://mylogin#old.maschine.box or hg pull path/to/old/repository/on/nfs/mount
`
Alternatively you can also use bundle and unbundle. They create bundles which can be imported in the new mercurial easily and keep all meta-information.
hg bundle -r XXX --base YYY > FILENAME
where YYY is a revision you know you have in your new repository. You import it into your new repo with hg unbundle FILENAME. Of course you can bundle several changesets at once by repeating the -r argument or giving a changeset range like -r X:Y.
The least comfortable method is a via diff or export:
hg export -r XXX > FILENAME or equivalent hg diff -c XXX > FILENAME where you need to import the result with patch -p1 < FILENAME or hg import FILENAME.
The easiest way is to do this is to ensure that all work on your old machine is committed. Then use this command on it from the base of your repo:
hg serve
which creates a simple http server on this repo. The monitor should state the name of the http URL it is serving.
On your new machine, just pull from that URL.
Once you've pulled your old changes you can stop the hg serve process with ^C.
The advantages of this method are that it is very quick, and that it works on just about any system. The ssh method is also quick, but it won't work unless your system is configured to use ssh.
Answer to Update
The OPs update is asking an orthogonal question about how to merge changes pulled from a server with local changes. If you haven't already done so, try to digest the information in this merge doc and this one.
Merging is for merging changesets. The error is happening because you have local changes that haven't been committed which mercurial can't merge. So the first thing to do is to commit your local changes, then you will be able to merge.
But before you merge, I strongly recommend that you are merging what you think you are merging. Either ensure there are only 2 heads, or specify which head you are merging with. When merging, you have to be at one of the heads you wish to merge; it's usually better to be at the head with the most changes since the common ancestor because the diffs are simpler.
After you've merged, don't forget to commit the merge. :-)
I often work with Mercurial by keeping a local store of my upstream clones, and then just cloning again locally for my actual working environment:
$ cd /clones
$ hg clone ssh://external-repo.example.com/some/repo/path/foo
$ cd ~/Development
$ hg clone /clones/foo
This is particularly useful for me because I often want to make new clones on airplanes, etc., where I have no internet access. However, this doesn't work when the original clone contains subrepos - the presence of the .hgsubstate file means that hg will always go out to the internet instead of grabbing the local cloned revision (even if they are the same). Is there any way to make a local clone copy the files without going out to the internet?
This question has an answer which would probably work, but seems very unfortunate for long-term management (deleting the .hgsubstate file in the clone in /clones/, and then making local clones from that).
You can use a "trivial" subrepository path in your .hgsub file like this:
foo = foo
bar = bar
This is the recommended setup. The advantage of setup a layout is that a clone has the same structure as the repository you clone from. You can thus clone your clones when on a plane.
Alternatively, you can use the [subpaths] setting to re-map the URLs to local paths. This lets you add
[subpaths]
http://server/(.*) = /clones/libs/\1
to your ~/.hgrc file and then you'll see that paths are remapped to /clones/libs when you clone.
You can achieve this by cloning the subrepositories yourself. Supposing that foo has a single subrepo called bar:
$ cd ~/Development
$ hg clone -U /clones/foo
$ hg clone -U /clones/foo/bar foo/bar
$ hg update -R foo
The update does not need to access the internet since the subrepository exists and contains the necessary changeset for the update on the master.
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.
I've just started with Mercurial, I have a 'central' repository on Bitbucket which I cloned onto one machine and made changes and committed and pushed. I then cloned from Bitbucket to another machine committed and pushed which was fine. I then came back to the first machine, made changes committed and attempted to push, but got the error message. What am I doing wrong? Should I have pulled first? How can I resolve the error and push? Any help is appreciated!
Darren.
A Mercurial repository gets its identity when you make the first commit in it. When you create a new repository on Bitbucket, you create an empty repository with no identity.
When you clone this repository to machine A and make a commit and push it back, then you brand the repository. If you have cloned the repository on the second machine before pushing from the first, then you can end up in the situation you describe.
Please run hg paths on the machine where you cannot push. Then make a separate clone of the repository it says it will push to. Now examine the first changeset in each repository with
hg log -r 0
If the initial changesets are different, then you have two unrelated repositories, as we call it in Mercurial. You can then export the changes you cannot push as patches and import them in the other.
If you're pretty sure the push path is correct, it may be worth it to just export your changes to patches from the problem repo, clone again from Bitbucket and then import the patches into the new repo. This will either just work or reveal a bad/corrupted commit.
I would like to share knowledge about Mercurial internals.
Repositories unrelated when they have no any same revisions.
Corresponding piece you can find in mercurial/treediscovery.py:
base = list(base)
if base == [nullid]:
if force:
repo.ui.warn(_("warning: repository is unrelated\n"))
else:
raise util.Abort(_("repository is unrelated"))
base is a list of roots of common parts in both local/remote repositories.
You always may know how repositories are different by:
$ hg in $REMOTE
$ hg out $REMOTE
You always may checks roots of both (after cloning both locally):
$ hg -R $ONE log -r "roots(all())"
$ hg -R $TWO log -r "roots(all())"
if output from above commands doesn't share IDs - those repositories are unrelated. Due to hash properties it is very impossible that roots be equal accidentally. You may not trick roots checking by carefully crafting repositories because building two repositories looks like these (with common parts but different roots):
0 <--- SHA-256-XXX <--- SHA-256-YYY <--- SHA-256-ZZZ
0 <--- SHA-256-YYY <--- SHA-256-ZZZ
impossible because that mean you reverse SHA-256 as each subsequent hash depends on previous values.
Having this info I believe any Devs be able to troubleshoot error: repository is unrelated.
See also Mercurial repository identification
Thanks for attention, good hacking!
You get this message when you try to push to a repository other than the one that you cloned. Double-check the address of the push, or the default path, if you're just using hg push by itself.
To check the default path, you can use hg showconfig | grep ^paths\.default (or just hg showconfig and look for the line that starts paths.default=).
I have multiple modules, each in their own repository.
Then there's a skeleton, which has some basic code that's common for all clients, with subrepos of some modules that are always included.
What is the best way to use this set-up on a new client?
The problem I'm currently experiencing is:
- if I clone the skeleton and then add something in the skeleton and push it to the server, the skeleton gets updated.
If I have a repository per project for the client in which I clone the skeleton, the same thing happens: the changes in the skeleton are pushed to the skeleton.
Now, I can probably fix this by cloning the skeleton and then immediately creating a new branch for the client in the skeleton, but I prefer if it has its own repository for the delivery to the server, instead of being a branch of the skeleton (which I want to use for skeleton versions, not projects).
What are your suggestions?
If I understand you correctly, the missing bit of information is that you can change the default push path after making a clone. When you run
$ hg clone http://hg.server/repos/skeleton client-a
to get a client-a clone from the skeleton repo, then Mercurial creates client-a/.hg/hgrc with
[paths]
default = http://hg.server/repos/skeleton
So hg push will now send changesets to that repository. You should instead make a new clone on the server:
$ hg clone skeleton client-a
and then make a clone of that on your machine:
$ hg clone http://hg.server/repos/client-a
Changes to the skeleton code will then no longer automatically propagate to the skeleton repo on the server.
An important down-side of this is that all your client repositories will be "compatible" This means that you can do this by accident:
$ cd client-a
$ hg pull http://hg.server/repos/client-b
This works since client-a and client-b share a common ancestor in the skeleton repository. For that reason, I would simply copy the skeleton files and adds them anew to each client repository:
$ unzip skeleton.zip
$ rm skeleton.zip
$ hg add
$ hg commit -m "Initialized repository for client-a"
Since the date and commit message will be different for each client, the repositories will become unrelated and hg push and hg pull will then error out if you try to mix changesets from different clients.