IMPORTANT: Cleaning Up after the Hotspot repository rollbacks

[Daniel D. Daugherty]

Greetings,

This e-mail applies to folks that have a child repository of
the jdk7/hotspot-svc/hotspot repo. I've destroyed my old merge
repo and I'm about to recreate it from the rolled back bits
(case #1 below).

Please check to see which of the four situations below apply
to your Serviceability child repo...

Dan


Erik Trimble wrote:
> This message is for those people who have a local clone of any of the 
> following repositories:
>
> http://hg.openjdk.java.net/jdk7/hotspot/hotspot
> http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot
> http://hg.openjdk.java.net/jdk7/hotspot-svc/hotspot
>
> AND who have pulled down an incorrect changeset that was removed 
> during tonight's rollback.
>
> To check if you have the offending changeset, in each local 
> repository, run this command:
>
> % hg log | grep 2bb5ef5c8a2d
>
> Any output from this command indicates that your repository has been 
> contaminated.
>
>
> ###  HOW DO I FIX THIS? ####
>
> There are four cases; please following the appropriate section:
>
> CASE #1:   You have no committed or uncommitted new work in the 
> repository that you haven't already pushed to the hg.openjdk.java.net 
> repository
>
> SOLUTION:  Re-pull the repository from http://hg.openjdk.java.net
>        This is the fastest, easiest solution - if you have no new 
> work, simply get a clean copy.
>
>
> CASE #2:   You have committed one or more changesets of your own work 
> into the contaminated local repository
>
> SOLUTION:  Clone a new copy of the repository from 
> http://hg.openjdk.java.net, then apply your changesets to that new copy.
>          Step 1:  clone a fresh copy to <new_repo>
>          Step 2:  change directory to your old, contaminated 
> repo:      % cd <old_repo>
>          Step 3:  use 'hg outgoing' to discover which changeset IDs 
> you have created since the last push to the repository
>          Step 4:  For each changeset of your work, do the following:
>                            % hg export -g -o /tmp/changesetID changesetID
>          Step 5:  change directory to <new_repo>
>          Step 6:  For each of your changesets, do the following:
>                            % hg import -p 1 /tmp/changesetID
>
>       You are now up-to-date and ready to work.
>
>       In a limited number of cases, where your work was based against 
> an old branch of the repository, you may have problems with above 
> procedure. Please send an email to this list regarding your problems, 
> and someone will contact you shortly to help with the procedure.
>
>
>
> CASE #3:  You have new work in the contaminated repository, but have 
> not committed yet (i.e. you do not have a changeset of your work).
>
> SOLUTION:  Create a patch using your working files, and apply that 
> patch to a fresh clone from http://hg.openjdk.java.net
>          Step 1:  clone a fresh copy to <new_repo>
>          Step 2:  change directory to your old, contaminated 
> repo:      % cd <old_repo>
>          Step 3:  Run this command:   %  hg diff -g > /tmp/new_work.patch
>          Step 4:  change directory to the new repo:      % cd <new_repo>
>          Step 5:  Using GNU patch, apply your changes:      %  patch 
> -p 1 -i /tmp/new_work.patch
>
>
>
> CASE #4:  You have both committed changesets, and uncommitted work in 
> the contaminated local repository.
>
> SOLUTION:  Follow the procedure in Case #2 to update your changesets, 
> then follow the procedure in Case #3 to migrate your uncommitted 
> working files.
>
>
>
>
> Once again, we apologize for the inconvenience this rollback has caused.
> If you have any questions regarding this rollback, or the above 
> procedures to repair your local repositories, please send email to 
> this list (not to me), and we will try to reply promptly.
>
>
>