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.
Related
I read about bookmarks in mercurial, every source states that it's like git branching, that the bookmark gets updated uppon every commit, but I really don't understand what's its purpose. Any guidance would be greatly appreciated. Thanks.
From the Mercurial wiki:
Bookmarks are references to commits that are automatically updated
when new commits are made. If you do hg bookmark feature the feature
bookmark refers to the current changeset. As you work and commit
changes the bookmark will move forward with every commit you do. The
bookmark will always point to the latest revision in your line of
work. Since bookmarks are automatically updated when committing to the
changeset they are pointing to, they are especially useful to keep
track of different heads. They can therefore be used for trying out
new features or pulling changes that have yet to be reviewed.
I also suggest reading this article for an overview of the various ways to branch in Mercurial.
I suggest not taking bookmarks and trying to find a use for them, but rather finding a process you find natural to use in your team and then finding how Mercurial best handles branches in the context of that process, be it with bookmarks or cloning or what have you.
Adding just a few minor details, to the excellent points of Mihai Danila:
Bookmarks are, in a few words, a lot like: "movable tags without a permanent movement log".
There are various features built on top of the 'movable tag' property, like merging of bookmarks from other clones, automatic movement of the bookmark as you commit on top of it, etc. But the basic idea is pretty much just that. A symbolic name that you can attach to a changeset, much like a 'tag', but one that can move arbitrarily forward or backward in history as required.
You can definitely built a branching scheme on top of bookmarks. In fact, Mercurial itself has adopted the names 'crew' and 'crew-stable' for two bookmarks that the development team uses to coordinate Mercurial's own development. But you don't have to.
I agree 100% with what Mihai wrote: "Don't take bookmarks and try to find a use for them, but rather find a process you find natural to use in your team and then find out how Mercurial best handles branches in the context of that process, be it with bookmarks or cloning or what have you".
What's the difference between a tag and a bookmark in Mercurial? I can't seem to find any discussion of how the two differ.
Lets consider your repository as a "choose your own adventure books", with different points of view.
A tag is like a stamp that the editor put on your manuscript to say "ok, we keep a trace of your current work, in case shit happens."
A named branch would be a chapter. You have to choose at one point which chapter you'll have to write, and they are there to stay. Some will merge back, some will end (sorry, you died.)
A bookmark is, well, a bookmark. It follows you while you're reading (committing) the book. It helps you to keep tracks of "what you were reading at that time", so you can remove them, move them to a different "chapter". When you share the book (push), you usually don't share your bookmarks, unless you explicitly want to. So you usually use them on anonymous branches because their life cycle is shorter than named branches.
Bookmarks are used when you want a mnemonic (foo_feature) that points to a changing commit id as your work progresses. They're more light-weight that regular Mercurial branches, and somewhat similar to the way git branches work.
Tags generally point to fixed commit ids. They can be reassigned manually, but this is discouraged.
There are actually five concepts to play with:
tags
local tags
bookmarks
lightweight branches
named branches
Lightweight branches are what happens if you just use mercurial. Your repository history forks and sometimes merges as you change things and move around your history.
The other four are ways of annotating lightweight branches and the changesets that make them up.
named branches and tags are mercurial-only concepts where the branch names and tags actually get recorded in the repository by making more commits to the repository. They'll tend to propagate to other repositories in ways which are not necessarily obvious.
local tags and bookmarks are much more like what git calls tags and branches. They're metadata rather than being mixed in with the versioned objects. So they're not represented as part of the repository history. They tend to be local to your repository, and won't propagate unless you propagate them deliberately.
At least I think that's how they all work. After about twelve months of using mercurial daily I haven't really got to grips with its model(s). If anyone knows better than me then feel free to edit this answer so it's correct.
How I actually use these things in practice.
I'm working on a single shared repository with about 20 other people. I make many experiments and lightweight branches in my own private repository, which never get pushed to our main central repository. Occasionally once an experiment has worked out I'll modify the main line and push a changeset into the central repository, from which it will find its way to everyone else's machine.
I'll occasionally push some changesets to a co-worker if they're one of the people who's comfy with how mercurial works. But several people are a bit scared of it and prefer if I send them diffs that they can apply with patch.
For experiments I expect to be short lived and private, I just let lightweight branches happen where they may, and remember what's going on. If I feel my memory slipping about a twig that's been around for a bit, I bookmark it.
I use local tags to mark revisions I might like to come back to one day. They make interesting past states easier to find.
I myself almost never make non-local tags or named branches (except by accident, and I destroy them if I do). But our release people do. Our released major versions all have their own named branches off from the main line, and minor versions have tags on those branches. That ensures that these important branches and tags look the same to everyone.
Again, I've no idea whether this is how one's supposed to use mercurial, but it seems to be a model that works well for our size of team.
If three or four of us wanted to collaborate on an experiment, that would probably be worth a named branch, which we'd probably share between ourselves but not push to the central repo. I don't know how well that would work out!
The biggest difference is that a bookmark is automatically moved forward when you commit. Here's an example:
hg init
..edit a file..
hg commit -m 'my commit' # creates revision 0
hg tag -r 0 mytag # creates revision 1
hg bookmark -r 0 mybookmark # doesn't create a revision
hg update 0 # get back to r0
..edit a file..
hg commit -m 'another commit' # creates revision 2
At that point mytag is still pointing to revision 0 and mybookmark is now pointing at revision 2. Also the tagging created a changeset and the bookmark didn't.
Also, of course, the bookmark created a revisio
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.
Changes were made to our .vcproj to fix an issue on the build machine (changeset 1700). Later, a developer merged his changes (changes 1710 through 1715) into the trunk, but the mercurial auto-merge overwrote the changes from 1700. I assume this happened because he chose the wrong branch as the "parent" of the merge (see part 2 of the question).
1) What is the "correct" mercurial way to fix this issue, considering out of all the merged files, only one file was merged incorrectly, and
2) what should the developer have done differently in order to make sure this didn't occur? Are there ways we can enforce the "correct" way?
Edit: I probably wasn't clear enough on what happened. Developer A modified a line in our .vcproj file that removed an option for the compiler. His check-in became changeset 1700. Developer B, working from a previous parent (let's say changeset 1690), made some changes to completely different parts of the project, but he did touch the .vcproj file (just not anywhere near the changes made by Developer A). When Developer B merged his changes (becoming changes 1710 through 1715), the merge process overwrote the changes from 1700.
To fix this, I just re-modified the .vcproj file to include the change again, and checked it in. I just wanted to know why Mercurial thought that it shouldn't keep the changes in 1700, and whether or not there was an "official" way to fix this.
Edit the second: Developer B swears up and down that Mercurial merged the .vcproj file without prompting him for conflict resolution, but it is of course possible that he's just misremembering, in which case this whole exercise is academic.
I will address the 2nd part of you question first...
If there is a conflict, the automated merge tools should force the programmer to decide how the merge happens. But the general assumption is that a conflict will involve two edits to the same set of lines. If somehow a conflict arises because of edits to lines that are not close to each other the automated merge will blithely choose both of the edits and a bug will appear.
The general case of a merge tool always merging properly is very hard to solve, and really can't be with current technology. Here is an example of what I mean from C:
int i; // Someone replaces this with 'short i' in one changeset stating
// that a short is more efficient.
// ... lots of code;
// Someone else replaces all the 65000s with 100000s in another changeset,
// saying that more precision is needed.
for (i = 0; i < 65000; ++i) {
integral_approximation_piece(start + i/65000.0, end + (i + 1) / 65000.0);
}
No merge tool is going to catch this kind of conflict. The tool would have to actually compile the code to see that those two parts of the code have anything to do with eachother, and while that would likely be enough in this case, I can construct an example that would require the code to be run and the results examined to catch the conflict.
This means that what you really ought to do is rigorously test your code after a merge, just like you should after any other change. The vast majority of merges will result in obvious conflicts that a developer will have to resolve (even though that resolution is often fairly obvious), or will merge cleanly. But the very few merges that don't fit either category can't easily be handled in an automated fashion.
This can also be fixed by development practices that encourage locality. For example a coding standard that states "Variables should be declared near where they're used.".
I'm guessing that .vcproj files are particularly prone to this problem since they are not well understood by developers and so if conflicts do appear they will not be sure what to do with them. My guess is that this happened and your developer simply did a revert back to the revision (s)he checked in.
As for part 1...
What to do in this case depends a lot on your development process. You can either strip the merge changeset out and redo it, though that won't work very well if lots of people have already pulled it, and it will work especially poorly if there are lots of changesets that have already been checked in that are based on the merge changeset.
You can also check in a new change that fixes the problem with the merge.
Those are basically your two options.
The tone of your post seems to me to indicate that you may have some politics surrounding this issue in your organization, and people are blaming this error on the frequent merges of Mercurial. So I will point out that any change control system can have this problem. In the case of Subversion, for example, every time a developer does an update while they have outstanding changes in their working directory, they are doing a merge, and this kind of problem can arise with any merge.
In mercurial a merge doesn't have a single parent, it by definition has two and only two parents. When someone is merging they're making two choices:
What two changesets will constitute the two changes
Which of those changesets will be the left-parent and which will be the right-parent
Of those two questions the first is very important, and the second barely matters at all, though it took me a while to come to understand that.
You select the left-parent by using hg update X. That changes the output of hg parents (or in newer versions hg summary) and essentially determines what's in your working directory before the merge.
You select the right-parent by using hg merge Y. That says merge X (the working directory's parent) with changeset Y. As a special case, if there are only two heads in your repository and your parent is already one of them then Y will default to the the other.
I'd have to see your resulting graph to know just what the developer did, but it's possible he didn't update to one head or another before invoking merge, which would have him merging one head with some point back in history.
If your developer picked the right parents for the merge then the left vs. right doesn't much matter -- the only real difference is that when one uses hg diff or hg log -p or some other command that shows the patch for a merge changeset, it's displayed relative to the left-parent. That's, however, mostly a factor in display only. Functionally they're pretty much identical.
Assuming your developer picked the right changesets then what he should have done was test the result of the merge before committing it. Merging is software development, not an annoying VCS side effect, and not testing before committing is the error.
Fixing
To fix this, just re-do the merge correctly. Use hg update to set one parent, use hg merge to pick the other. Make sure your current working directory is correct and then commit. You can get rid of his bad merge using something like hg strip or better, just close down his branch with hg commit --close-branch after updating to it.
Avoiding
You say "mercurial auto-merge", but mercurial doesn't really auto-merge. It does a premerge which is an extremely cautious combination of obvious changes, but it's so careful it won't even merge for you if each merge parent adds code in the same region because it can't know which block of code you'd rather have first.
You can disable this premerge entirely or on a file-by-file basis using the merge tool configuration options:
https://www.mercurial-scm.org/wiki/MergeToolConfiguration?highlight=premerge
I downloaded TortoiseHg 1.0 for evaluation. For the life of me I can't figure out how to make a branch. It seems to understand branches (e.g. in its repository browser) but I just can't seem to find a way to make a branch. This seems like such a fundamental capability since out of the often touted benefits of DVC is the lightweight branching.
I Googled around and couldn't find much discussion of this topic (at least for recent versions) so I have to assume I'm missing something, right?
Update: So I flagged Chad Birch's answer below to answer the "new branch" issue. As he correctly points out, you do a commit and then click on the branch button to bring up the branch maintenance dialog which is where you create new branches. I kind of wish they had given us a context menu option for this. Once you've branched, the next natural question is how to merge and this is also not obvious. It turns out that option is buried in the repository explorer. You need to select the head of another branch, right-click and then select "Merge with...".
As shown in the docs, all you should need to do is just click on the branch: default button near the top of the commit dialog, and change to a new branch name.
To start new branch with TortoiseHg press Commit... then, above Commit message press Branch, then "Open new named branch: "
Just wanted to add that in order to push new branch to remote repository there is a checkbox on the Synchronize tab under Options of "Allow push of a new branch" - you have to remember to turn it off again right afterwards.
Most of the time in mercurial, you clone the repository to make a branch.
You can then merge the separate repositories once you made your edits and commits.
This might sound like it would take up a lot of disk space but on most operating systems, mercurial will make hardlinks instead of copying the files. Anyway, disk space is normally cheap, and because it's local it's rather fast.
If you think about it, every "checkout" (in svn terminology) or "clone" (in mercurial terminology) is really a branch that will probably be merged back so it makes lots of sense that clones are the common way of making branches.
Before commiting, click on Branch button (see image), Then select a branch or create a new one (by typing where you select the branches).
See the image here