在沒有使用版本控制的開發團體中，我所熟悉的一種常用開發方式是：多個開發人員共同負責一個軟件的開發，每個人在各自的機器上有整個軟件的拷貝，并對之實施編碼，分別完成各自任務之后，再通過文本比對工具將各自機器上的不同版本的軟件整合到一臺機器上。
本文就這樣的開發方式，提出在軟件開發中出現的幾個和版本控制密切相關的典型問題（但未必全面），同樣也是需要通過版本控制來解決的問題，它們來源于實際開發過程中的切身體會，并經過總結和整理。
1、軟件代碼的一致性
軟件的開發、維護和升級，往往是多個人共同協作的過程。不同人對同一個軟件的不同部分同時做著修改，這種行為有時會出現彼此交叉的情況。由于同一軟件在各自開發人員的機器上都有拷貝，軟件的全部代碼都暴露在每個開發人員面前，原則上他有權限可以不加限制地更改軟件的任何部分。而當他們修改的內容屬于公共部分，或者需要被其他人員所負責的部分調用時（軟件各模塊間的彼此依賴關系決定了這種情況是經常發生的），這種修改就屬于交叉情況。此時，就有可能出現代碼的不一致現象。比如：修改者在改動了某個公共函數的同時也修改了其調用接口，若其他人員沒有得知此事，而在各自機器上仍調用原來版本的函數，則當整合時，就會出現錯誤。另一種更為嚴重的情況是，修改者決定廢棄原有函數而另外編寫一個新的函數，但他并未刪除原有函數，這種情況即使最后的整合也可能不會被察覺，如果將這種一致性錯誤的糾正延遲到測試階段，則會增加調試的難度，從而降低開發效率。為了始終保證代碼的一致性，一種解決辦法是，要求修改者每次修改后都通過某種方式告知同組其他人員，或者隨時對軟件做整合。但是這樣，一方面會增加開發人員的負擔，另一方面也降低了軟件的開發效率。
2、軟件內容的冗余問題
軟件在各自開發人員的機器上都有拷貝，并且同一個開發人員在不同時期也會在本機保留當時的軟件版本，也就是說，一臺機器上還可能不止一個版本。這類似于一種信息的冗余。對于不同版本而言，其差別有時可能并不很大，如果說不必要的占用存儲空間是一個次要問題的話，那么另一個問題可能更重要。隨著時間的推移，開發人員可能對自己機器上的不同版本間具體差異的了解變得模糊不情，甚至忘記了當時為什么區分這些版本的原因，這會給整合帶來麻煩。而且，如果需要同時維護多個版本，則對某個版本的改動可能需要反映到其余版本的對應處，很難保證這一過程不會出差錯。還有一點，作為開發人員，有時即使知道自己機器上軟件的某個版本可能不會再使用了，他也不會去刪除（生怕萬一需要從那里獲取點什么），但是通常也不會再去維護或查看它，因此久而久之，這種“僵死之物”會在多臺機器上“蔓延”。
3、軟件過程的“事務性”
對于軟件的某個版本，如果開發人員想要為其增添新的功能，或改善原有功能，而又擔心會攪亂原來運行良好的軟件。一種常用的辦法，就是保留現有版本，另復制一個新的拷貝，并在新的副本上進行修改。這類似于一種事務處理，當將一系列操作做為一個事務時，如果中間某個操作出現偏差，則希望恢復到執行事務之前的狀況。而當完成修改之后，開發人員該如何處理這兩個副本呢？是在新的副本上繼續新的開發，將之作為最新版本；還是將新的改動加入原有版本，刪除新的副本。無論怎樣，都可能會出現如下情況：如果軟件運行正常，則出現2中提到的冗余情況；當刪除修改前的版本后，又發現改動中有問題，但已無法恢復了；改動無誤，將改動加入原有版本時，可能出現人為錯誤，導致軟件運行出錯；即使沒有人為錯誤，這種做法也會給開發人員增加額外負擔，一定程度的降低開發效率。重復上述過程則會出現多個類似的副本，此時，如何對待這些不同版本，將是開發人員需要面對的問題。而如果調試的過程中，發現確實有必要恢復到上一個版本，甚至上上個版本……，此時就不得不保留所有版本了。
4、軟件開發的“并發性”
由于是多人共同開發一個軟件，期間出現多人修改軟件的同一部分，尤其是同時修改，有時是不可避免的。對于前者，具有良好編程習慣的人員的一種通常做法是，對他人的源程序進行修改時添加必要的注釋，寫明修改人，修改原因，修改日期等。但實際情況是，當修改內容很零散或修改過程很復雜時，注釋很難寫，或者代碼被注釋分割得支離破碎影響正常閱讀，或者注釋無法詳細說明實際情況。而且，這種做法也增加了開發人員的負擔：他需要在考慮代碼邏輯的同時，兼顧如何寫注釋；而對于注釋和代碼的一致性也是他需要隨時留意的問題，不能疏忽。因此，我認為這種措施在實際開發中，并未取得實質效果，是不必要的，事實上代碼本身（而非注釋）是最能說明問題的，而修改的記錄應該置于代碼之外的某處。而且，不論是否是同時修改，都需要考慮1所提到的一致性問題，需要及時進行人工的差異比較和整合以便形成一個統一的新版本。
5、軟件代碼的安全性
由于代碼完全暴露于所有開發人員面前，任何人都可以增、刪、改之。除了會造成1所提到的不一致問題外，從安全的角度來看，也是存在隱患的，這一點對于一個自主產權的長期開發的產品而言更是如此。即使是一般的項目開發，不同的人員其分工不同，允許別人可以不加限制地任意修改自己負責模塊的代碼（相當于所有人員都具有管理員身份），總是容易產生問題。對于共有模塊更是如此，所有人都可以修改，一旦修改，則波及全體。
6、軟件的整合
在軟件的整合過程中，一般比較可靠的做法是使用文本比對工具輔助完成的。這種措施，有以下缺點：
● 可靠性，整合中的人為錯誤會影響軟件的可靠性，有時這種錯誤很難察覺，可能編譯沒有問題，而在測試時卻發現了問題。這種潛在的錯誤發現的時間越晚就越難以糾正。
● 效率，對于純手工的整合即使熟練操作的人也是需要時間來完成的，而有些整合只是將兩段代碼拼接在一起，這一過程完全可以借助于某些自動機制。這可以大大節省時間，使開發人員可以專注于后續的開發任務。