สำหรับโปรแกรมเมอร์ หรือทีมพัฒนาเล็กๆ แล้ว สิ่งสำคัญสิ่งหนึ่งที่เรามักจะมองข้ามไป คือการสำรองข้อมูล และการจัดการเรื่องการใช้งานไฟล์โปรเจคร่วมกัน เชื่อหรือไม่ว่า บางที ถ้าลองสังเกตดูแล้วว่า เวลาที่เสียไปกับการบริหารจัดการเรื่องจิปาถะเหล่านี้ อาจจะกินเวลาของโปรเจค มากกว่าที่คุณคิดก็ได้

ลองมาสังเกตดูกระบวนการแชร์ไฟล์โปรเจค ที่คนส่วนใหญ่มักจจะทำกันก่อนดีกว่าครับ

วิธี “ตัวใครตัวมัน”

ลองนึกย้อนไปตอนสมัยเรียนนนะครับ เมื่อเราจะต้องทำโปรเจคใหญ่ๆ อย่าง Senior Project หรือ โปรเจคจบของรายวิชาต่างๆ ที่ต้องร่วมมือกันหลายคน วิธีที่เราใช้ในตอนนั้น ก็มักจะเป็นตามภาพด้านล่างนี้ ก็คือ วางโครงโปรเจคกันก่อน จากนั้นต่างคนก็ต่างไปทำกันมา ส่วนของใครของมัน แล้วพอใกล้ๆ เวลาส่ง เราก็จะนำไฟล์ของทุกคนมารวมกัน ที่บ้านใครซักคน แล้วก็ภาวนาให้ทุกอย่างผ่านไปได้ด้วยดี

แต่เราก็รู้ดีอยู่แล้วว่า มันเป็นเรื่องที่เป็นไปไม่ได้ อย่างน้อย ถ้าเกิดใครเพิ่มไฟล์ใหม่เข้ามา ที่ชื่อดันเหมือนกัน ก็ยุ่งแล้วครับ แต่ปัญหาที่ยุ่งเหยิงกว่านั้นก็คือ เราไม่มีทางรู้ได้เลยว่า เมื่อทุกส่วนรวมกันแล้ว มันจะใช้งานได้ อย่างที่เราคิดไว้ จริงอยู่ที่ มันอาจจะคอมไพล์ผ่าน แต่ก็ไม่มีใครการันตีถึง ความถูกต้องได้ จริงไหมครับ?

แชร์ไฟล์ไว้ที่ File Server

วิธีหนึ่งที่ดู Advance ขึ้นมาหน่อย ก็คือเอาไฟล์ ใส่ไว้ใน Shared Folder แล้วทุกคนก็มารวมตัวกันที่บ้านใครซักคน เพื่อจะได้ทำงานไปพร้อมๆ กัน โดยการ Map Drive มา แล้วก็เปิดโปรเจคทำไปพร้อมกันเลย

วิธีนี้ แน่นอนว่า เราสามารถมั่นใจเรื่องความถูกต้องได้มากขึ้น เพราะเราทำงานกับไฟล์โปรเจคที่สมบูรณ์จริงๆ แต่ปัญหาก็อาจะเกิดขึ้นได้ ถ้าเกิดมีความจำเป็นที่ต้องใช้งานไฟล์เดียวกัน พร้อมๆ กัน ลองดูจากภาพด้านล่างนี้ครับ (ภาพจากคู่มือ TortoiseSVN)

นั่นก็คือ ถ้าต่างคนต่างลืมบอกกันว่า เฮ้ย เราจะใช้ไฟล์นี้นะ ก็จะเกิดเหตุการณ์ หัวเราะทีหลังดังกว่า เพราะใครเซฟท้ายสุด ก็จะเป็นคนที่สามารถบันทึกการเปลี่ยนแปลงของตัวเองลงในไฟล์ได้ โดยที่การเปลี่ยนแปลงของอีกคน ก็จะหายไปเลย

จึงเป็นที่มาของระบบ Source Control แบบแรก คือ

Lock-Modify-Unlock

