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.
