Having used hg evolve for a while TortoiseHG (version 5.6.1 on Windows) now shows a large number of obsolete changesets.
These show up red or gray, like this:
When you select one of these, THG will tell you:
Obsolete state: orphan (red items)
or
Obsolete state: obsolete (gray items)
For the most part I don't need to know about these anymore, and it would be nice to just remove them from the view (but not from the repository). Ideally I'd like the red & gray line items to just not be shown.
Looking in the THG settings and also THG documentation (1, 2) as well as web searches I haven't been able to find a way to do this. (The relevant actual Mercurial docs don't mention THG at all).
Is it possible to hide orphaned or obsolete changesets in THG?
If you enable the search toolbar, there is an icon to enable/disable hidden changesets. Caveat: I'm currently running 5.0.2 so it may be different in 5.6.1 but it should still be there.
Related
I'm playing around with Mercurial and I have a question about separating work for various tickets (I use PyCharm as my IDE, but this is more of a general Mercurial question).
My workflow goes like this: claim a ticket (bug, feature, refactor, etc), create an associated bookmark, hack away, push my bookmark up for code review, code is ready for integration testing. During integration testing I take all the bookmarks, merge them and test.
My problem is when I push my code up. The first bookmark that I push up continues along the default branch, while my 2nd, 3rd, 4th, etc bookmarks I push create new heads along the default branch. This is great because if during testing and a bug is discovered, the associated bookmark's code can be removed and the remaining code can continue to be tested / released. (IE: I can pick and choose which bookmarks to merge and test) The problem is with that first bookmark. If I understand Mercurial, you can only merge heads, which means the 2nd, 3rd, 4th, etc bookmarks that I want to merge and test must be merged with the first bookmark that was pushed up; which means if I need to rip out the code from the first bookmark, I can't (IE: the first bookmark must be part of the merged group).
Now, this can be worked around by using branches. A new branch is a new 'head', so I can pick and choose which branches to merge and test. However, it is my understanding that branches in Mercurial are suppose to be a long time thing (like having QA, testing, and release branches), and not for minor things like bug fixes.
Should I just use branches, or am I doing something wrong?
Generally, you can merge any arbitrary versions unless one is a direct descendent of the other.
A bookmark only becomes active, if you update to it.
If you want the bookmark to NOT become active, simply update to the version it is attached to by referring to the hash.
From what I understand, you are actually missing a bookmark. A bookmark which indicates the approved head and does not contain any testing code from your bug fix heads. You could bookmark that revision with the special # bookmark.
Oh wait, I figured it out; I'm just being silly, sorry about that guys.
So for future reference:
My problem was that I was unable to cherry pick which bookmarks to merge because the first bookmark would continue along the 'main line of development' and I would have to update to it (because it's a head, and I can only merge heads). However, there is absolutely nothing preventing me from updating to a different head (such as to bookmark #2) and merging in whatever bookmarks I want. IE: For some reason, it was stuck in my head that I had to update to the 'main line' head (which contains code from bookmark #1) to merge, when I don't have to.
I have two machines, window 7 with TortoiseHG 2.6 and Linux with TortoiseHG 1.5. I use bitbucket as a website to hold my centralized repository. The window machine associates with bitbucket user account, Cassie-win and the linux machine associates with bitbucket user account, Cassie-linux. Here are the steps I have performed.
created a empty centralized repository at butbucket Cassie-linux account
create two files locally, file1.txt and file2.txt on linux machines and push them to the Cassie-linux account.
Add user Cassie-win to the repository
Clone the repository to the window machine, make changes on file2.txt there and push it back to the centralized repository.
Meanwhile, also make some changes on the file2.txt which is on the linux machine and commit locally
Then I pull changes from the centralized repository at Cassie-linux account to my local linux machine. Now my linux local repository has two heads because of different contents in file2.txt and I would like to merge them together.
I used the "merge with" tool of TortoiseHG on my linux machine to merge these two heads. However, it kept failing to do so. I tried like a hundreds times and didn't know where I got it wrong. Both file1 and file2 are test files that have only three lines. I also used a command "hg resolve file2.txt" to check the error. However, it only showed that mergeing fails and didn't shown much information. Does anyone know how to use TortoiseHG merge tool to merge two heads ? And what could be the problem to stop TortoiseHG merging two heads ?
I embedded the screenshot which I took on the Linux machine which has TortoiseHg 1.5.
I right clicked the "from Cassie-win account" and it has "merge with" option. Then, I clicked the "merge" option with "merge" tool but it failed with error messages as below.
Thank you very much,
By "merge with" in TortoiseHg, do you mean you tried "Merge with Local" from the context menu of one head after updating your working directory to the other head? If so, you should have seen a wizard taking you through the steps of a merge. TortoiseHg will expect you to intervene if it cannot automatically merge the two heads. Once it asks you to do that, you have a few options including "Mercurial Resolve" and "Tool Resolve."
If you could post more details about the errors you see when the merge "fails," we might be able to be more helpful.
First things first: A merge just creates a new file version. You must commit it before it can be seen or pushed to your other repo clones.
Now, if you're doing a merge and the same line, or adjacent lines, have been modified in both merge parents, the automatic merge won't succeed and you'll be asked to choose what to do at each conflict point. Kdiff3, the tool that TortoiseHG uses for merging the files on Windows is not terribly intuitive, so here's an overview:
If there are multiple files to merge, you'll see a directory control. Navigate to one of the files and open it so you see two file versions side by side.
Depending on the circumstances, you may now have to activate "Merge this file" (in the Merge menu and on the toolbar), which will show you a third version of the file (the merge result) below the other two.
You can now navigate from change to change, and click on the A and B buttons to select which change to use. Note that the buttons are toggles, and it is possible to activate both together (to import both versions to the merge). Note also that you'll also see diffs that could be automatically merged. In general you can leave them alone (there are navigation buttons that go directly to the next unresolved diff).
Once you've figured out how to work all this and chosen a version for each diff, you'll be able to save and go on to the next file. When you're done, your merge is ready to commit.
Edit:
So you need to do this on the Linux side, and you've got no Kdiff3. Ok, then do it the old-fashioned way: Using the commandline and a regular editor.
When a merge fails, the conflicted file turns into a context diff that includes both revisions. Open it with your favorite editor, look at it carefully and clean up each context-diff region (you'll know them when you see them) until you have a clean, usable file just as you want it to be.
Exit, drop to the command line and type hg resolve -m file2.txt. This removes the file from the list of conflicts.
When you've done this with all conflicted files (you can list them with hg resolve -l) you'll be allowed to commit, and your troubles are over.
PS. If you don't like the merge tools you've got, consider installing kdiff3 (it's available for linux, but no idea how well it works), or p4merge as #LazyBadger suggests.
Side notes
You can exchange data between your hosts without "Bitbucket-in-the-middle": just hg serve on both hosts and hg pull <PARTY> on opposite side
You could use single BB-account from both our hosts (less management on BB-side) and differentiate source of every changeset in Bitbucket interface only by usernames in changesets
To the question of merges
When (in any SCM) you try to merge two diverged lines of coding, there are two possible cases
Independent changes are not overlapped and can be combined into common descendant without user's intervention. If this case merge "just happens"
Changes are intersected and some strings are in conflicted state: i.e we have two different changes for some old data. It this case user's choice is needed and SCM or store merge-result with conflicted parts marked (and note merge as unsucceful and unfinished before appropriate user-action) or run user-defined merge-resolver (read "Visual Merge Tools")
In your situation, obviously, he have second case: some strings from 3 in merge-sources was in conflict and you haven't configured in TortoiseHG Diff/Merge tools (TortoiseHG - Global Setting - TortoiseHG)
Have and add these tools will be best choice for future. Now you have by hand edit file-in-conflict and select correct data in conflicted lines, mark conflict as resolved (check TortoiseHG context menu of file), remove temp-files and, at last, commit merge
I have a mercurial version control installation in my company. We have central repository and regularly pull changes from there.
Several files on my computer are marked as newer ones. But really they already exist there.
If I delete them physically, they became marked as removed. If I revert them, they become newer ones.
I already tried to reload this repository to newer place, but situation was repeated.
Can anyone help me?
It sounds a lot like you're pulling but not updating.
Pulling gets the changesets others have made, but they don't become active in your code directory until you update to them.
If I've misunderstood, could you post a sequence of commands, with the output you get, to demonstrate the problem?
If you miss icon overlays for some files, you can try TortoiseHG - Update Icons (or just cd forward and back some time, restart Overlay Icon Server...)
If you miss icon overlays for all files of some type, you may reach limit of overlays for your OS (bundle of different Tortoise* can give such effect)
The problem that I'm running into is that I have some code reviews to do, with ~10 commits per review. It's an active repo with constant commits from developers. I have TortoiseHg filtering my changesets so that I am looking only at the ones that I care about.
What I would like to see is the difference between the changeset before the first change, and the last (without all the non-related changesets showing). I simply want to see the final results of all these changes. I don't care that there was some horrible code in changeset 1, that was fixed in 3. I just want to see the diff of what ultimately got merged through all these changesets.
I feel like I'm missing the obvious, and this isn't a bright question. Nevertheless, I'm asking anyways. Anyone?
I'm not sure about 1.1.8, as I'm using the 1.9/2.0 candidate release, but I believe you could left-click on changeset1, right-click on revision3 and select visual Diff. This should open your diff tool of choice and only show you the diffs between the 2 versions.
When I did this in the newer tortoise, it opened BeyondCompare in directory compare mode, with revision1 on one side, and revision2 on the other.
Don't merge in between commits and diff off the developers clone between start and finish changesets.
Or If merges occured, update and merge everything and then take the entire codebase (or just changed files) and dump it onto a clean tip clone (make sure you are working with the same version to avoid overwriting anything). Recommit all at once.
After having solved the problem of getting the editor to launch when there's a merge conflict - Mercurial: No editor appears when merge conflicts are detected
I now have another problem, the editor now launches but opens the files in the following order:
hello.c
hello.c~base.????
hello.c~other.????
But what I really want to see is the file that highlights the conflicts, which I expect should be the first one hello.c, but instead hello.c just shows the tip.
Any advice?
Regards,
Chris
I'm not sure what tool you're using for merges, but it sounds like it's doing a 3-way merge. The left pane is normally the common ancestor, the middle pane is the file you're merging in, and the right pane is your changes to the file.
I really like kdiff3 (free and open source) for merges and would recommend it if the tool that you're using isn't working for you. It's in the mercurial documentation as the example merger that they use in many places.
The first file ends up being the finished merge, so you need to make sure you manually copy in all changes from the other two files. Vimdiff works well for this as it highlights all differences between the three files. I'm not exactly sure how the three files are generated, but this process does seem to work for me.