ระบบนี้เป็นระบบง่ายๆ นั่นก็คือ ใครที่ต้องการจะแก้ไฟล์นี้ ก็จะต้องทำการ “จอง” ไฟล์ไว้ก่อน ถ้าใครจะเข้ามาแก้ไขไฟล์นี้ ก็จะแก้ไม่ได้ คล้ายกับระบบ Lock ไฟล์ที่มีใน OS ทั่วไปครับ อันที่จริงแล้ว ระบบนี้ก็ไม่ได้ต่างอะไรกับการแชร์ไฟล์โดยปกติ แตกต่างกันแค่ เราถูกบังคับให้ต้องสื่อสารกันว่า ใครจะใช้ไฟล์ นั่นเอง

แต่สมมุติว่า ถ้าเราไม่ได้นั่งทำงานที่เดียวกัน เพราะพอมีระบบแล้ว ต่างคนก็ต่างนั่งทำงานที่บ้านตัวเอง แล้วผมเกิดล็อคไฟล์ไว้เพื่อแก้ไข แล้วออกไปข้างนอกดูหนังคลายเครียด เพื่อนๆ คนอื่นที่อยู่ที่บ้าน ก็หมดสิทธ์ใช้ไฟล์ไปโดยปริยาย จนกว่าผมจะดูหนังจบ และกลับถึงบ้าน ไม่อย่างนั้น ก็อาจจะต้องให้คนที่เป็นแอดมิน ปลดล็อคให้ เพื่อจะได้ใช้ไฟล์ได้

จะเห็นว่า ระบบนี้ แม้จะช่วยเรื่องการแชร์ไฟล์ได้ แต่ก็ยังสร้างปัญหาอยู่ดี ซึ่งขอสรุปให้เป็นข้อๆ ดังนี้

1. ทำงานได้ช้าลง เพราะต้องแย่งไฟล์กัน
   แน่นอนว่า โดยทั่วไปแล้วแม้เราจะสามารถแยกโปรเจคเป็นไฟล์ย่อยๆ ไม่เกี่ยวข้องกันเลยได้ แต่โอกาสที่จะมีการใช้ไฟล์ร่วมกัน ก็มีอยู่ อย่างเช่น ไฟล์ที่เป็น Web Service, ไฟล์ที่เก็บ Enum หรือ Constant เป็นต้น
   
   นอกจากนี้ การแก้ไขส่วนใหญ่ มีโอกาสน้อยมาก ที่เราจะแก้ไขที่จุดเดียวกัน แต่ระบบนี้จะทำให้คนสองคน ซึ่งจำเป็นต้องแก้ใขไฟล์เดียวกัน แต่คนละส่วน ก็ไม่สามารถทำงานได้พร้อมกันอยู่ดี
   
2. แอดมินปวดหัว
   เนื่องจากทุกคนสามารถ Lock ไฟล์กันได้อย่างอิสระเสรี จึงเกิดเหตุการข้างต้นที่ผมยกตัวอย่างไปแล้วได้ นั่นคือ ล็อคตาย คือ คนล็อค ล็อคเสร็จแล้ว มันก็ตายไปเลย ไม่ยอมมาปลดล็อคให้ ซึ่งจากที่ผมได้ทำงานร่วมกับระบบ Source Control แบบนี้ บ่อยครั้งมาก ที่เราจะต้องตะโกนบอกให้เพื่อนอีกคน คืนไฟล์ให้ หรือถามว่า ใช้เสร็จหรือยัง ถ้าเกิดวันนั้นเจ้าตัวคนล็อค ไม่ได้มาทำงาน ก็ต้องเสี่ยงให้แอดมิน ปลดล็อคให้ ซึ่งก็จะทำให้เกิดปัญหาที่อีกข้อ ตามมา นั่นก็คือ
   
3. เกิดปัญหางานหายได้ง่าย
   ระบบ Source Control ลักษณะนี้ ก็ยังคงทำงานในแบบไฟล์อยู่ ไม่ได้ดูแลการแก้ไขตัวเนื้อไฟล์จริงๆ ซึ่งถ้าผู้ที่เคยใช้ระบบ Visual Source Safe มาก่อน น่าจะทราบดี ถ้าหากว่าเราทำการแก้ไขไฟล์ในเครื่อง แล้วสั่ง Get Latest Version ออกมา ระบบก็จะแค่ตรวจสอบว่า ไฟล์ในเครื่อง กับไฟล์บน Source Safe นั้น เหมือนกันหรือไม่ ถ้าไม่เหมือนกัน ก็มีแค่สองทางเลือกคือ Lock ไฟล์ เพื่อแก้ไข หรือ เอาไฟล์จากบน Source Safe ทับไฟล์ของเราเลย  (โดยที่ไม่ได้บอกด้วยว่า ไฟล์ของเรา กับไฟล์บน Server ต่างกันอย่างไร) บางที ถ้าเราเผลอไปกดให้ทับไฟล์ของเราในเครื่อง ก็เท่ากับจบกัน

