Setting up the Mercurial Repositories for Sumatra

Deneau, Tom tom.deneau at amd.com
Tue Dec 11 14:42:15 PST 2012


John --

The answers to #1 thru #4 are yes.
We haven't often had need to merge Branch A with Branch B, but I would think that would work.

-- Tom


-----Original Message-----
From: John Rose [mailto:john.r.rose at oracle.com] 
Sent: Tuesday, December 11, 2012 3:56 PM
To: Deneau, Tom
Cc: John Coomes; sumatra-dev at openjdk.java.net
Subject: Re: Setting up the Mercurial Repositories for Sumatra

On Dec 11, 2012, at 8:14 AM, Deneau, Tom wrote:

> Named Branch Experience...
> 
> At AMD, we have used name branches successfully in our own Hotspot repository clones but we haven't had to face some of the more complicated scenarios outlined below.  We generally
>   * start work on a named branch
>   * merge the branch with default whenever we deem necessary
>   * generate the webrev vs. default
>   * keep the named branch open for changes based on webrev reviews until the webrev is actually accepted, we never actually merge the branch into default in our repo, that happens in the hotspot main repo.
>   * close the branch either
>      * after it's been merged in the hotspot main repo
>      * or after the experiment is deemed one that will not go forward.
> 
> Mostly the branches stand alone and we haven't had the case where changes have to be merged from multiple named branches.

That's encouraging.  A couple of questions (clarifications, really, since I think the answers are all 'yes'):

1. Is this the case:  Your branches can be pushed to your group repo and shared easily among people working on the branch?
2. Is this also the case:  People working independently on other branches can share the same group repo, without cross-branch interference?
3. When merging up to a new default, the nice merge tools kick in, right?
4. Independent branches can merge up independently, right?

About patches vs. branches:

If branch A needs to be merged into another branch B, we could convert branch A to an explicit artifact A.patch at that point, and then import A.patch, either using MQ or permanently into B.  The artifact B.patch would provide a clear and separable export point.

Put another way, I don't think branches exclude patches, and vice versa.  I'm thinking that we can set up the machinery to allow both workflows, and then gravitate towards whatever works.

About patches:

I like patches, because I feel more control over single text files, backed by single threads of history.  But the control requires special patch-oriented tools, notably Emacs diff-mode, so it's not for everybody.  And dealing with *.rej files is a pain, though Emacs helps a lot, and I'm used to it.

Unsolved question:  Is there an MQ-centric way of getting the nice HG merge tools to assist with merge-ups to default?  (In the case of patches, as noted earlier, such merge-ups are really rebasing, but without the strange effects on repository history.)  If there is, then the *.rej files can disappear from the discussion.

Proposal:  Let's enable the branches, and agree to admit patches also, keeping an eye on workability, with the reasonable hope of converging on best practices as we go.

- John



More information about the sumatra-dev mailing list