HotSpot workflow

[ioi.lam at oracle.com]

I usually keep each change in its own repo, and use mq to keep track of my changes. When I need to sync down, I would use the rebase extension to make sure my changes are always sitting at the tip of the tree, without any merge change sets.

The problem with merge change sets is I can never understand what's in them. I.e. What's changed by me and what's changes by others. They are good for the computer to produce the right output. They are horrible for a human to understand what's changed.

> On Apr 14, 2015, at 6:06 PM, "serguei.spitsyn at oracle.com" <serguei.spitsyn at oracle.com> wrote:
> 
> Just to share in hope, someone will find it useful. :)
> I normally do not use the mq extension and hg merge.
> 
> My approach is similar to what Dmitry does:
> - keep one repository for one bug fix
> - do not commit until the fix is ready for a jprt push
> - save the current patch with:
>    %  hg diff > ../1.patch
> - to pull the updates:
>    % hg revert -a
>    <pull the update from the parent (better to do it from the top repo)>
>    % hg import ../1.patch
> - commit before the jprt push
> - if a conflicting fix discovered in the parent repo just before my jprt push:
>    % hg rollback
>    % hg diff > ../1.patch
>    % hg revert -a
>    % hg pull
>    % hg import ../1.patch
>    % hg commit
>    % <jprt push>
> 
> 
> The above is a little bit manual but simple and always works like a charm.
> 
> Thanks,
> Serguei
> 
> 
>> On 4/14/15 9:34 AM, Dmitry Samersoff wrote:
>> Andrew,
>> 
>> I'm the rare person in JDK who doesn't adopt mq ;)
>> 
>> Below is my workflow:
>> 
>> Typically I have about five-six-ten CRs "in progress" in my pile.
>> 
>> It's critical for me to have stable basement for the changes, so I
>> create a separate folder for each problem, clone workspaces there and
>> don't update it until the fix become complete.
>> Right before push I merge my changes into the recent codebase and repeat
>> all tests.
>> 
>> I use hg TAG to mark a start of my work, than keep committing changes as
>> necessary (hg ci, hg rollback etc) and at final stage just get a diff
>> between the first and the last changeset using plain hg diff and apply
>> this patch to fresh workspace.
>> 
>> -Dmitry
>> 
>> 
>> 
>>> On 2015-04-14 15:26, Andrew Haley wrote:
>>> I'm having some practical problems with the HotSpot workflow.
>>> 
>>> I usually have several patches on the fly at any time, but webrev and
>>> Mercurial don't really help.  "hg push" and "hg merge" work on the
>>> whole repo, not just a changeset, so I've been manually saving
>>> changesets and re-merging them into the master tree, which is very
>>> error-prone and has led to some mistakes submitting changes.
>>> 
>>> Also, the need to submit a change as a single changeset makes it
>>> awkward to commit regularly as I work on a patch; I can't find any way
>>> to merge a set of changes into a single changeset and push that.
>>> 
>>> So, what do you do?  Do you keep a source tree checked out for every
>>> webrev?  Do you regularly commit as you work?  Am I missing
>>> some tricks?
>>> 
>>> Thanks,
>>> Andrew.
>