ถ้าลองมองดีๆ ปัญหาแบบเดียวกันนี้ ก็เกิดขึ้นกับระบบฐานข้อมูลครับ แต่ระบบ DBMS เขาจัดการด้วย Transaction นั่นคือ แต่ละคน ก็จะเห็นมุมมองของ Database ในชั่วขณะที่คนนั้น ติดต่อเข้ามา โดยที่การเปลี่ยนแปลงของอีกคน จะไม่ส่งผลกระทบข้ามมาเลย และถ้าต้องการบันทึกการเปลี่ยนแปลงที่เกิดขึ้น ก็ต้องสั่ง Commit Transaction เพื่อให้ระบบ DBMS ตรวจหา Conflict ว่ามีการพยายามแก้ไขข้อมูลจุดเดียวกันหรือไม่ และเกิดขั้นตอน Conflict Resolution ต่อไป

ด้วยแนวคิดเดียวกันนี้ ก็มี Source Control อีกแบบเกิดขึ้น นั่นก็คือ…

Copy-Modify-Merge

ระบบแบบนี้ จะทำงานคล้ายกัยฐานข้อมูลครับ นั่นคือ แต่ละคนสามารถติดต่อเข้ามา เพื่อดูข้อมูลล่าสุด แล้วแก้ไขเปลี่ยนแปลงได้ตามใจชอบ จนกว่าจะพอใจ แล้วสั่ง Commit เพื่อเซฟการเปลี่ยนแปลง เพื่อความเข้าใจ ผมจะอธิบายตามภาพด้านล่างนี้ครับ

แรกเริ่มเลย ทั้งแฮรี่ และแซลลี่ สามารถเปิดดูไฟล์ A พร้อมกันได้ แล้วจะทำการแก้ไขเปลี่ยนแปลงอย่างไรก็ได้ ตามใจชอบ ในเครื่องของตัวเอง โดยที่ไม่ต้องสั่ง Lock ก่อน

ทีนี้ แซลลี่แก้ไขจนเสร็จแล้ว ก็ทำการเซฟไฟล์ กลับเข้าไปยังระบบ และถ้าแฮรี่ ต้องการจะเซฟบ้าง ก็จะโดนปฏิเสธโดยระบบ เพราะว่าตอนนี้ ไฟล์ในระบบนั้น ไม่เหมือนกับไฟล์ที่แฮรี่เคยอ่านมาดูตั้งแต่ครั้งแรกแล้ว

ดังนั้น แฮรี่ก็จะต้องอ่านไฟล์ที่ถูกแก้ไขโดยเซลลี่ เข้ามาดูในเครื่องก่อน และระบบ ก็จะจัดการ “Merge” หรือ รวมการเปลี่ยนแปลง ที่แฮรี่ทำไว้ในเครื่อง (A’) เข้ากับไฟล์ที่ได้ออกมาจากระบบ (A”) โดยอัตโนมัติ ซึ่งในขั้นตอนนี้ ถ้าเกิดว่าแซลลี่ และแฮรี่ ไม่ได้แก้ไขไฟล์ที่จุดเดียวกันเลย ระบบก็จะสามารถรวมไฟล์ให้ได้โดยอัตโนมัติ

แต่ถ้าหากว่าแซลลี่ และแฮรี่ เกิดแก้ตรงจุดเดียวกันขึ้นมา ไฟล์ในเครื่องแฮรี่ ก็จะอยู่ในสถานะ “Conflict” ซึ่งแฮรี่ ก็จะต้องไปเรียกแซลลี่ มานั่ง Merge ด้วยกัน ว่าเธอแก้ตรงไหน ฉันแก้ตรงไหน ต้องเก็บอะไรไว้ เอาอะไรออก

