>>เล่าประสบการณ์การย้าย source code จาก SVN มา Git

เล่าประสบการณ์การย้าย source code จาก SVN มา Git

By | 2018-06-24T16:17:20+00:00 June 24th, 2018|Story|0 Comments

เกริ่นนำ

ผมได้มีโอกาศทำงานบริษัทญี่ปุ่นกับทีมญี่ปุ่น โปรเจ็คที่ทำอยู่อายุกว่า 10 ปีแล้ว  และตัวโปรเจ็คเองก็ใช้ svn เป็น source control และก็ยังใช้มาเรื่อยๆ ซึ่งตัวโปรเจ็คก็มีขนาดที่ใหญ่พอสมควรซึ่งใหญ่จนบ่นว่าช้าได้ก็คงต้องบอกละว่าเป็นเกม เพราะเก็บทั้ง code และ resource  หากใครเคยใช้ svn กับโปรเจ็คใหญ่ๆจะรู้ว่ามันช้ามาก เพราะมันต้องดึงข้อมูลมาใหม่ทุกครั้งที่เรียกใช้คำสั่งใน svn  แตกต่างจาก git ที่ clone โปรเจ็คลงเครื่องเราก่อนที่จะ checkout ได้

ซึ่งทางทีมญี่ปุ่นเองเขาก็ host เจ้า svn repositories บนเครื่อง server  ในออฟิศเองนั่นแหละ  ต่อมาทางทีมไทยก็มีเข้าไปศึกษาและเพิ่ม feature ในเกมบ้าง ซึ่งเวลาทำงานก็จะช้าพอสมควร (ไม่ได้อยู่ในวง local ด้วยนี่นา)

แล้วพอมาวันหนึ่ง ทีมทางญี่ปุ่นก็เหมือนจะต้องไปพัฒนาโปรเจ็คตัวใหม่  และฝากฝั่งการเมนเทนและพัฒนาไว้กับทีมไทย…

ทางญี่ปุ่นส่ง Hard Disk ที่ก็อปปี้ SVN repositories มาให้ เอามาให้เรา host เองในออฟิศเพื่อแก้ปัญหาเรื่องความช้าในการ commit งานหรือ checkout งานต่างๆใน SVN

ซึ่งมันก็เร็วขึ้นแหละครับ  แต่มันก็ยังแบบว่าช้ากว่าการที่เราใช้ Git อยู่พอสมควร

ถึงเวลาที่จะต้องสังคายนา Source Control

ไม่ไหวละ มันช้าาาาาาาาา ถึงช้ามาาาาาากกกก  เราก็มีการพูดคุยกันว่าย้ายมาใช้ Git กันเถอะ มันเร็วกว่าเยอะเลยนะ  ทางเบื่องบนก็เห็นว่าไม่ดีมั้ง history ของ svn ที่ทำกว่า 10 ปีมันจะหายไป ถ้าจะมาตัดขึ้น Git

เราก็ทำการค้นคว้าเล็กๆพบว่า Git เองมีคำสั่ง built-in ในการแปลง SVN ให้มาเป็น Git

เอาล่ะ ฟังดูดีทีเดียว

 

ปัญหาต่อไป…  เอ้าใครจะทำดี? นั่งๆคุยกันอยู่นี่ก็เป็น Programmer ที่เน้นเขียน code ไม่ใช่บริษัทใหญ่ๆ ที่มีตำแหน่ง DevOps หรือ System Admin อะไรแบบนั้น

แน่นอนว่าการที่ผมได้มาเขียน post นี้หมายความว่าผมได้เป็นคนทำแน่ๆ

ก่อนที่จะไปถึงขั้นตอนแปลง SVN มาเป็น Git  มาพูดถึงขั้นตอนเลือก Git repositories manager software ที่จะเอามาใช้ก่อนละกัน

ตอนที่ทำการเปรียบเทียบระบบต่างๆ ตัวที่เข้ารอบมีอยู่ 2 ตัว นั่นคือ

ซึ่งทั้งสองมีเวอร์ชั่น Community Edition (CE) สำหรับการใช้นำมา host เองฟรีทั้งคู่แต่โดนจำกัดบางความสามารถ

และที่สำคัญรองรับการใช้งาน Git – Large File Storage (LFS) ทั้งคู่

สุดท้ายตัวที่เลือกมาก็คือ GitLab ซึ่งเอกสารอะไรก็เยอะกว่าพอสมควร  เป็นที่นิยมรองลงมาจาก GitHub เลยละมั้ง…

ปัญหาต่อไปของ Windows User

GitLab หรือ software ประเภทเดียว ส่วนใหญ่จะติดตั้งได้บนเฉพาะ Unix ซึ่งผมไม่เคยใช้มาก่อนเลย…

เราเลือกใช้ VirtualBox เป็น Virtual Machine Software ครับ  ลงและใช้งานมันบน Windows Server ที่ใช้นี่แหละ

