1.前提
公司SVN賬號密碼和AD賬號密碼是綁定在一起的，為了保證代碼檢出總是最新，jenkins中做代碼檢查前總會從SVN中檢出最新代碼。
最近公司要求AD賬戶不得使用原始密碼，更改密碼后，jenkins在檢出代碼的時候出現了一個坑爹的問題：控制台打印的問題是subversion update has been canceled。
2.分析原因
subversion update has been canceled——SVN代碼無法正常更新，這很明顯是SVN密碼更改后的副作用。
3.所做的努力
3.1 修改jenkins本身的配置
修改完jenkins中一切和SVN有關的賬號密碼信息並重啟jenkins服務后，檢出代碼仍舊報錯：subversion update has been canceled。
上述努力失敗后，一度不敢再相信人生。谷歌了十幾分鍾，由於公司網速太不給力（可以吐槽一下么？），也沒得到一個有參考價值的答案。
平復了下心情，打算從頭開始分析。只是很糾結：jenkins該修改的配置都修改了，而且確保沒有遺漏，為什么就沒有生效呢？
3.2 重新分析
拿出一個代碼檢查作業仔細分析，大腦中顯現出jenkins后台做的一切工作，看到SVN檢出的策略：Use 'svn update' as much as possible（平時一直沒有太注意這個所謂的策略，因為默認就是它），虎軀一震，有了！
這應該就是jenkins檢出的時候利用了slave SVN本身的檢出功能，那我就應該去修改子節點中SVN保存的用戶密碼等相關數據。
3.3 再次出發
打開slave SVN客戶端，setting → Saved Data → 選擇「Authentication data」，點擊【Clear】 → 確定。
進入SVN Resp-browser，就會彈出一個框，讓重新輸入賬戶密碼，輸入后勾選上保存。
再次構建jenkins中的作業，果然好了！
由於公司電腦只能在內網使用，無法截圖，就不再上圖了。
4.體會
① 遇到問題應該先自己分析可能的原因，而不是直接谷歌。要對自己有信心，相信自己獨立解決問題的能力。
② 再次體會到jenkins m/s架構的優勢——master只負責調度管理，slave負責具體執行。這也為jenkins出現的問題提供了兩個大維度的思考面：master層面和slave層面。