จากนั้น เมื่อทั้งคู่ Merge กันได้แล้ว แฮรี่ก็จะสามารถเซฟไฟล์ กลับลงไปในระบบได้ และเมื่อแซลลี่ โดนกลับไปถึงโต๊ะ ก็สามารถอ่านไฟล์ที่ Merge กันได้แล้ว มาเก็บไว้ในเครื่อง เพื่อทำการแก้ไขต่อไป

แล้วประโยชน์สำหรับนักพัฒนาคนเดียวละ?

แน่นอนว่า สำหรับคนที่ฉายเดี่ยว เรื่องการแชร์ไฟล์นี่ไม่ใช่ปัญหาอยู่แล้ว แต่ปัญหาที่ผมเชื่อว่า ทุกคนน่าจะเคยพบเหมือนกัน ก็น่าจะหนีไม่พ้น…

• เมื่อวานยังใช้ได้นี่นา ทำไมวันนี้ใช้ไม่ได้แล้ว
• วันก่อนเราแก้อะไรไปบ้างวะเนี่ย???
• ปัญหานี้ เวอร์ชั่นก่อน ไม่เคยเป็นนี่นา!?!?

แต่ถ้าคนที่มี Backup ปัญหาก็คงจะทุเลาไปได้บ้าง แต่อย่างไรก็ตาม เรามักจะ Backup กันแบบไม่จริงจัง เช่น Zip เอาไว้เฉยๆ บ้าง บางคนเป็นระเบียบหน่อย ก็จัดเป็นวันๆ ไว้ แต่ถึงอย่างไร Backup ก็ข่วยได้แค่เก็บไฟล์ก่อนหน้านี้ไว้ได้ แต่ไม่ได้ช่วยบอกเราอยู่ดีว่า เราแก้อะไรไปบ้าง

ขอแนะนำ Subversion

สำหรับระบบ Source Control ในท้องตลาดก็มีเยอะแยะมากมาย แต่ตัวหนึ่งที่มีความน่าสนใจเป็นพิเศษ เนื่องจากเป็น Free Software และมีการใช้งานอย่างแพร่หลาย ก็คงจะหนีไม่พ้นเจ้า Subversion นี่ละครับ เนื่องจากความที่มันเป็น Free Software จึงทำให้มีคนพัฒนาระบบและโปรแกรมต่างๆ มาติดต่อกับมันเป็นจำนวนมาก จนเมื่อเอาทั้งหมดมารวมกันเนี่ย สามารถทำระบบ Life Cycle Management อย่าง Team System ได้เลยทีเดียว

สำหรับ Subversion นั้น มีคุณสมบัติที่ดีกว่าระบบอื่นดังนี้ครับ

• ทำงานได้ทั้งแบบ Copy-Modify-Merge และ Lock-Modify-Unlock
  เพราะว่าไฟล์บางประเภท เราไม่สามารถทำการ Merge ได้ครับ อย่างเช่นไฟล์รูป หรือไฟล์ PDF เป็นต้น Subversion ก็เลยสนับสนุนทั้งสองแบบ
  
• Subversion มอง Version แบบทั้งโปรเจค
  ระบบของยี่ห้ออื่นบางทีจะมีมุมมองของโปรเจคที่เพี้ยนไป นั่นคือระบบจะมองเวอร์ชั่นเป็นตามไฟล์ แต่ว่าถ้าเราคิดดูจริงๆ แล้ว โปรเจคทั้งโปรเจค แค่มีไฟล์โดนแก้ไปเพียงไฟล์เดียว ก็ทำให้เวอร์ชั่นเปลี่ยนแล้ว จริงไหมครับ?
  
• การกระทำหลายๆ อย่าง สามารถรวมกันได้ ในการบันทึก 1 ครั้ง (Atomicity)
  ลองนึกดูว่า ในการทำงานจริงๆ เช่นการแก้บัก หรือเพิ่มฟีเจอร์ เราไม่ได้มีการแก้ไขไฟล์ แค่ไฟล์เดียว แต่อาจจะต้องมีการแก้ไขไฟล์หลายๆ ไฟล์ หรือแม้แต่การเพิ่มไฟล์ใหม่ เพิ่มโฟลเดอร์ใหม่เพื่อใส่รูป เป็นต้น การกระทำทั้งหมดนี้ เราสามารถ บันทึกได้ โดยการ Commit เพียงครั้งเดียว ซึ่งจะทำให้เวลาเราไปดูรายงานการเปลี่ยนแปลง ก็สามารถมองเห็นได้อย่างชัดเจนว่า การเพิ่มฟีเจอร์นั้นๆ หรือแก้บักตัวนี้ ได้เกิดการเปลี่ยนแปลงอะไรบ้างในภาพรวม
