I pulled from the newfeatures branch in one of my Mercurial repos using TortoiseHg. Now whenever I try to pull from ANY of my repos, it tries to use the newfeatures branch, which doesn't exist on any of my other repos.
I cannot find any setting to let me fix this. I uninstalled TortoiseHG and reinstalled it and the problem still occurs. I deleted all my local repos and tried recloning them and the problem still occurs.
My Mercurial.ini does not specify a branch. If I go into the console and type hg branch it reports default. TortoiseHg workbench says Branch: default above selected options and the selected options are --pushafter = True . However, every time I try to pull, the output log reads hg pull --verbose --branch newfeatures.
How can I fix this?
Could it be because of the Target check box in the Synchronize panel? Even if the panel is not visible, the Pull button uses those settings when TortoiseHg issues the hg pull command.
Related
I'm new to Mercurial, and I'm using the Stable/Default branching system. We're all on Windows here, and I'm trying to get everyone else to work in this system. We're all using TortoiseHg. I'm trying to document how to Merge changes into stable and tag releases, but I've only been using Mercurial for about three weeks, so I'm not even sure I'm doing this correctly. Also, TortoiseHg seems to be missing a few options available from the command line. But, I need to make this work from the Windows shell, or it won't get adopted here.
All of our programming work is done in default, and the stable branch is used only for releases of the software. One thing that leads me to believe I'm doing something wrong is that, after every merge, I have to re-make the stable branch. Is that normal? Seems counter-intuitive.
Below is the procedure I wrote up. Please feel free to point out my idiocy or ask any questions. And thank you in advance for any comments.
On my laptop, there are two directories for each project. The devel directory stores a clone of the default branch,
===============
Merging the branches and creating a stable release, TortoiseHg
-- Commit in the devel repository.
-- Open the devel local directory.
-- Start HgWorkbench.
-- Click the latest stable version of the stable branch.
-- Select Merge with local...
-- Synchronize and push changes to the remote repository.
-- Go to the local stable repository.
-- Synchronize and pull from the remote repository.
-- Update to the latest default branch. Picking "update to tip" should be best.
-- TortoiseHg -> commit. Commit to branch "stable." You'll need to re-create a new branch. When it asks, select "Restart branch."
-- Open HgWorkbench and add a tag for the latest stable version. Example "Version X.X"
-- Synchronize and push to the remote repository. Use the Options button in the Sync dialog box to bring up the "sync options" dialog. In the bottom field labeled "Branch", type "stable"
-- Return to the local "devel" repository.
-- Synchronize and pull from the remote repository. Use the Options button in the Sync dialog box to bring up the "sync options" dialog. In the bottom field labeled "Branch", make sure the field is blank. Otherwise, it will default to the "stable" branch.
There's no need for the second clone to achieve what you want and I think that it adds complexity where it isn't needed.
This is what I'd do:
Have a single clone of the repository
Commit in the default branch
Start HgWorkbench
Right click the latest changeset on the stable branch
Choose Update... in the pop up menu and press the Update button in the pop up window (use the default options)
Right click the latest changeset in the default branch
Choose Merge with local...
If the working directory status is shown to be clean (it should be) then click the Next button
If there are no merge conflicts (again, there shouldn't be if you do no development in stable) click the Next button again
Enter a commit message and click the Commit button and the press Finish on the next step
Right click the last changeset in the stable branch and choose Tag..., enter the tag name and press the Add button.
Right click the last changeset in the default branch and choose Update... using the default options again
You've now got a tagged stable branch and are back on the default branch to continue development. When you're ready to release a new stable version then repeat the steps above from step 3.
Is it possible to rename 'default' to 'production' in TortoiseHG?
You cannot rename a branch in Mercurial (or TortoiseHg for that matter). What you do instead is to start a new branch called production and base it on the current default branch.
You can do this in TortoiseHg 2.0, where you
Click the row representing the working directory
Click the branch button
Click to open a new branch
Fill in the branch name and click OK
Enter a commit message and click Commit.
This will create a new branch with the name production. The old default branch will remain and you can thus put new features there before merging them into production when they're stable.
You cannot do it directly from the Tortoise2.0+ settings, but through the command-line hg.
As documented in hgbook:
Mercurial lets you assign a persistent name to a branch.
There always exists a branch named default. Even before you start naming branches yourself, you can find traces of the default branch if you look for them.
To start working with named branches, use the hg branches command
$ hg branch production
marked working directory as branch production
$ hg branch
production
Check then if that change is reflected in TortoiseHg
I've just recently moved a lot of my Views and Controllers into more appropriate locations and am now wanting to pull down recent changes from our central repo.
I've done a hg pull which worked fine and asked me to do a hg update to bring the changes down locally. This in turn informed me that I needed to do a hg merge however when I try this, I get a message stating that
abort: outstanding uncommitted changes
When I check this using hg status I see in the list all of the files that I've moved (so they're now deleted from their old location).
How do I tell Mercurial that I've removed these files? Do I have to go through each one of them and manually do a remove? Is this something that's possible using only the command line rather than doing it with a GUI tool?
From the command line to automatically hg rm the files you've removed you'd:
hg addremove
It's likely your GUI (you didn't say which you use) exposes that functionality too.
However, that's not what's causing your message. You have some already made local changes that mercurial does know about (unlike the removed files which it doesn't know about until you tell it), and you need a hg commit before you can merge.
I use an ant file to build a java project in mercurial through hudson.
The mailnine has a hudson job running just fine.
Recently a new branch was created and pushed to the server by commnd line:
hg branch newbranch
hg commit
hg push -f
The mainine does not contain these changes and still builds fine.
I have set up a new job with the same setting as mainline (in fact copied mainline job in hudson), and specified the newbranch.
However, the newbranch job builds code identical to mainline.
If I commandline clone the repository and switch to the newbranch everything looks as expected. This seems to be a hudson configuration glitch unless my merqurial skills are off course.
I have also tried to set up the job from sratch with settings identical to mainline with the addition of the newbranch specification without any luck.
What am I missing?
Anyone any ideas?
Try putting the branch in the URL to clone like:
http://server/path/to/repo#newbranch
or
ssh://user#server//path/to/repo#newbranch
You can see the full syntax for branch-in-repo-url using hg help urls
URL Paths
Valid URLs are of the form:
local/filesystem/path[#revision]
file://local/filesystem/path[#revision]
http://[user[:pass]#]host[:port]/[path][#revision]
https://[user[:pass]#]host[:port]/[path][#revision]
ssh://[user[:pass]#]host[:port]/[path][#revision]
Paths in the local filesystem can either point to Mercurial repositories
or to bundle files (as created by 'hg bundle' or 'hg incoming --bundle').
An optional identifier after # indicates a particular branch, tag, or
changeset to use from the remote repository. See also 'hg help revisions'.
One issue with cloning a job is that the 'cloned' job is created as soon as you hit the clone button. While you are still configuring the cloned job, it may hit a build trigger like an SCM polling event that causes it to kick off before you have fully configured it.
I believe this was fixed in later versions of Hudson, but cannot find the changelog entry for job cloning. The same issue existed for cloning a slave configuration, and the problem was fixed in Hudson 1.319.
Using TortoiseHg Synchronize, clicking "Pull" pulls down the 2nd most recent revision.
At the bottom of the Synchronize interface is a button, "Update to branch tip." Clicking this button pulls down the most recent revision.
What is happening here?
Command line hg tells this:
$ hg help pull
...
Pull changes from a remote repository to a local one.
...
-R is specified). By default, this does not update the copy of the
project in the working directory.
vs.
$ hg help up
...
Update the repository's working directory to the specified
revision, or the tip of the current branch if none is specified.
If you are new to mercurial or want to know you havent missed any options, this is could be helpful:
http://blog.hanxiaogang.com/hg-guide/