一．提交之前先更新
1.svn更新的原則是要隨時更新，隨時提交。當完成了乙個小功能，能夠通過編譯並且自己測試之後，謹慎地提交。
2.如果在修改的期間別人也更改了svn的對應檔案，那麼commit就可能會失敗。如果別人和自己更改的是同乙個檔案，那麼update時會自動進行合併，如果修改的是同一行，那麼合併時會產生衝突，這種情況就需要同之前的開發人員聯絡，兩個人一起協商解決衝突，解決衝突之後，需要兩人一起測試保證解決衝突之後，程式不會影響其他功能。
3.在更新時注意所更新檔案的列表，如果提交過程中產生了更新，則也是需要重新編譯並且完成自己的一些必要測試，再進行提交。這樣既能了解別人修改了哪些檔案，同時也能避免svn合併錯誤導致**有錯。
二．保持原子性的提交
每次提交的間歇盡可能地短，以幾個小時的開發工作為宜。例如在更改ui介面的時候，可以每完成乙個ui介面的修改或者設計，就提交一次。在開發功能模組的時候，可以每完成乙個小細節功能的測試，就提交一次，在修改bug的時候，每修改掉乙個bug並且確認修改了這個bug，也就提交一次。我們提倡多提交，也就能多為**新增上保險。
三．svn提交時注意不要提交本地自動生成的檔案
一般配置管理員都會將專案中一些自動生成的檔案或者與本地配置環境有關的檔案遮蔽提交（例如eclipse中的.classpat**件等）。如果專案中沒有進行這方面的配置來強行禁止提交這樣的檔案，請自覺不要提交這樣的檔案。提交了這樣的檔案後，別人在更新後就可能與本地的環境衝突從而影響大家的工作。
四．不要提交不能通過編譯的**
**在提交之前，首先要確認自己能夠在本地編譯。如果在**中使用了第三方類庫，要考慮到專案組成員中有些成員可能沒有安裝相應的第三方類庫。專案經理在準備專案工作區域的時候，需要考慮到這樣的情況，確保開發小組成員在簽出**之後能夠在統一的環境中進行編譯。
五．不要提交自己不明白的**
**在提交入svn之後，你的**將被專案成員所分享。如果提交了你不明白的**，你看不懂，別人也看不懂，如果在以後出現了問題將會成為專案質量的隱患。因此在引入任何第三方**之前，確保你對這個**有乙個很清晰的了解。
六．svn提交時提前協調好專案組成員的工作計畫
專案經理應該合理分配工作計畫。每個成員在準備開始進行某項功能的修改之前，如果有可能，先跟工作小組的成員談談自己的修改計畫，讓大家都能了解你的思想，了解你即將對軟體作出的修改，這樣能盡可能的減少在開發過程中可能出現的衝突，提高開發效率。同時你也能夠在和成員的交流中發現自己之前設計的不足，完善你的設計。
七．對svn提交的資訊採用明晰的標註
在乙個專案組中使用svn，如果提交空的標註或者不確切的標註將會讓專案組中其他的成員感到很無奈，專案經理無法很清晰的掌握工作進度，無法清晰的把握此次提交的概要資訊。在發現錯誤後也無法準確的定位引起錯誤的檔案。所以，在提交工作時，要填寫明晰的標註，能夠概要的描述所提交檔案的資訊，讓專案組其他成員在看到標註後不用詳細看**就能了解你所做的修改。
八．慎用鎖定功能
SVN提交工作時需要注意的事項
一 提交之前先更新 1.svn更新的原則是要隨時更新，隨時提交。當完成了乙個小功能，能夠通過編譯並且自己測試之後，謹慎地提交。2.如果在修改的期間別人也更改了 svn的對應檔案，那麼 commit就可能會失敗。如果別人和自 己更改的是同乙個檔案，那麼 update時會自動進行合併，如果修改的是同一行...
專案發布時需要注意的事項
經過幾個月的努力，我們組的專案walle終於要上線了，也許是經驗的不足，也許是太衝動了，上線後才發現上線準備的根本就不充分。經過這次事件後，認識到以下幾點，免得下次上同樣的當。1.上線前，要對自己嚴格一點，發現的問題，可以修復一定要修復，不要報有僥倖的心理，這個問題不重要，大家不會關注，一旦上線後，...
使用特殊索引時所需要注意的事項
在oracle裡除了我們常用的b樹索引外，還有一些特殊索引能被使用。如 倒序索引，位對映索引，函式索引等。我根據自己的體會，列乙個注意事項 倒序索引 oracle doc上說倒序索引比較適合於序列號產生的字段，如唯一編號。但是這樣的索引對於範圍的比較，如 between and 等操作是不起作用的 ...