• สามารถทำงานร่วมกับระบบ Bug Tracking หรือ Project Management ใดๆ ก็ได้
  เนื่องจากตัว Subversion สามารถกำหนด Field เพิ่มเติม ตอน Commit ได้ เราจึงสามารถนำมันมาใช้ร่วมกับระบบ Project Management ได้ โดยไม่ต้องเปลี่ยนระบบใหม่ทั้งหมด ซึ่งเอาไว้ผมจะมาเล่าให้ฟังในโอกาสต่อไปครับ

ต้องลงอะไรบ้าง

สำหรับการสรรหา Subversion มาติดตั้งในเครื่องนั้น ง่าย และถูกลิขสิทธิ์ด้วยครับ โปรแกรมหลักๆ ที่เราจะใช้ ก็มีแค่TortoiseSVN เท่านั้นเอง ซึ่งเป็นทั้งระบบ Subversion ในตัว และ GUI สำหรับทำงานร่วมกับระบบ Subversion ด้วย (ถ้าใช้ Windows 64-bit ก็ต้องดาวน์โหลดแบบ 64-bit มาด้วยนะครับ)

แต่ถ้าในการทำงานเป็นทีม ก็จะต้องมีโปรแกรมเพิ่มเติมด้วยครับ ดังนี้

• WinMerge จริงๆ แล้วตัว Subversion มันสามารถ Merge ให้เราเองได้อยู่แล้ว แต่ว่าโปรแกรมนี้ จะใช้ในกรณีที่เกิด Conflict ขึ้นครับ แน่นอนว่า ถ้าทำงานคนเดียว โปรแกรมนี้ไม่ต้องใช้เลย เพราะยังไงก็ไม่มีวันเกิด Conflict
  
• Visual SVN Server ชื่อก็บอกอยู่แล้ว ว่าเป็นตัว Server ครับ ใช้สำหรับลงในเครื่อง Server เท่านั้นครับ ในเว็บจะมี Plugin ของ Subversion สำหรับ Visual Studio ด้วย แต่ว่ามีค่าใช้จ่ายครับ เราไม่ชอบ อิอิ

หรือถ้าคนที่อยากจะทำงานจาก Visual Studio อย่างเดียวเลย (ซึ่งผมเองไม่ค่อยชอบ) ก็มีครับ นั่นคือ AnkhSvn ซึ่งได้รับการพัฒนาอย่างต่อเนื่องมาน่าจะเกิน 5 ปีแล้ว

สำหรับโพสนี้ ผมขอแนะนำการใช้งานทั่วไป สำหรับทำงานคนเดียวก่อนนะครับ ซึ่งจะเป็นพื้นฐาน ก่อนจะต่อยอดไปเป็นการทำงานไปทีมในโพสต่อไป อ้อ ลงแล้วอย่าลืม Restart เครื่องก่อนนะครับ

การใช้งาน

หลังการติดตั้ง TortoiseSVN แล้ว จะไม่มีโปรแกรมอะไรใหม่ในเครื่องเลยครับ เพราะว่าการทำงานของ TortoiseSVN นั้น จะเป็นแบบ Shell Extension ซึ่งฝังลงไปในตัว Windows Explorer เลย

สมมุติว่า ตอนนี้เรามีโปรเจรอยู่แล้ว และต้องการเพิ่มโปรเจคนี้ เข้าไปยัง Subversion สามารถทำได้ตามนี้ครับ

