I'm following this post Codeplex: Updating a Fork with Changes from the Master Repository but it seems like it doesn't work for me. As I'm new to Mercurial, I might be missing something..
Scenario
Here is the URLs of the main repository and my fork. I created a fork from main repository a few months back.
Main Nuget repository : https://hg.codeplex.com/nuget.
My fork repository : https://hg.codeplex.com/forks/michaelsync/msyncwillmakeyoubetter.
Problem
I can't update my fork with the changes from master repository.
Steps taken
Here is the steps that I tried to do but it didn't work.
PS C:\michael sync\git\nuget> hg clone https://hg.codeplex.com/forks/michaelsync/msyncwillmakeyoubetter
destination directory: msyncwillmakeyoubetter
requesting all changes
adding changesets
adding manifests
adding file changes
added 2231 changesets with 13584 changes to 3800 files
updating to branch default
1205 files updated, 0 files merged, 0 files removed, 0 files unresolved
PS C:\michael sync\git\nuget> cd .\msyncwillmakeyoubetter
PS C:\michael sync\git\nuget\msyncwillmakeyoubetter> hg pull https://hg.codeplex.com/nuget
pulling from https://hg.codeplex.com/nuget
searching for changes
adding changesets
adding manifests
adding file changes
added 301 changesets with 2574 changes to 838 files (+1 heads)
(run 'hg heads' to see heads)
PS C:\michael sync\git\nuget\msyncwillmakeyoubetter> hg commit -m "sync the changes from main respo to my fork"
nothing changed
PS C:\michael sync\git\nuget\msyncwillmakeyoubetter> hg push
pushing to https://hg.codeplex.com/forks/michaelsync/msyncwillmakeyoubetter
searching for changes
abort: push creates new remote branches: 1.6, 1.6.1, 1.7!
(use 'hg push --new-branch' to create new remote branches)
What I don't understand is that how come there is no change after pulling the code from master repository. It said nothing changed when I tried to commit.
I checked these posts How can I get the changes from a "master" repository in mercurial for a project hosted on google code? and Mercurial - how to fetch latest changes from parent of fork? but couldn't make it work until now.
First of all, it is really important to understand what exactly the various commands you used do :
pull : retrieve the changes from a repository, but don't apply them to the working copy
commit : apply the changes on the working copy to the local directory
push : push all change sets in the local repository to the remote one
update (which you didn't use) : update your working copy to a specific changeset from the local repository
You'll notice that I use two different terms, working copy and repository.
The repository is all the change sets available, with the various branches, heads, etc.
The working copy is the files you actually see in your file explorer, they can be to totally different state than the last changeset in the repository.
So, once you did your pull, if you want to "apply" the changes to your working copy, you must do an update, Alternatively, you can also du hg pull -u. If you made some changes since the last pull, you may have to merge instead of updating, if you look at the documentation you've linked, they're doing a merge (step 3).
If the update was successful, no need to do a commit, the changes are already in your local repository. If you had to do a merge, a commit will be necessary to acknowledge the changes you made.
Concerning the push part, you're creating new branches by doing so like stated by the error message. By default, Mercurial don't push changesets creating new branches, you must use the stated command : hg push --new-branch or push a branch specifically hg push mybranch
I hope my explanations are clear enough, otherwise feel free to comment. I also recommend you read some tutorial about Mercurial, for example this one : http://hginit.com/
Related
We have a project that lives in a mercurial repository.
Our customer would like to take ownership of the code base by doing the following:
Set up a mercurial repository on a server belonging to the customer.
Import the existing code into the new mercurial repository.
What is the best way to achieve step 2?
Is it a simple matter of doing the following:
Clone the existing mercurial repository:
hg clone <existing mercurial repo URL>
Push the cloned repository into the new one:
hg push <new mercurial repo URL>
Am I missing any steps? What about the hgrc file? Does it have to be modified in any way prior to pushing the project into a new repository?
Yes, you can do what you state, however it is worth noting that if you do a simple hg clone of your main repository, then a link will exist between the two, which may not be what you want. You can remove this link by editing the .hg/hgrc file and removing the default = ... item in the [paths] section.
I find that a better way is to do it without cloning. This way you don't have the link between repositories, which as this is going to a customer may be what you want.
The basic method is to set up a new repository with no changesets, and then bring in all of the changesets in one of three ways:
Push the changes from your repository to the new repository.
Pull the changes from into the new repository from the old.
If you don't have access to the new repository, create a bundle that can be provided to the customer - this can then be unbundled or pulled into the empty repo.
Pushing and Pulling is done as you normally would, but specifying the repository location:
// create the empty repository
hg init .
// pull in everything from the old repo
hg pull /projects/myOriginalRepo
or to push...
// create the empty repository
hg init /projects/myNewRepo
cd /projects/myOriginalRepo
hg push /projects/myNewRepo
Creating a bundle is perhaps a nicer way, as you can write the bundle onto a DVD and give it to your customer wrapped in a bow with a nice greeting card:
cd /projects/myOriginalRepo
hg bundle --all ../repo.bundle
Everything gets written out to a single file, which can then be extracted with hg unbundle repo.bundle or hg pull repo.bundle, into a repository with no existing changesets.
Regarding the hgrc file, as already mentioned in another answer it is not a controlled file, and so won't be copied. However, any contents are likely things like hooks to perform auto-building, or validating changesets before they are applied. This is logic which would probably only make sense to your own organisation, and I would suggest you wouldn't want this to be imposed on your customer - they are, after all, taking ownership of your code-base, and may have their own systems in place for things like this.
In the simple case - it's all.
But if you have modified .hg/hgrc file then you need to move it to the remote server manually and (if necessary) modify it correspondingly to a new environment.
Ie: you could have hooks set up in the original repository.
As of clients - just change a path to a repository in a default section (or any other section if you have several specified)
To move the master repository, you need to (a) create the new master repo and (b) tell the existing clients about it.
Create the new master repo any way you want: cloning or init+pushing, it makes little difference. Be sure to move any contents of the old repo that are not under version control, including .hgrc and any unversioned or ignored files that are not discardable. If you cloned, edit the new master's .hgrc and remove the default path, so that it doesn't try to talk to the old master repo any more.
Existing clones of the old master repo still push/pull from the old master. Everyone must edit their .hgrc, updating default (and/or default-push) so that it points to the new location. (They may also need to update authentication credentials, of course).
Only then is the migration complete. Remove (or move/hide) the original repo so that if someone forgot to update their repo path, they'll get an error on push/pull instead of pouring data down a memory hole.
We have a master repository located on a separate server. I originally cloned the default branch and made my changes locally. I have locally commited those changes. However, there has been a branch created on the master repository that I would like to push my changes to. Below is the description of my attempt at getting this accomplished.
I have cloned the branch. I am trying to export my changes from local default like so:
C:\hg\default>hg export -g -o mypatch -r tip
and when trying to import them into the clone of the new branch, I get the following:
C:\hg\newBranch>hg import C:\hg\default\mypatch
applying C:\hg\Fill1\mypatch
patching file .hgignore
Hunk #1 FAILED at 11
1 out of 1 hunks FAILED -- saving rejects to file .hgignore.rej
abort: patch failed to apply
I can manually fix the .hgingore.rej file just fine. The problem is that the patch also contains files that were moved. Instead of the files showing as moved, I get the following when running hg status:
C:\hg\newBranch>hg status -C
M someOtherFilesThatLookAsExpected.txt
! originalLocaion\fileA.txt
? newLocation\fileA.txt
This missing and new status is for all files that were moved in the commit contained the applied patch. Am I doing something wrong? Do I always have to manually move files when applying a patch? Is there an easier way to accomplish this branch transfer?
That's a bit difficult to answer without knowing more about your repository structure, but here's how I'd go about it without knowing more. I'm assuming that the reason for the conflict is that there are conflicting changes in the same branch of the repository.
First, get the contents of the newBranch repository:
cd c:\hg\default
hg pull c:\hg\newBranch
Then, either merge or rebase your changes on top. If you are working on the same branch, then just using
hg pull --rebase c:\hg\newBranch
in lieu of the regular pull should do (assuming you have rebasing enabled). Otherwise, do an explicit merge or rebase of the two heads that you need to reconcile. Finally, do:
hg push -r tip c:\hg\newBranch
in order to get your (now reconciled) changes back into newBranch.
Unless you have very specific and unusual requirements, push and pull should be your normal way to sync repositories or part of them (note that using -r will only push/pull the respective branch). Export/import are rather low-level mechanisms that may not give you the benefits of the standard machinery that handles renames, three-way merging logic, etc.
I am making say 4 local commits in HgSVN, then I updated my local code to an earlier revision, I added changes to it, did local commits, merged with server code and when tried to push, I was not allowed because of the 4 local commits not merged.
How to delete/remove these 4 local commits from HgSVN history and push the code ?
What should be done in this scenario ?
using HgCommit for saving code to the local machine and
HgWorkbench for pushing the local changes to the server
Your main big problem: you prefer do nor read docs and use tools blindly. Otherwise you have to know one of the biggest limitation of HgSubversion: it is not possible to push back to Subversion mergesets from Mercurial
"...Mercurial merges cannot be pushed to Subversion"
Also, HgSubversion page on Mercurial wiki clearly states:
The important point to note is that hgsubversion cannot push merge changesets to a svn repository. This means you should not try to merge this new head -- if you do so, hg push to svn will fail. Instead, you should rebase the changesets that you want to push to the Subversion repository (see Rebasing changes below)
I have a repository, called "my project" based in a framework called "framework". The two of them have each it's repository, unrelated between them, with each branches and tags. I want to receive "framework"'s updates in my repository, but only from "default" branch and not from others. And, of course, I do not want to have "framework"'s tags in my repository, as it is a totally different project.
I have Mercurial HG, and I would like to be able to pull changes from "framework" repository directly from my "Manage repository" page.
Furthermore, I only want to download latest changesets, since I started my project not long ago. And It would be perfect if I could rename the "framework"'s default branch to other name in my repo, e.g. "Framework Changesets".
Note: I do not have write access to the "framework" repository.
I tried to do what mercurial wiki said:
hg pull -f -r default "framework"
It was OK, until I realised I had downloaded all the tags from the "framework" repository, and I had downloaded all the changesets from the remote repository. Furthermore, when in TortoiseHG->Configuration->Synchronization I put the "framework" repository as a remote repository for that project, and pulled from the remote repository, I got all the branches from that repository.
Of course I wasn't able to change default branch name, and updated my default branch, even though I tried to use hg convert --branchmap (but I didn't know how to use it).
Is there any solution to my problem? or even a partial solution?
I think you can address this issue through a combination of these things:
Pulling specific branches
Using the command line: hg pull -r <branch name>
Using TortoiseHg v1.1.X:
Check for incoming changesets by using the button labeled Download and view incoming changesets
Right-click on the tip of the branch you want to pull and select Pull to here
Reject the rest of the changesets using the Reject button
Removing existing tags
You can always hand-edit the .hgtags file to remove tags created on the "framework" branch, but I don't know of a way to pull changesets without the tags.
Changing branch name
Using the mq extension you can change the named branch that your new "framework" changesets live on. See answer to "Apply patches in branch" for instructions on how to do this in TortoiseHg v1.1.X, as well as the CLI. The basic idea here is to create a named branch with the name you want, import all of the "framework" changesets you pulled into a patch queue, and then apply them to the new named branch. They will shed the branch name from "framework" and use the branch name of the branch you applied them to.
If you are going to pull from "framework" more than once, you would need to use the patch queue to move only the new changesets with each pull. It should be easy to see which changesets you haven't moved yet.
We can specify the branch name by appending branch name with a # symbol in the clone url.
e.g.
hg clone --verbose https://user#cloneurl/my_product#MY_BRANCH "C:\myCode"
Suppose that:
I have a repo called MyRepo.
I have uncommitted changes in my working directory.
I do a pull from Repo1 and that creates a branch in MyRepo
I want to do a merge of what I already had in my repo with what I have just pulled.
As described here, the merge process changes the state of the working directory.
In my scenario, I don't want to loose the uncommitted changes that are in my working directory because at that point, I'm interested in changing the state of MyRepo; not the state of my working directory.
Is there a way to go through the merging process, including resolving conflicts manually, without affecting the content my working directory? Can this process be done in temporary files only? Or should I shelve my changes, do the merge and then unshelve to restore my working dir to the state it was before the merge?
Use shelve or attic extensions to temporarily stash your changes while you merge.
You could clone your repository to your latest checkin, merge the changes with the clone, commit, and then pull the new changeset from your cloned repository back into your current one.
You can't do that. As the documentation says, merge really is a working tree operation. Resolving conflicts without testing the result is crazy. Either shelve or commit the changes and then do the merge. If you don't want the commit to be visible anywhere, you can commit the change, update to the previous revision, merge the new branch, apply the temporarily committed patch and strip that temporary branch.
Just do it in a clone.
Clone MyRepo to MyRepo-merger, which will pull over all the committed changes, but not your uncommitted changes
Inside MyRepo-merger do a pull from Repo1.
Inside MyRepo-merger do all the hg merges you want
Inside MyRepo-merger push to either Repo1 or the original MyRepo
Pushing back to MyRepo won't alter the working dir of MyRepo, so that's a safe action.
Remember in Mercurial that clones are incredibly fast and cheap -- on modern file systems they use hardlinks under the covers so they're not even taking up much space on disk.
I'm pretty new to mercurial, but couldn't you clone from your local repository and copy your working copy over to the clone? You could then run your merge in the original? You'd preserve the state of your working copy in the clone while being free to allow the change of the original's working copy.
Test this first. I've never done it in hg.