Mercurial Tip: Checking in regularly with uncommitted changes in your clone


NetBeans, like OpenJDK and OpenSolaris, uses the Mercurial distributed version control system. I'm a big fan of of distributed version control. However, one thing that drives me nuts is this error message:


% hg merge
abort: outstanding uncommitted changes

This isn't just going to be a rant - I've finally found a solution which is working extremely well for me. I've suggested it to some other developers who have also reported that it works well for them, so I thought I would share it with you.



The reason I run into this all the time is my preferred style of work:


  • I like to work on many things simultaneously. If while working on something, I come across a bug and I spot the problem, I just fix it right there and add a test for it. When I get ideas, I might go and put @todo tasks for myself, or leave editorial comments in various source files. I might also work on a couple of larger tasks simultaneously. Yes, I know the preferred Mercurial idiom for this is to have multiple clones, one for each task - but that isn't my preferred way of doing it. Each NetBeans clone is huge and takes a while to both clone and build - and I would have to switch my IDE editing context between these large source trees all the time.

  • I like to check things in in logical chunks with a message that pertains to that particular change. This means I often check in a subset of the edited files in the tree.

  • I like to check in code regularly rather than leaving all files edited until I'm ready to check everything in.

  • I like to keep up to date. I'm using the bits I'm working on and I report problems when I see them so I want to make sure these are truly new and current bugs. Therefore, I update to the tip at least every day.



It turns out that the above requirements are tricky to fulfill with a default setup. Here's what happens.


  • I'm working on something and a high priority bug comes in. I find and fix it. I check in just the fix for this one problem. I
    still have many other edited files in my clone since I was in the middle of something else.


  • Since it's a high priority bug, I want to push it. However, when I do, I get this:


    % hg push
    pushing to https://tor:\*\*\*@hg.netbeans.org/main/
    searching for changes
    abort: push creates new remote heads!
    (did you forget to merge? use push -f to force)

    This tells me that somebody has checked in something since my last pull. That happens a lot with a project like NetBeans
    where there are checkins every few minutes.


  • No problem - I'll just pull down their changes, merge, and push again, right?

    % hg pull && hg update
    pulling from http://hg.netbeans.org/main/
    searching for changes
    adding changesets
    adding manifests
    adding file changes
    added 1 changesets with 1 changes to 1 files (+1 heads)
    (run 'hg heads' to see heads, 'hg merge' to merge)
    abort: crosses branches (use 'hg merge' or 'hg update -C')


  • Ah, I couldn't just update, I have to merge since I have checked in changesets of my own. Let's do that:

    % hg merge
    abort: outstanding uncommitted changes

    !@#@%\*#%$%&\*$ ! Now, if I have dozens of changes, what do I do? When I first started using Mercurial, I would either
    try to finish my other changes and check them in and then try the merge again, or if I really wasn't ready to do that,
    I would copy the contents of my modified files to another location, hg revert the changes, and try again.


  • It's not unreasonable of Mercurial to insist that you cannot merge with uncommitted changes. When it's merging, it will think
    file modifications in the clone are your manual edits to resolve any merge conflicts. However, it does make using
    my workflow difficult.


    The Solution



    It's really very simple: Use two clones. Do all your work in clone "main", and all your merging and pushing from clone "sync".
    Let's say the main repository is "master", and your two clones are "main" and "sync":





    To get set up, either clone the master repository twice, or, you can clone your main locally, but be sure to update
    the "parent" reference in your sync clone such that it points to the master instead of your working clone
    (I do that by copying main/.hg/hgrc to sync/.hg/hgrc.)



    Here's the new workflow:


    1. As before, work in main. Edit files at will, and check in logical changesets as needed.



    2. When you want to push a changeset, go to your sync clone, and pull your new changesets from your working clone:

      % cd ../sync
      % hg pull ../main && hg update

      At this point, it's best to try a build/test as well, to make sure changeset is complete. If you're working
      on many things in parallel, it's possible that your changeset is depending on a change in a file you haven't
      checked in yet.



    3. Now pull in the new changes from the master, and merge these:

      % hg fetch

      (Or if don't have the fetch extension installed, do it manually - hg pull && hg merge && hg ci -m "Merge").



    4. If something went wrong with the merge - no problem. You can just go and nuke the entire sync clone
      and try again! Your modified files, and your new changesets, are still sitting completely unaffected in the main
      clone. Just clone sync again and try more carefully :)



    5. Now you can push your merged changesets to the master repository:

      % hg push

    6. ...and now you can pull these changes back into your main repository:

      % hg pull ../sync && hg update

      This will give you all the tip changes into your working clone, but without the risk of causing multiple heads that you
      have to merge. You've already merged your local changesets over in the sync clone, and therefore there is no
      conflict between your local changesets and the new changesets in the tip!



    This process may seem tricky, but it's trivial once you try it:


    Work in main, push and merge in sync, and pull back into main.

    Finally, I want to call attention to item #4. Doing it this way means that it's trivial to try again if something wrong happens
    during the merge. I've had a couple of merges where I've really mucked things up. Unfortunately, this was in my tree that contained
    the changesets that I cared about. In the end I had to go and manually copy out the files I wanted to check in and try again. With
    the above approach, if something goes wrong, just nuke the sync clone and try again.



    This is the reason I'm suggesting this approach to anyone using Mercurial, not just people who want to work with edited files.
    Especially when you're new to distributed version control systems or Mercurial, it's great to be able to go back if you make
    a mistake. Just make sure you know what you're doing before you submit that final hg push command to push everything
    back to the master repository!