1. อย่างแรกเลย เราจะต้องมีฐานข้อมูล ที่จะเก็บตัวโปรเจคของเรา เรียกว่า Repository ก่อน และเนื่องจาก Subversion มอง Version เป็นแบบภาพรวม เราจึงควรจะมี Repository แยกกันเป็นโปรเจคไปด้วย แต่ถ้าไม่สะดวก หรือไม่ได้ต้องการทราบเลขเวอร์ชั่นที่ละเอียดมาก ก็สามารถจับทุกโปรเจค มารวมกันได้ครับ แต่ต้องจำไว้ว่า การ Commit ครั้งหนึ่ง จะทำให้ Subversion มองว่าทั้ง Repository ได้ขยับเวอร์ชั่นไป เป็นเวอร์ชั่นใหม่ ซึ่งจะส่งผลกับทุกโปรเจคที่อยู่ใน Repository เดียวกันครับ
   
   วิธีสร้าง Repository ในเครื่องก็ง่ายมากครับ แค่สร้างโฟลเดอร์ใหม่ แล้วก็เข้าไปใน Folder นั้น คลิ๊กขวา เลือก TortoiseSVN –> Create Repository Here…
   
   ก็จะพบว่า ด้านในโฟลเดอร์ มีไฟล์กับโฟลเดอร์ขึ้นมาเยอะเลย
   
2. ทีนี้ ถ้าเราต้องการจะเข้าไปดู Repository (ต่อไปนี้ขอเรียกสั้นๆ ว่า Repo…จะเรียกมันว่าลิโพเลยดีมั๊ยนะ) ที่เราเพิ่งสร้างขึ้นมา ก็สามารถใช้คำสั่ง RepoBrowser ได้ โดยการคลิ๊กขวาที่ใดก็ได้ใน Windows Explorer หรือ Desktop
   
   จากนั้น ก็กรอก URL ของ Repo ลงไปครับ เนื่องจากว่าเป็นการเข้าถึง Repo ในเครื่อง ก็ต้องใช้ว่า
   
   file:///E:/Repositories/TestProject
   
   สังเกตว่า เป็นเครื่องหมาย / ธรรมดา และมี 3 ตัวนะครับ ที่อยู่ด้านหลัง file:
   
   ถ้าเกิดว่า อยากจะให้สามารถแชร์ Repo ข้ามเครื่องได้ด้วย ก็สามารถใช้เป็น Share Folder ได้ครับ แต่ด้วยระบบของ Subversion แล้ว เป็นสิ่งที่ไม่ควรทำอย่างยิ่ง ถ้าต้องการจะใช้ร่วมกันจริงๆ ควรจะลง Server SVN จะดีที่สุดครับ
   
3. จากนั้น ตามหลักสากล เราควรจะมีโฟลเดอร์ด้วยกัน 3 โฟลเดอร์ครับ คือ trunk branches tags ซึ่งเราสามารถใช้ RepoBrowser สร้างขึ้นมาได้เลย
   
   สำหรับทั้งสามโฟลเดอร์นั้น มีจุดประสงค์ดังนี้ครับ
   
   trunk เอาไว้เก็บตัวโปรเจค ที่เรากำลังพัฒนาอยู่ในปัจจุบัน
   
   branches เอาไว้เก็บ Branch ในกรณีที่เราต้องการจะลองเล่นอะไรใหม่ๆ แต่ไม่อยากจะให้กระทบกับตัวหลักใ trunk
   
   tags สำหรับเอาไว้เก็บ Build หรือจะเอาไว้ Backup เมื่อเราทำงานเสร็จเป็นระยะๆ ก็ได้ครับ เช่น Beta 1, RC1, V1.1 เป็นต้น
   
   อันที่จริงแล้ว เราไม่มีกฏตายตัวนะครับ ว่าจะต้องมีโฟลเดอร์เหล่านี้ เราสามารถจะจัดมันยังไงก็ได้ ตามใจชอบ แต่โฟลเดอร์ที่ผมแนะนำนี้ คือรูปแบบทั่วไป ที่ใช้กันอยู่ครับ
   
