SVN能做類似git過濾器的屬性嗎？

我對git並不是很熟悉，但它看起來好像可以使用過濾器屬性，例如在提交之前整理XML文件。 SVN手冊專門（強烈地）建議不要使用pre-commit掛鉤。有另一種方法嗎？SVN能做類似git過濾器的屬性嗎？

來源

2010-11-23 Sam Brightman

答案似乎是：不。我相信拒絕提交是SVN唯一的安全選擇。

來源

2010-12-30 18:03:41

+1是的。不，那是。 – 2010-12-31 08:48:05

沒有其他辦法可以做到這一點，你會發現，即使支持這樣的事情，也會讓你感到頭疼。甚至不建議在簽入前自己重新編寫代碼，因爲您的修訂版差異不會讓您瞭解真正改變的內容。如果某些東西的格式非常糟糕，以至於無法閱讀，我只會這樣做。

來源

2010-11-23 04:39:21 JOTN

這不是一個問題。以與VCS歷史有關的方式大規模更改文件的格式不是一次性操作。這些文件已經處於相當好的狀態，但重點是讓它們保持這種狀態。 – 2010-11-26 08:16:49

您希望做的任何事情的唯一方式是使用clean/smudge腳本來隱藏數據庫連接字符串，商業門戶的密碼等。這通常是在您可以擁有一個配置文件並且它是功能公共數據和私人安全數據的混合。

Pro Git Book's Attributes Section

希望這會有所幫助。

來源

2010-11-24 02:44:44

我的問題涉及到SVN。還有其他原因需要這樣做。 – 2010-11-26 08:03:57

這聽起來像是您的IDE或XML編輯器的工作。 Eclipse例如可以讓你指定各種自動操作（但是做一個糟糕的XML編輯器）......我確信有一個XML編輯器可以在保存時整理或重新格式化XML。

我不認爲差異應該是一個反對此的原因，因爲好的差異工具將有選擇忽略空白和/或不重要的差異，即使文件已被重新格式化也使查看差異變得容易。

取決於你使用的團隊，如果這個「整理」正在顯着地改變你觸摸的每一個文件，你可能想避免它，或者它可能是完全正確的。例如，我在Eclipse上修剪尾隨空白並在保存時添加缺少的@Override註釋，但我不告訴它在保存時完全重新格式化我的.java文件。

來源

2010-11-25 03:09:29

有人使用幾種不同的編輯器，並且還有自動處理完成。通常這些文件沒有顯着改變，但需要使它們符合團隊標準。 – 2010-11-26 08:15:38

嗯。在那種情況下，它可以作爲自動化處理的一部分來完成嗎？這或者可能讓開發人員在其編輯器外部手動運行xml清理腳本。即使開發人員使用不同的編輯器，是不是可以讓每個編輯器配置適當，所以這不是問題？ – 2010-11-26 22:30:16

使用Git，您有完整的存儲庫副本供您個人使用，因此在提交時消除文件並不是問題。畢竟，你只是在影響自己。

但是，Subversion有一個集中式存儲庫，這意味着在提交過程中對文件進行掃描更加棘手，通常不鼓勵。

其中一個問題是，這種類型的事件必須由鉤子和鉤子來處理，因爲它們在服務器上運行，無法訪問您的工作副本。他們可以通過只讀的svnlook命令檢查提交，但就是這樣。是的，有辦法避開它，但正如手冊所說的那樣，這是不推薦的。

即使使用像Git和ClearCase這樣的版本控制系統，在提交過程中可能會攔截文件，但它仍然不是一個好主意。首先，它可以在掛鉤腳本運行時減慢提交過程，這可能會挫敗用戶。其次，如果消除過程實際上破壞了文件，會發生什麼？開發人員在提交之前會測試並驗證其更改。「破天荒」比在休息室喝完最後一杯咖啡更糟糕，而且沒有製造另一個鍋。然而，這是一個開發者，他們做了他們所想的一切，而這是一個愚蠢的鉤子腳本！

這是應該由自動構建過程完成的事情（您正在使用像CruiseControl或Hudson這樣的增量構建系統嗎？）。這可以作爲測試的一部分來完成，如果文件格式不正確，構建可能被標記爲「不穩定」。事實上，哈德森有鉤子可以做到這一點，作爲構建過程的一部分，這使得這非常簡單。構建服務器可以通知程序員他的錯誤（糟糕的程序員！該文件沒有縮進！沒有甜甜圈給你！）和技術負責人或構建經理。

簽入的內容是開發人員編寫和測試的內容。檢查格式化，單元測試以及所有其他內容可以由構建系統完成。

來源

2010-12-30 18:44:13

SVN能做類似git過濾器的屬性嗎？

回答

相關問題