早上好,合併多個文件夾中的代碼
我正在使用遺留代碼。這個遺留代碼由多個項目組成(使用NI LabWindows CVI的C語言),並且從未在源代碼管理系統中管理,但僅在文件夾中管理。隨着時間的推移,它變得有點混亂,創建了這個文件夾的副本,並根據所建立的項目對所有文件夾進行了更改。 結果是,有5個文件夾,每個文件夾包含不同的代碼,這些文件夾曾經是相同的代碼。還有許多文件在所有文件夾中被修改,因爲它們被用於多個項目中。每個項目只能從5個文件夾中的1個構建(所以項目A只構建在文件夾1中,項目b在文件夾4中等)。它不僅是原始代碼,還有用戶界面文件。
我希望迄今爲止清楚。
我的任務是將所有的代碼合併爲一個代碼庫(最初開始時)。我想獲得一些建議。
這裏是計劃: 1.創建一個文件夾的基線版本,據推測這是一個變化最大的文件夾。 2.創建GIT存儲庫以存儲代碼和所有更改 3.遍歷所有文件夾並使用文件差異軟件將文件合併到基準版本。 (文件夾1是基線,將文件夾2合併到基線,將文件夾3合併到基線等)
您對此計劃有任何意見嗎?什麼是好的?壞?我可以使用哪些工具?
對任何以前的文件夾中的內容的準確性不作任何假設。僅僅因爲一個.c文件比另一個文件夾中相應的.c文件有更多的變化並不意味着它比另一個更好。從用戶需求列表開始,或者如果可用,則列出軟件寫入的原始規格。然後從一個乾淨的石板開始,尤其是使用UIR文件。 (轉儲舊版本並創建自己的版本)CVI在版本之間的UIR兼容性方面聲名狼借,如果你發現舊的.c/.h文件寫得很好,請從它們中取出片段,但是要開始清理 – ryyker
你對這些假設是正確的。沒有原始的規格,因爲這個軟件是在飛行中開發的,並且隨着任何需求文檔或更改文檔而被廣泛修改。有時,當我運氣好的時候代碼被記錄或包含日期/時間戳。有時候我不那麼幸運,這些數據/時間戳完全過時了。 基本上你所說的是重新做整件事情? (或大部分)這種感覺會導致真正的麻煩,因爲多年來發展起來的所有不成文的要求都很難從代碼中提取出來。 – TriceratopsMagician
如果您必須重新執行此操作,請在開始實施新版本之前堅定地從一組衍生要求開始。在一定程度上,新的要求可以通過反向工程得出,你將在評估原始代碼和提煉它到底創造了什麼。另外,請諮詢軟件的其他利益相關者(用戶)以瞭解存在哪些功能缺陷,並將其添加到需求中。爭辯說它的功能不會影響軟件的目的,但如果它們包含在設計中的話。 – ryyker