4. เมื่อเรามี Repo พร้อมแล้ว ก็เหลือแค่การเอาไฟล์ ใส่มาใน Repo ของเรา ซึ่งทำได้ง่ายมากครับ จากใน Windows Explorer อีกแล้ว
   
   สมมุติว่า ตอนนี้ผมมีโปรเจคอยู่แล้ว และต้องการนำมันไปไว้ใน SVN ที่ผมจะต้องทำก็คือ ไปที่โฟลเดอร์ที่เก็บไฟล์โปรเจค แล้วคลิ๊กขวา เลือก SVN Checkout ครับ
   
   จากนั้น URL ก็ใส่เป็น URL ของ Repo เรา พร้อมกับโฟลเดร์ trunk เช่น file:///E:/Repositories/TestProject/trunk และโฟลเดอร์ที่จะ Checkout ก็ตรวจให้แน่ใจว่าเป็นโฟลเดอร์ของโปรเจค เพราะตัว Tortoise SVN มันอาจจะเติมชื่อ Folder ใน SVN ให้ครับ
   
   
   เรียบร้อยแล้ว ก็กด OK เราจะถูกถามว่า โฟลเดอร์มันมีไฟล์อยู่แล้วนะ แน่ใจหรือเปล่า ก็ตอบ Yes ครับ
   
    
   
   จากนั้น จะมีอีกหน้าต่างเปิดขึ้นมา เพื่อรายงานสถานะ ทุกอย่างควรจะเรียบร้อยดีครับ
   
   
   ถ้าเราเปิดดูโฟลเดอร์ ก็จะพบว่า มีเครื่องหมายถูกในวงกลมสีเขียวอยู่ด้วย แปลว่า โฟลดอร์ของเรา ได้กลายเป็น Working Copy ของ โฟลเดอร์ trunk ใน Repo ของเราแล้วครับ นั่นก็คือ โฟลเดอร์นี้ จะเป็นโฟลเดร์ที่เราใช้ทำงาน ซึ่งมันจะลิงค์กับโฟลเดร์ trunk ในลิโพ เอ้ย repo ของเราครับ
   
   จากนั้นสำหรับครั้งแรก เราก็จะต้องเพิ่มไฟล์ให้เข้าไปอยู่ในลิโพซะก่อน โดยการใช้คำสั่ง Commit ครับ ซึ่งก็จะมีหน้าต่างใหม่เปิดขึ้นมา
   
   
   แต่ก่อนจะเลือก Select All แล้วกด OK ผ่านไปเฉยๆ ขอให้ลองดูซักนิดครับ ว่ามีไฟล์อะไรที่ไม่เกี่ยวข้องกับโปรเจคของเราหรือเปล่า อย่างเช่น
   
   - โฟลเดอร์ bin/obj ซึ่งเปลี่ยนทุกครั้งเมื่อ Compile โปรแกรม
   - ไฟล์ .suo ซึ่งเป็นไฟล์ Setting ของ Solution
   - ไฟล์ .user ซึ่งเป็นไฟล์ Setting ของ Project
   
   ถ้าพบ ก็เอาออกซะก่อน ไฟล์/โฟลเดอร์เหล่านี้ จะได้ไม่มากวนเลขเวอร์ชั่น (Revision) ของเรา เมื่อเสร็จเรียบร้อย SVN ก็จะรายงานว่า ตอนนี้ Revision เราอยู่ที่หมายเลข 6 นั่นคือ ตั้งแต่สร้างลิโพนี้มา เราได้คอมมิทไปแล้ว  6 ครั้งครับ ถ้าในขั้นตอนที่ผ่านมา ใครสร้างโฟลเดอร์แล้วลบหลายๆ ครั้ง ก็จะได้เลขที่เยอะกว่านี้ ส่วนผมเอง ก็สร้างแล้วลบไปครั้งนึงครับ
   
   
   
   เท่านี้ก็เรียบร้อยครับลิโพเราพร้อมใช้งานแล้ว

การใช้งานประจำวัน

ทีเรา ต่อไปพอเราทำงานไปเรื่อยๆ เราก็สามารถบันทึกการเปลี่ยนแปลงเอาไว้ช่วยเตือนตัวเอง และช่วยให้เราคืนชีพโปรเจคได้ ถ้าเราเกิดไปทำมันพังขึ้นมา สิ่งที่เราจะต้องทำเป็นประจำ กับตัว SVN ก็มีลักษณะการทำงาน ตามนี้ครับ

• ทำงาน เซฟ แล้ว Commit
  หลังจากทำงานไปซักพัก และรู้สึกว่า ทุกอย่างดูดี วันนี้จะพักนอนเล่นแล้ว คุณก็ควรจะสั่ง Commit สักครั้งครับ เพื่อบันทึกข้อมูลลง SVN และจะได้มีโอกาสเขียน Log ไว้เตือนตัวเองด้วย คำสั่งและหน้าจอ Commit ผมได้แสดงให้ดูไปแล้วในหัวข้อก่อนหน้านี้
  
