how to merge your project gate with Nevada … and what not to do.

I recently made my first attempt to merge our project gate with then-current bits from the Nevada gate; a change I wanted to benefit from had just been put back, and I was eager to get the bits.

Here’s what I should have done:

  • creat a clone of the project gate (ilb-merge-clone) (we were based off of build 107 at the time)
  • reparent to onnv-clone
  • hg pull -u (this got us bits from build 111)
  • hg merge
  • hg commit
  • create webrevs vs. the project gate and vs. Nevada, inspect.
  • hg reparent to our opensolaris gate
  • hg push (to the project gate on

If I’d done it this way, all would have been fine. And I did, except for one step: before the last ‘push’, I did something I shouldn’t have: I issued a ‘hg recommit’. If you’re groaning now, there’s probably no news for you in the rest of this piece ;-). If not, here’s a little detail:

Whenever a change to the source is done (eg. a minor milestone or the fix for a bug), you can do ‘hg commit’ to document this in the your repository. Such an action is also reversible with hg-means; so it makes sense to commit fairly often. Note: commit doesn’t change anything in the parent repository, rather, the change in the code is communicated to your working repository. That way, you accumulate several commits before pushing them to the parent repository (or "putting back" in teamware-speak).

When you compare your work with the repository you’re planning to push this to, hg uses this history to find out which files actually changed and compare those that did.

Normally, when you want to push an incremental set of changes to your project gate, it’s sufficient for these changes to appear as one changeset in the project history (esp if you’re planning to integrate with Nevada anyway at a later point in time, where all those changes will again be collapsed into a single change-set). ‘hg recommit’ collapses all changes into one.

What was different in my situation: by pulling bits from onnv-clone, I’d imported Nevada’s change-set history. Unless we’d been planning to integrate our project with Nevada right away (ie before (m)any more changes to Nevada), this history would have been essential for future merges.

By removing this history, I made that step very painful – I essentially declared all changes that Nevada had introduced since we’d started our project gate, and which I’d now incorporated into our gate, as "our" changes (and not as Nevada changes we just synced up with), so every future comparison with Nevada would not only show our project work as changed, but everything that had changed in Nevada since we’d created our gate.

Lesson learned: just because something makes sense in one set of circumstances, it does not necessarily do so when the circumstances change – even if the change is minimal.

I finally got Nevada history back into our repository with a lot of help from Mark J Nelson (and that was not trivial!), and if you want to buy him a beer the next time you see him, you’re more than welcome to 🙂

This entry was posted in Sun. Bookmark the permalink.

2 Responses to how to merge your project gate with Nevada … and what not to do.

  1. Jason says:

    The 2nd to last item ‘reparent to our opensolaris gate’, do you mean the project gate? I’ve been trying to figure out a good way to handle that for my own projects that involve ON, and this is the first place I’ve seen any sort of procedure documented.

  2. Michael Schuster says:

    yes, I meant "the project gate on"; sorry for the confusion.
    btw; Mark Nelson pointed me to a place where this is documented:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s