如何鼓勵更頻繁的進入SVN信息

一組，我的工作約半年前從VSS切換到SVN開發商。從CheckOut-CheckIn到Update-Commit的轉換在許多用戶上很難實現。現在他們不再需要在文件完成時檢查文件（或者更準確地說，現在沒有其他人可以看到他們已經檢出文件並告訴他們重新檢查以釋放文件上的鎖文件），它發生在不止一次的情況下，用戶已經忘記在完成之前很長時間才提交修改。如何鼓勵更頻繁的進入SVN信息

雖然大多數用戶良好犯下的變化，這個問題是相當嚴重，決定可能進行強制用戶get locks on all files in SVN before editing。我寧願不會看到這種情況發生，但我對以另一種方式改善情況感到不知所措。所以，任何人都可以提出如何做任何操作：

跟蹤哪些文件用戶編輯，但有
尚未提交的修改，鼓勵用戶與當他們這樣做
幫助玩完必須習慣的新的版本控制模式

外的現成解決方案，歡迎各界人士用戶教育（即：提醒用戶桌面程序提交，如果他們沒有穿上e在給定的時間間隔內，自動獲得用戶提交率的統計信息，並在頻率降至某個閾值以下時發送警告電子郵件等）。

來源

2010-02-22 Yaakov Ellis

簽入，否則我們會找開發商誰將會籤來代替你總是工作 – 2010-02-22 19:25:36

...用戶忘記了提交修改，直到它們完成後很久。

我認爲這是這裏的問題。如果功能/錯誤修復未被簽入，如何「完成」？你有問題跟蹤系統記錄未解決的問題嗎？你有一個持續集成系統，一旦簽入就進行單元測試嗎？

如果開發者沒有責任地做自己的事情，那麼遇到難以讓每個人都合作的問題就不足爲奇了。您將需要某種監督（項目經理？團隊負責人），負責確保個人開發人員與其他開發人員團隊進行合作。

來源

2010-02-22 18:29:05

不幸的是，單元測試和持續集成仍處於採用的早期階段。即使在單元測試中，如果用戶忘記將單元測試提交給測試項目，那麼測試仍然可能通過，忘記提交。 – 2010-02-22 18:31:48

嚴肅地說，這是開發經理/主管需要解決和執行的事情。 – 2010-02-22 18:38:42

@Yaakov Ellis，如何不讓同一個人編寫代碼和單元測試？ – Abizern 2010-02-22 18:47:18

閱讀提交日誌，並詢問他們的身份的人，當他們將在他們的變化進行檢查。承諾整件事比作出「拯救」的方式要好。

開發完成的東西，怎麼會忘記檢查一下嗎？交付過程是否使用戶從開發人員自己的計算機上運行構建？

來源

2010-02-22 18:26:15 Christian

閱讀提交日誌在理論上起作用，但很難手動完成。某些類型的自動化方法將是首選。交付流程過程可能涉及第三方用戶從SVN更新，然後上傳更改。不幸的是，單元測試仍然有一些方法，所以沒有辦法自動檢查是否包含所有更改（即使存在同樣的忘記提交新單元測試的問題也會存在）。 – 2010-02-22 18:29:24

你使用任何一種錯誤/功能跟蹤軟件？
當他們勾選完成的作品時，可以要求他們包含修訂號。

來源

2010-02-22 18:26:42

使用FogBugz進行錯誤跟蹤和自行開發的軟件，用於新項目的任務跟蹤。 – 2010-02-22 18:30:16

+1並且還配置錯誤跟蹤器以要求一些QA，例如代碼評論或測試評論。無論如何這是一個好主意，它肯定會迫使人們犯下！ – MarkJ 2011-12-30 12:27:29

我覺得你的問題實際上是缺乏contigous構建系統combinet與錯誤/功能/變化的跟蹤。通過一個bug跟蹤系統和一個連續的構建，開發人員只有在他的更改生成了自動構建並構建了包含更改的版本後才能聲明「完成」，並通過構建驗證測試並將其放到發佈放置位置。由於改變「構建」爲構建的唯一方法是檢入（可能的反向將功能分支集成到主分支/主幹），開發人員必須檢入，否則他們將永遠不會完成任何事情。

來源

2010-02-22 18:26:44

