HotSpot workflow

[serguei.spitsyn at oracle.com]

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.
>>
>