1.svn 隱藏資料夾儲存著svn當前同步資料夾的一些元資訊，不要修改，也不要刪除 。 不過有時候被鎖定的時候，可以刪除這個資料夾中的lock檔案以解鎖，但是這樣做有可能會造成同步錯誤。
2.新增檔案的時候，需要在要新增的檔案上點右鍵然後add…，然後要想與伺服器同步，還需要commit提交。
3.提交失敗的時候，可以試著先更新一下，或者清理一下，然後再提交。
4.平時開發過各中，可以乙個人（小組）建立乙個開發分支，這樣每個人的檔案同步不會跟其它人產生衝突。必要的時候可以進行分支合併。
5.如果刪除了.svn資料夾，造成乙個子資料夾不能同步 ，可以再把這個資料夾checkout一下，這樣便可以重新恢復同步資訊，自動建立.svn資料夾.
6.update是與伺服器最新版本保持同步，如果本地版本比伺服器版本舊，則更新本地檔案為伺服器版本，如果本地版本比伺服器版本更新，則不進行操作。
7.commit是提交本地的修改檔案，本地檔案修改後，或者通過add新增了新檔案，或者通過delete刪除了檔案，或者移動、複製了檔案，都需要通過commit提交來提交到伺服器上。
8.revert如果要恢復到伺服器上的最新版本（某個版本），使用revert
9.update to version 是與伺服器上的某個檔案比較，如果伺服器上的檔案更新，則同步，否則不做操作。
10.get lock…和release lock，是用來鎖定某些檔案以阻止其它人改變的
12.relocate 與switch，前者是在改變url/ip的時候使用，後者意思是改變目錄，比如切換到某個branch
13.resolve是用來解決衝突的。
14.如果已經有人lock了乙個檔案，但另外乙個人需要編輯此檔案，有兩個選擇，乙個是由管理員來解除鎖定，另外乙個是在get lock選項中有個steal the locks，選擇後，即可以編輯該檔案
15.svn的版本概念是針對目錄而非檔案，即使只更新了乙個檔案，那麼，整體的版本也需要加1
16.推薦使用目錄樹為
/repos/trunk 用來儲存主線，所有的code都存放在這個目錄中
/repos/branches 用來儲存目錄分支，oem、新功能、設計方案調整，都有可能需要建立分支目錄
/repos/tags 用來儲存標籤拷貝，文件寶的階段性成果可以打個標籤存放到此目錄下
17.svn的上傳和更新是非同步的，可以分開操作，而不用擔心在update的同時把自己不成熟的**commit從而影響別人的工作。
svn常用操作
a、保持客戶端和伺服器端的一致，從伺服器上更新檔案，update
b、對客戶端檔案的增、刪、改、剪下，add,delete,copy,move
c、狀態比較 status，diff
d、取消對伺服器上檔案的修改，revert
e、合併別人的修改(後更新的人需要做這個操作)update,resolved
f、客戶端修改的檔案更新到伺服器上，commit
18.查詢版本，不單單可以通過版本號查詢，也可以通過關鍵字和版本的日期來查詢 注意:如果給定時間的話，查詢時需要在希望的日期上加一，如要查詢2008-09-02的版本，應該使用2008-09-03，因為你只給了日期而沒有給指定的時間點。
19.鎖定-修改-解鎖方案，拷貝-修改-合併方案使用的一般原則
如果是影象檔案，一般使用鎖定-修改-解鎖方案，因為兩個不同的版本沒法合併
如果是文字檔案，一般使用拷貝-修改-合併方案
20.鎖定檔案可以所單個，也可以鎖多個，可以選擇乙個資料夾，然後在列表中勾選。並且，這個鎖定是隨時都可以解除的，選擇unlock即可。
注意: 如果一旦提交了更新，那麼所有的檔案都將解鎖，即使有部分檔案可能還沒有更新。 但是如果你在commit的時候，選擇keep locks，則檔案還是被鎖定。
21.對客戶端的目錄或檔案可以設定屬性，可以從下拉列表中選擇
如svn:needs-lock，就是對指定的物件設定唯讀許可權，只有當該物件擁有鎖定的許可權後，才能對檔案進行編輯，這樣可以確定只有乙個使用者在操作該檔案，避免像影象這樣的檔案只能線形操作而導致另外乙個人工作的浪費。
22.即使客戶端的檔案test.doc被重新命名了hello.rtf(使用svn重新命名)，但它的歷史紀錄仍然含有重新命名以前的資訊，並且可以將之前的版本給提取出來。即使再新建乙個test.doc也不會有混淆。(檢視歷史紀錄的時候需要把stop on copy/rename這個選項的核取方塊的勾去掉)
23.svn的複製比較特殊，如果複製乙個目錄，它其實並沒有完全複製目錄中的所有的檔案，它只是建立乙個目錄樹的入口，你可以把它理解為乙個快捷方式，即使當你的新目錄中的檔案有了更改，它也只是更新你修改的檔案，其他檔案還是原資料夾的對映，沒有更改。
24.對主幹和分支上檔案的修改互不影響。當完成了分支上所有工作，所有的分支修改可以被拷貝回到主幹。
25.對同名檔案的合併可以先用svn diff檢視檔案的區別，然後通過svn merge功能來合併檔案。
26.如果需要解決版本的衝突，會在本地目錄下產生同名的三個檔案，初始的版本（在比較的左邊）、最終的版本（在比較的右邊）、接收區別的工作拷貝（合併的目標）。通過比較來手動合併版本，如果通過比較不需要將本地的修改合併到伺服器上去，則使用revert回滾。
27.手工跟蹤合併:svn並不能完全自動合併衝突，比較合適的方法是在版本提交的日誌資訊中說明合併的特定版本號（或是版本號的範圍），這樣等到合併時可以執行svn log來檢視分支包含了哪些修改。這樣可以幫助依序進行合併而不會進行多餘的合併。
28.預覽合併:當工作拷貝已經改變，合併會針對存在的那乙個檔案，這時執行revert不會恢復在本地的修改，兩部分的修改無法識別出來。解決這個問題的簡單的方法就是使用diff來預覽變化部分，通過顯示合併時的狀態資訊，得到合併之後的「整體」預覽。
29.svn diff和svn merge的區別:
30.將test.doc版本100重新命名為ceshi.doc，同時新建乙個檔案test.doc為版本102。
這樣區別就出來了:
svn diff命令忽略祖先，diff命令只是單純地比較兩條路經下的兩個檔案。
svn merge是比較兩個物件，會注意到版本100和版本102的test.doc兩個檔案是不關聯的。
31.svn並沒有真正意義上的重新命名，move命令只是copy、delete兩個命令的組合。
32.找回刪除的專案:即使刪除了檔案或目錄，svn的資訊從不丟失，只是從當前的head版本消失了，但仍然存在於歷史的早期版本。只要通過svn的log來檢視所有改變的每個專案的版本，找出你刪除檔案或目錄的那個版本。
33.將所有的開發**存放在trunk上。
常用分支模式:
a、發布分支:在**發展到一定階段，建立發布分支，將當前的乙個版本取出來，拷貝到branches目錄下，進行全面嚴酷的測試，如發現bug則在當前版本進行修復，並同步更新trunk中的bug，經測試完成後，將檔案拷貝到tags目錄中發布，並提交給客戶。
b、特性分支:如果需要作複雜的修改，會影響到trunk**的穩定性，則建議建立乙個特性分支，等特性穩定之後，再和truck主幹合併
34.標籤tag:它是某個專案，某個時間的乙個快照，這個術語很常見，每次提交乙個修訂版本其實都是乙個精確的快照。
35.svn的資料儲存格式有berkeley db和fsfs。我們現在所使用的版本預設為fsfs格式的資料儲存。
36.svn自帶工具
（要使用這些工具可以在命令列模式下輸入svnadmin help、svnlook help等指令即可）
svnadmin:提供建立svn版本庫的功能，還可以用來維護這些版本庫。
svnlook:用來檢視版本庫中不同的修訂版本和事物（它不會改變版本的內容）。
svndumpfilter:可以簡單快速的作為svn版本庫歷史的以路經為基礎的過濾器。
svnsync:將乙個版本庫的歷史轉移到另外乙個上。特點是可以遠端操作（「源」、「目標」版本庫以及svnsysnc程式可以在不同的計算機上使用。）
37.svn節約磁碟空間的主要方法:
1、採用增量化技術，對兩組資料，只記錄其中的一組，另外一組只是存放與第一組有差別的部分。
2、由於客戶端和伺服器網路異常，或客戶端svn程序異常中止，都可能導致檔案提交的事務失敗，可以刪除意外中止的事務。可以使用$svnadmin lstxns myrepos來清除。
38.刪除不使用的berkeley db日誌檔案
svnadmin list –unused –dblogs /path/to/repos
rm 『svnadmin list –unused-dblogs /path/to/repos』
svn的使用注意
既然你是剛接觸這個svn,我有幾點建議給我參考。1，不要盲目commit，不要選中整個工程，然後commit，因為有些本地檔案提交後，如.classpath檔案等，別人再update的話，別人的工程可能就報錯了。正確的做法，選中工程，team 與資源庫同步，英文我忘了，預設是team下的第乙個。這個...
使用指標應注意的問題
使用指標應注意的問題 1.錯誤的對乙個未初始化的指標進行解引用，2.錯誤的對乙個null 指標進行解引用。解引用乙個 null 指標的結果因編譯器而異，允許程式在這樣的訪問之後還可以繼續進行的原因可能是這個程式可能沒有正確的執行。3.向函式錯誤的傳遞空指標 4.指標減去乙個整數，結果產生的指標所指向...
SVN 使用注意事項
2010 3 8 17 10 23 1.檔案應該按組提交。即乙個功能或一次修改用到的檔案一次提交而不是分開提交。2.確保每一次提交的版本都是可用的，而不是編譯都通不過的。如果多個人的提交相互依賴，應該乙個人為主，其他人提交patch給他，合併後一次提交。3.做好目錄劃分，功能確實相互依賴且集中，否則...