我們的團隊正在考慮轉移到SVN。但是，我似乎無法找到一個方法來做到以下幾點：subversion：如何管理已調整的文件
我需要做一些小改動本地約20個文件存儲庫中的W/O有SVN認爲他們「改變」，幷包含在提交。 （像通信超時和日誌記錄級別的變化。）
理想情況下，我想將修改過的文件合併到版本庫中的新版本。 （保持調整的本地文件與其他用戶承諾的更新保持最新。）
我無法想象我們在需要/需要時是獨一無二的。
圍繞這種用例有最佳實踐嗎？
我正考慮的一件事是把所有的調整文件放入一個分支的「調整」工作副本。
然後將我調整過的文件合併到我的「官方」工作副本中。
然後使用比較「調整」和「正式」工作副本的腳本更新我的忽略列表。該腳本還會忽略並警告我任何文件，這些文件可能會調整和其他可能需要提交到存儲庫的更改。
這似乎還挺有趣，我無法想象沒有更好的方法。
只要有文件在存儲庫中，但不想更改，就會最終更改這些文件。使用什麼版本控制系統並不重要。有人會不小心更改這些文件。
有幾件事情，可以幫助：
build.template.properties文件。該文件已簽入，但開發人員可以將其複製到build.properties並按照他們想要的方式進行調整。我使用svn:ignore和我的pre-commit hook來確保沒有人檢查實際的build.properties文件。根據您使用的語言，您不能從定義值的單個文件加載這些調整，並且擁有一組默認值，這些默認值被提交給源代碼控制，並允許每個開發人員創建自己的「調整」文件被忽略？
通過這種方式，源代碼版本一致且穩定，並具有合理的合理默認值，但開發人員可以調整其本地副本的內容。
聽起來不像版本控制問題，更像是「我們如何獲取值來覆蓋可調整設置」問題。
我同意記錄和超時配置的具體情況的答案。但是，在調試和開發期間，我經常需要進行其他實驗或調查性更改。如果是這樣，在知道我真正想做的更改後，我會單獨退房，並將這些更改置於乾淨，最近簽出的副本中。以這種方式工作也可以降低解決團隊項目中衝突變化的風險。 –
是的，我也曾經這樣工作過，現在用git我只是創建一個分支;） –
我同意邁克爾關於超時和日誌級別的配置。這將減少我調整文件的數量。但是，我仍然有不少調整。 – punk4funk
端注：如果
我需要做一些小改動本地約20個文件存儲庫中的W/O有SVN認爲他們「改變」，幷包含在提交。
是在您的工作流程相當普遍的要求，那麼你可以考慮使用不顛覆，但是，鐵，水銀與MQ + mqcollab擴展或-X選項中汞提交
）不幸的是，我們有2個選項，內部工具或SVN，我<3 mega-corps！ – punk4funk
只是不要犯包含設置的文件。提交設置爲「待配置模板」的文件。然後（如果你友好的話）放下一個「readme.txt」文件來解釋複製模板文件，在編輯器中打開它，並設置適當的值，如文件在其註釋中描述的那樣。
你不需要每次安裝「調整」，但你爲什麼要提交他們擺在首位。源代碼控制不是「系統備份」，而是源代碼控制。
PS。如果您確實需要如上配置20個不同的文件，請考慮改進配置控制的集中化。
我可以按照你的建議減少調整文件的數量，但不是所有的都可以。不需要進行調整 – punk4funk
源代碼不能替代備份，如果需要恢復系統，請安裝備份客戶端並配置備份系統。而不僅僅是你知道的20個文件在系統上進行了「調整」，每個系統的改變都不是源代碼的一部分，但是提交它們的模板是合理的。過度依賴源代碼控制來實現超過其設計的目標 - 比如僅僅將備份分配給每個開發框（這應該是私有的），這可能最終會成爲一個重大的安全隱患。 –
對於第1頁 - 這些文件也可以被特殊的「更衣室」用戶鎖定 - 即使真正的作者也無法更改鎖定 –
1.預先提交鉤子看起來非常強大。我可以想象我們將它用於很多事情。但是，它看起來並不像個人用戶可以很容易地定製一些非常用戶特定的東西。
2.這可能是假設我可以自動創建更改列表並添加所有調整過的文件的方式。
3.我檢查了我的調整，其中不少可以根據您的建議進行自定義。但是，有些特定於我的我無法做到這一點。
4.太好了。我確信希望這樣的事情能夠奏效！
Thx！ – punk4funk
只是爲了跟進...我們的團隊終於轉移到了SVN，並且更改列表對我們的需求非常有用。我們看到的一個問題是Eclipse插件的「變更集」不是「真正的」SVN變更列表。 ：^（ – punk4funk