และเราเลือก Ubuntu Server  พอลงเสร็จมันก็มีมาแต่ Terminal ง่อยๆ(ครับ ผมรู้ครับว่าบางคนอ่านแล้วบอกว่า ง่อยอะไร นี่แหละสุดยอดของความ Powerful แล้ว) ไม่มี UI อะไรมาให้ใช้งานเลย

ก็ลองเล่นกับคำสั่งทำความคุ้นเคยกับโครงสร้างและคำสั่งต่างๆบน Ubuntu อยู่พักนึ่งก่อนจะลง GitLab  ต้องบอกเลยว่า แทบจะจับจอคอมทุ่มเพราะบางทีมันหงุดหงิดกับความไม่รู้เลยความไม่เคยชินกับการใช้แต่ Command Line บน Unix เลยจริง

พอเสร็จแล้ว อู้วววว ระบบสุดยอด และ UI มันสวยงามอะไรขนาดนนี้

 

ก็ลองสร้างโปรเจ็คทดสอบการใช้งานทั้งแบบปกติและแบบใช้ LFS

เอาว่ะ ผ่านๆๆ เตรียมขั้นตอนต่อไป

ถึงเวลาแปลง SVN ให้มาเป็น Git

พร้อมแล้ว Enter !!!

git svn clone --stdlayout --no-metadata -A ~/authors.txt http://svn/repo/bigproject

นั่งรอมันไป 2 วันกว่าๆครับ กว่ามันจะแปลงเสร็จ แล้วขนาด Git repository ที่ได้มานั่นใหญ่ถึง 30GB กันเลยทีเดียว รวมกับตัวโปรเจ็คด้วยแล้ว 45GB+  โอ้วว

เสร็จแล้วก็ใส่ .gitattributes ที่เตรียมเอาไว้เพื่อบอกว่าจะให้พวก Resources (png, fbx, ogg, อื่นๆ) ไปเก็บแยกเป็น LFS นะ

เสร็จแล้วก็ Push สิ รออะไร

 

หลังจากที่ Push ไปประมาณ 3 ชั่วโมงกว่าๆ  ใน Command Line โชว์ว่า “Bad Gateway”

ไปจ้องในจอ Terminal ในฝั่งเซิร์ฟเวอร์มันบอกว่า RAM หมดขอตัดโปรเซสนี้ทิ้งนะ

อะไม่เป็นไรเพิ่ม RAM ให้อีกเป็น 8 GB ก็ยังไม่พอ เพิ่มไป 20GB ถึงจะพอ

 

เอาล่ะ ในที่สุดก็ได้แล้ว แต่ทว่า…

ทำการบ้านมาไม่ดีพอ

ลอง Clone ดูปรากฎว่า มันก็มาทั้งยวงแบบเดิมไม่ได้ แยกเป็น LFS แต่อย่างใด

เหตุผลก็คือมันต้องใช้อีกคำสั่งแปลงจากการเก็บแบบปกติให้มาเป็นเก็บแบบ LFS ก่อน จะมาใส่ลงใน .gitattributes แบบการสร้างโปรเจ็คครั้งแรกเลยไม่ได้

git lfs migrate import --include="*.png, *.fbx, *.ogg" --include-ref=refs/heads/master --include-ref=refs/heads/branch-1

ขั้นตอนนี้กินเวลาไปอีก… 1 วัน

บทสรุป

ในที่สุดก็เสร็จละ พร้อม Push จริงๆสักที  และคราวนี้ RAM Usage ของเครื่องเซิร์ฟเวอร์พีคไปที่แค่ประมาณ 8GB กว่าๆเท่านั้น เป็นเพราะพวก LFS objects นั้นถูกอัพโหลดขึ้นไปเก็บแยกจาก Git Repository โดยสิ้นเชิง และไม่ต้องมานั่งบีบอัดไฟล์รวมไปกับ Git Objects

ตัว .git เหลือแค่ 18GB ที่เหลือเป็น LFS Objects อีกกว่า 50GB…

แต่ในทางใช้งานจริงเครื่องที่จะ clone ก็จะได้ไฟล์มาทั้งหมด 38GB (จาก 45GB) และที่สำคัญ เร็วมากกกกกกกกกกกกกก ใช้เวลา clone แค่ 30-35 นาที เท่านั้น!!!

 

เสริมความมั่นใจในการเก็บข้อมูลโดยการอัพโหลดไปเก็บที่อื่นด้วย

ตัว GitLab เองมีความสามารถในการส่งข้อมูลไปเก็บที่ Cloud Storage ด้วยในตัว  แต่ว่าเรามีแต่ Dropbox ซึ่ง GitLab ไม่ซัพพอร์ทโดยตรง ไม่เป็นไรไม่ใช่ปัญหาอะไรมาก เราก็ใช้คำสั่งก็อปปี้ไปวางเองดื้อๆเลย ไม่มีอะไรซับซ้อนมาก

 

ทั้งหมดนี้กินเวลาทั้งทำการเรียนรู้และติดตั้งใช้งานเสียเวลาไป 1 อาทิตย์เต็ม