問題:
最近公司一個項目組的源代碼解決方案打開時總是出現解決方案或者部分項目被自動簽出的情況,但簽入又提示沒有變更。事情雖 小,導致幾個程序員要用項目文件時總是要找其他人簽入。浪費不少時間。出現時間有幾個月了,也一直沒有重視去解決。但最近出現源代碼部分被覆蓋等一些異常 情況后,問題就變得很嚴重了,於是決心解決。
分析:
按照解決問題的習慣(這個習慣有時候真的不好),第一反應就是去網上搜索“TFS自動簽出解決方案”,“TFS自動簽出 sln”,“TFS Auto Check out sln”等關鍵詞,找到兩個比較有價值的文章,但還是沒有解決問題,一時陷入了困境,解決方案的自動簽入前后的文件都是一致的。無奈,干脆放下,出去辦公 室透透氣,發現查找問題過程中的一個大漏洞,總是一直在分析解決方案,沒有去分析也會自動簽出的項目文件,回來分析一看,果然找到問題,問題如下圖:項目引用的項目文件前后兩個版本中Tools項目的相對路徑不一致,一個三級,一個兩級
根據TFS歷史記錄找到相應同事的電腦,發現果然是這樣,其中一個項目的相對路徑關系跟其他人不一樣,對比如下
其他人這兩個項目都是放在同一個文件夾下,但他的不一樣,就導致相對路徑不一致。
附錄:搜到的兩個網上文章
Automatic Checkout on Build Solution
When I open a solution VS2010 tries to check out SLN file – why?
解決:
將他的本地源代碼相對路徑(是相對路徑,不是絕對路徑)修改后跟大家一樣的解決了。
本地映射路徑修改辦法如下,記錄備忘下(這個修改每次都要想一下,才記得在哪里改的
):
PS:但改了后又碰到一個問題,項目路徑還是在加載舊的項目文件路徑,解決辦法是強制更新解決方案文件,不知道是因為緩存還是其他什么原因導致非要這樣操作
如何避免:
源代碼的對應程序員各自的物理路徑不要求,但各個解決方案,項目文件所在的相對路徑必須要一致,否則就可能出現這樣的問題。
后記,感悟:
1、查找問題原因時不能一味盲從網上的解決辦法,因為情況很多,別人不一定碰到。還是需要冷靜自己的分析問題,尤其是在嘗試網上解決辦法無效的情況下
2、又驗證了一直以來的一個經驗,很奇怪的問題或者感覺無從下手的問題,很多時候原因都很簡單,甚至很低級的。