fix(migrate-wiki): 正推比對涵蓋兩代頁名規則 #49
No Assignees
Notifications
Due Date
No due date set.
Blocks
#48 release: wiki 目錄頁專用存取庫、HASH 完整 40 碼、閘門依 CLI 分流
plugins/gitea
Reference: plugins/gitea#49
Reference in New Issue
Block a user
migrate-wiki.sh的正推比對只算了一代頁名規則，會把另一代的頁誤判成孤兒留在原地。問題
頁名規則改過兩次，兩代的頁至今並存：
0-9ABC就改成H加前 7 碼。腳本只算第二代，所以第一代那些首碼落在
0-9ABC的頁一律配不到候選鍵，被列成孤兒。實測：同一個鍵在第一代算出
1C516D85、第二代算出H1C516D8，兩張頁都存在。只算第二代就只搬得動後面那一張。修法
old_hash()改成一個候選鍵印兩行，兩種都進對照表，任一種配得上就算配對成功。首碼落在D、E、F的鍵兩代同值，只印一行，不會重複配對。實測結果
拿實際的 wiki 內容重跑對照表：
（其中 9 頁是靠補上候選鍵解決的，另外 4 頁就是這次修的兩代規則問題。）
剩下的兩頁維持孤兒，照腳本原則只列不猜：一頁是更早的
{型別}_{日期}_{HASH}命名、頁名不符任何已知樣式；一頁反推不到候選鍵。硬猜一個鍵搬過去，猜錯就是把頁搬到沒有人會去找的名字底下，比留在原地更糟。腳本另外正確報出：那頁舊命名的分析頁連到一個會被搬走的盤點頁，屬於「引用被搬頁、自己卻沒被搬」，要人工改連結。
What：候選鍵的舊 HASH 改成兩種都算——第一代只取 SHA-1 前 8 碼大寫，第二代在其上 把首碼落在 0-9ABC 的改寫成 H 加前 7 碼。兩種都進對照表，任一種配得上就算配對成功。 Why：原本只算第二代，所以第一代那些首碼落在 0-9ABC 的頁一律配不到，被誤判成孤兒 留在原地。實測同一個鍵在第一代是 1C516D85、第二代是 H1C516D8，兩張頁至今並存， 只算第二代就會漏掉第一代那一張。 How：實地重跑對照表，可搬頁數從 35 增為 48，孤兒從 14 減為 2。剩下兩頁一頁是更早的 {型別}_{日期}_{HASH} 命名、頁名不符任何已知樣式，一頁反推不到候選鍵，兩頁都照原則 只列不猜。首碼落在 D、E、F 的鍵兩代同值，只印一行，不會重複。 Who：jsc-gitea