• Update ดู Log แล้วทำงานต่อ
  เมื่อเริ่มงานใหม่ในแต่ละวัน เราก็อาจจะกด Update สักครั้งหนึ่ง เพื่อให้แน่ใจว่า ข้อมูลใน Working Folder เรา ตรงกับใน SVN แล้วอาจจะเปิด Log มาดู เพื่อเช็คว่า คราวก่อนๆ เราได้ทำอะไรไปบ้าง ซึ่งวิธีดู Log นั้นง่ายมากครับ คลิ๊กขวา แล้วเลือก Show Log เท่านั้น
  
  
  แต่ Log ของ SVN จะต่างกับของ VSS ตรงที่เราจะเห็น Log ของการ Commit ไม่ได้เป็น Log แยกตามไฟล์ เพราะอย่างที่ผมได้บอกไปแล้วว่า SVN มองการ Commit เป็นแบบ Atomic หรือมองเป็นการแก้ไขในภาพรวม ถ้าอยากจะดู Log เป็นแต่ละไฟล์ ก็สามารถทำได้ โดยการไล่ Commit ทีละไฟล์ครับ แต่ว่าการทำแบบนั้น จะเป็นการทำลายจุดเด่นเรื่องนี้ของ SVN ที่ช่วยให้เราติดตามการเปลี่ยนแปลงแบบภาพรวมไป
  
  นอกจากนี้ เรายังเอา SVN มาใช้คำนวณ Man Hour ได้ด้วย โดยดูจากอายุของตัวลิโพ และปริมาณการคอมมิทที่เกิดขึ้น โดยการกดปุ่ม Statistics
  
  
  
• ลบ/เปลี่ยนชื่อโฟลเดอร์
  การลบหรือเปลี่ยนชื่อโฟลเดอร์ ผมแนะนำว่า ควรจะใช้ RepoBrowser เพราะว่าเชื่อถือได้มากกว่า การทำจากใน Explorer ครับ หลังจากทำเสร็จแล้ว ก็แค่สั่ง Update เพื่อปรับให้ตรงกับใน SVN
  
• เปลี่ยนใจ
  บางที เราแก้อะไรไปแล้ว แล้วเกิดเปลี่ยนใจ ไม่อยากจะเก็บไว้แล้ว ก็สามารถทำได้ โดยใช้คำสั่ง Revert ครับ
  
• Tag
  เมื่องานสำเร็จลุล่วงตามเป้าหมายที่วางไว้ อย่างพวก Milestone หรือ Build เราก็สามารถ Backup เก็บไว้ได้ครับ เกิดวันหน้าวันหลัง ทำอะไรพังขึ้นมา อย่างน้อย ก็ยัง ย้อนเวลากลับมาเอาของเดิมได้ เราเรียกการ Backup นี้ว่า Tag ครับ
  
  การ Tag สามารถทำได้จากหน้า RepoBrowser ครับ (หรือจะเลือก Click ขวาแล้ว Branch/Tag ก็ได้ แต่ผมไม่แนะนำ) ซึ่งจริงๆ แล้วก็ไม่ได้มีขึ้นตอนยุ่งยากอะไร มันคือการ Copy Trunk ไปเก็บไว้นั่นเอง ซึ่งทำได้โดยการ Click ขวาที่ trunk เลือก Copy To.. แล้วใส่ URL ว่า file:///E:/Repositories/TestProject/tags/M1 โดย M1 จะเป็นอะไรก็ได้ครับ มันก็คือ Folder ธรรมดานั่นเอง อย่าลืมใส่ Log ไว้ด้วยละว่า เรา Tag เพราะอะไร
  
  

ส่งท้าย

สำหรับการใช้งาน SVN ในขั้นต้น คงจะมีเท่านี้ครับ แต่ยังมีอีกหลายเรื่องมากมาย ที่ผมไม่ได้พูดถึงในโพสนี้ เช่น

• แก้ Conflict เวลาคนใช้พร้อมกันหลายคน
• Branch
• Merge Revision, Branch
• การ Backup ลิโพ

อ่านต่อได้จากภาคสอง ที่ http://coresharp.net/blogs/article/archive/2009/03/08/source-control-2.aspx