# 
# 
# patch "ChangeLog"
#  from [f5e9516c58454df164d3410d96e619d8aa23c179]
#    to [ca91f12d7b8e996444ad8a930c93e4d6f1cb79db]
# 
# patch "UPGRADE"
#  from [75ddb043ff15812b04ade82d294b4239bd5aeae5]
#    to [8402e407835dc317b49e4a715f59c73b50e2b67a]
# 
============================================================
--- ChangeLog	f5e9516c58454df164d3410d96e619d8aa23c179
+++ ChangeLog	ca91f12d7b8e996444ad8a930c93e4d6f1cb79db
@@ -1,3 +1,8 @@
+2006-04-11  Nathaniel Smith  <address@hidden>
+
+	* UPGRADE: Add a note that all certs will be re-issued, and all
+	revids will change.
+
 2006-04-09  Nathaniel Smith  <address@hidden>
 
 	* restrictions.{cc,hh}: Audit use of node id sources, and make a
============================================================
--- UPGRADE	75ddb043ff15812b04ade82d294b4239bd5aeae5
+++ UPGRADE	8402e407835dc317b49e4a715f59c73b50e2b67a
@@ -54,6 +54,13 @@
     entry in the history graph, the tree layout and file contents are
     preserved exactly.
 
+    The largest changes are that after upgrading, all revision ids
+    will change, and, as a consequence, all certs must be reissued.
+    This means that after upgrading, all certs will be signed by the
+    person who performed the upgrade, rather than their original
+    issuer.  This is a basic property of how signatures work, so
+    there's little we can do about it.
+
     If you have any private branches, and are not your project's
     "designated migrator", then it is still possible to preserve your
     branches.  However, this requires some more understanding of what