在一個小型開發小組中，我看到每天發送給組的郵件列表的電子郵件列表顯示前一天簽到的摘要以及顯示簽入次數，總行數等的非正式「賽馬」。在過去的30天內有幫助。很明顯，你不能使用任何類型的性能指標來使用多個checkins，但它仍然很有趣，並且讓每個人都能夠控制源代碼。「嘿，喬剛剛在本月通過了登記手續，哦等等，我從來沒有在昨天檢查過這個密碼。」

這也有其他優點的人進來在早晨和在他們的COFEE或不管它讓別人在開發商的頭腦做閱讀。當我們進入「代碼凍結」並接近發佈時，我們實際上只是通過簽入摘要來更改電子郵件，以包含實際的「差異」，以便每一行代碼立即得到多方面的關注。

來源

2010-02-22 18:28:14 bdk

你知道哪些自動化工具可以生成這樣的電子郵件嗎？ – 2010-02-22 18:30:43

對不起，我相信我們的開發者之一寫了我們的電子郵件腳本有一天晚上的樂趣，它只是抓住了。 – bdk 2010-02-22 18:42:28

如果開發人員忽略源代碼管理，那麼開發人員是否也可能忽略每日電子郵件？ – 2018-02-21 16:05:46

通常情況下，鼓勵開發者經常提交的東西是自我保存。當由於合併衝突而導致更新變得困難時，他們發現通過推送更改緩解了問題，他們會更頻繁地提交。

雖然聽起來有點根本錯誤。您的開發人員如何在不通過VCS的情況下對其發佈的產品進行更改？你應該關閉後門。

來源

2010-02-22 18:48:23

「您的開發人員如何在不通過VCS的情況下對其發佈的產品進行更改」 - 這就是問題所在。在少數情況下，代碼在應該發佈時尚未發佈。我試圖找出一種方法來關閉後門。 – 2010-02-22 19:50:56

如果您之前使用過VSS，那麼您可能在Visual Studio中工作。 AnkhSVN有一個掛起的更改窗口，如TFS和VSS中的窗口。該工具窗口自動顯示您的解決方案中本地修改了哪些文件。

對您的更改使用此掛起的更改窗口可以輕鬆處理小的/邏輯更改，並在早期而不是稍後提交這些更改。

[見的舊AnkhSVN的版本截圖]

來源

2010-02-22 19:16:41

有點類似，在Eclipse中，帶有本地更改的文件在包資源管理器中標有一個小圖標，指示該文件的狀態爲svn。（金色圓柱=上次更新後沒有本地更改，棕色星形=修改，藍色「+」=添加等）。如果你始終保持這種觀點，那麼你就會習慣於看到那個和所有黃金圓柱的含義，即「我所做的每一件事都已經承諾過了。」 – MatrixFrog 2010-02-24 00:16:36

找一個自動構建機（或至少是一個執着的人做的版本），並且只能從這臺計算機部署。然後，您的代碼在您提交之前不會部署，並且有助於確保沒有任何內容被排除在存儲庫之外。

此外，團隊中至少有少數成員承諾提早並經常鼓勵其他人也跟上，因爲緩慢的提交者必須處理更多的本地合併衝突。

來源

2010-02-23 11:44:07

體面的錯誤/功能跟蹤器將允許您在提交更改時添加錯誤編號。例如，如果我正在運行Redmine，我可以在我的Subversion提交消息的某個地方提交「修復＃323」，它會自動關閉bug /任務323。你只需告訴Redmine存儲庫在哪裏，無論如何都是要求的。

通過這種方式，您可以查看哪些更改已針對每個錯誤提交，並且沒有提交的錯誤將會打開（除非手動關閉）。您可以將缺陷分配給里程碑，在里程碑發佈之前，檢查針對缺陷的提交。

Trac也是如此，許多其他人也如此。

來源

2010-02-23 17:25:57

這裏的問題並沒有把Commits和任務聯繫起來。這是爲了確保人們正在犯的一切。 – 2010-02-23 19:00:46

我認爲這個想法是，你說「你修復了這個錯誤？」如果開發者說「是的，但我還沒有提交」，那麼它被認爲「尚未修復」 – MatrixFrog 2010-02-24 00:18:38

該協會旨在確保人們承諾一切。這個想法是，如果你從一個網站獲取任務，說完這個任務的最簡單的方法就是在提交註釋中添加「修復＃323」，這樣可以確保提交。 – 2010-02-25 11:45:40

自動化您的構建和部署，並使其沒有什麼是「完成」，直到它在測試服務器上進行測試的過程的一部分

來源

2010-02-23 17:29:49

如何鼓勵更頻繁的進入SVN信息

回答

相關問題