Comments:

Yes, this works, although I use hg fetch instead of hg pull/hg merge.

But I use Mercurial Queues rather than a "push clone". When I get the "outstanding uncommitted changes" error, I do the following:

hg qinit -f mypatchname.diff
hq qpop
hg fetch
hg push
hg qpush

Very nice.

Note that when you want to commit your local changes that were put on the patch queue, you have to do the following, a minor annoyance...

hg qpop
hg import .hg/patches/mypatch.diff

Posted by David Van Couvering on October 31, 2008 at 06:20 AM PDT #

Hi David,
thanks. I'm aware of Mercurial Queues, but the main reason I really recommend having an alternate clone to people new to Mercurial is the ability to throw it all away when something goes wrong during a merge. I also like the ability to be able to build/test individual changesets in isolation before pushing them.

Posted by Torbjorn Norbye on October 31, 2008 at 07:05 AM PDT #

Your description and level of detail for how to use Mercurial is exactly what I've been looking for. I'm new to Mercurial and am suggesting it for company wide use where I work. Thanks Tor.

Posted by Greg Strockbine on November 03, 2008 at 12:22 AM PST #

I agree with David and I prefer using MQ for working on several things at once in one repo (code for each bug/enhancement is stored in a separate patch). It's much faster, but also requires some discipline and awareness of which patch is currently on the top of the stack.

Once a patch is ready to be permanently moved to the main repo, hg import + hg push will do the job.

There are times when working on a separate clone makes more sense, mainly when working on major changes for a longer period of time.

Posted by Igor Minar on November 10, 2008 at 06:08 AM PST #

Hi Tor,

------------------
hg merge
abort: outstanding uncommitted changes
------------------

I had similar issues (when I had to tweak GSF modules in the clone of /main-golden to add friend dependencies on my module). I fixed it like this- I edit the .hg/hgrc file and changed the "default-push" value back to the one pointing to /main-golden.

Will this work all the time?

Then, as I had configured Hudson yesterday to automate builds for /main-golden locally. I ran the build myself and it worked. Also, build succeeded after nearly 100 minutes!

Posted by Varun on November 10, 2008 at 07:26 PM PST #

"However, one thing that drives me nuts is this error message:" ...

It's not "me" is everybody nuts...

Posted by Charles on April 05, 2010 at 04:32 AM PDT #

Thanks a lot for that tip. I have a similar workflow and it was driving me crazy that we can't do partial commits after a merge. Even if it's a bit annoying that it requires to clone the whole repo, this method prevents a lot of anger management. :)

Posted by mpl on April 11, 2010 at 11:24 PM PDT #

Post a Comment:
Comments are closed for this entry.
About

Tor Norbye

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today