Source Code Control (Version Control System)
Wed 27 October 2010
Software Development လုပ်တဲ့အချိန်မှာ အရေးကြီးတဲ့အချက်တစ်ခုဟာ ရေးနေတဲ့ Sorce Code များကိုထိမ်းသိမ်းရခြင်း ဖြစ်ပါတယ်။ ရေးသားတဲ့နေရာမှာ အမြဲပြုလုပ်ရလေ့ရှိတာက မူရင်းရေးပြီးသား Sorce Code များကိုအကြောင်းအမျိုးအမျိုးကြောင့် ပြင်ပြီးစမ်းရတတ်ပါတယ်။ အဲဒီလိုပြုလုပ်ရင်း မကောင်း၍သော်လည်းကောင်း မူရင်းကိုပြန်လိုချင်၍သော်လည်းကောင်း တစ်ခါတစ်ရံမှာခက်ခဲ့တတ်ပါတယ်။ ဒီနေရာမှာ Source Code Control (Version Control System) တွေဟာ အများကြီးအရေးပါလာပါတယ်။
ဒီလိုအရာတွေကို ပုံမှန်အားဖြင့်ရှင်းလေ့ရှိတာက စမ်းသပ်မှု့ပြင်ဆင်မှု့မလုပ်ခင်မှာ backup လုပ်ပြီးစမ်းသပ်ပြင်ရပါတယ် မူရင်းပြန်လိုချင်တယ်ြဖစ်လာရင်တော့ backup လုပ်ထားတာကို ပြန်သုံးလို့ရပါတယ်။ နောက်ပြီးတော့ backup လုပ်ရာမှာလည်း ဖိုင်တွေကို Version သော်လည်းကောင်း နေ့စွဲအချိန်လိုသော်လည်းကောင်း ထည့်ပြီးမှတ်ထားမယ်ဆိုရင် ထိမ်းသိမ်းရလွယ်ပါတယ်။ backup လုပ်ထားတဲ့ ဖိုင်တွေကိုလည်း အားလုံးအတွက် တစ်နေရာတည်းမှာထားပြီး shared directory အဖြစ်ဆိုရင်အားလုံး အသုံးပြုရလွယ်ကူပါတယ်။ ဒါတွေဟာ Source Code Control ရဲ့အခြေခံအချက်တွေပါ။
Version Control System တွေကိုဘာလို့ အသုံးပြုရတယ်ဆိုတဲ့ အချက်တွေဟာလည်း အရေးကြီးပါတယ်။ shared directory တွေမှာက ပရောဂျက်တစ်ခုအတွက်နဲ့ ပရိုဂရမ်မာနည်းရင် ညှိနှိုင်းသုံးစွဲလို့ရပေမယ့် များလာရင်တော့ Version Control အင်မတန်ရှုပ်ထွေးလာပါတယ် နောက်ပြီးတော့ အများသုံးစွဲတာဖြစ်လို့ မူရင်းထားတဲ့ shared directory မှာပဲ တိုက်ရိုက်ပြုပြင်ဖို့ကြိုးစားရင် တစ်ခုတည်းကို တစ်ချိန်တည်းမှာပဲ လူအများဝိုင်းပြင်မိတာတွေ ဖြစ်လာနိုင်ပြီးတော့ ပြဿနာများစွာ ရှုပ်ထွေးလာမှာဖြစ်ပါတယ်။ နောက်တစ်ချက်က လူအများအသုံးပြုတာဖြစ်လို့ မိမိရေးသားထားတဲ့ Soruce Code များနဲ့အတူ ပြုလုပ်ခဲ့အတဲ့ အပြောင်းအလဲများကို မှတ်တမ်းတင်ဖို့လည်း လိုအပ်ပါတယ် ဒီနေရာမှာ shared directory တွေဟာ Soruce Code ရဲ့အတွင်းမှာပဲ Comment များရေးသားရုံကလွဲပြီး မထောက်ပံ့ပေးနိုင်တော့ပါဘူး။
Shared directory တွေမှာဖြစ်နိုင်တဲ့ အခက်အခဲပြဿနာကို အောက်မှာပုံအဖြစ်နဲ့ပြထားပါတယ်။ ပုံမှာ လူနှစ်ယောက်ဟာ ဖိုင်တစ်ခုကို တစ်ပြိုင်တည်းဖတ်ပြီး ပြုပြင်ကြပါတယ် ဒီနေရာမှာ တစ်ယောက်ပြင်ထားတဲ့ ဖိုင်တစ်ခုကို နောက်တစ်ယောက်က မူရင်းဖိုင်ထင်တဲ့အတွက် ထပ်ရေးတဲ့အတွက်အခက်အခဲဖြစ်နိုင်ပါတယ်။
အလွယ်ဆုံးဖြေရှင်းနည်းကတော့ အသုံးပြုသူတစ်ယောက်အနေနဲ့ ပြုပြင်လိုခဲ့ပါက Lock ချတဲ့နည်းနဲ့ ဖြေရှင်းလေ့ရှိပါတယ် အချို့သော Operating System များမှာလည်း Shared file တွေကို Lock ချပေးထားနိုင်ပါတယ်။ သရုပ်ပြပုံကိုအောက်မှာ ကြည့်ရှု့နိုင်ပါတယ်။ Lock ကိုသုံးချင်းအားဖြင့် သာမန်အနေအထားအတိုင်း Shared လုပ်ရင်ြဖစ်လေ့ရှိတဲ့ နှစ်ယောက်ပြိုင်ရေးတဲ့ ပျောက်ဆုံးတာမျိုးမဖြစ်နိုင်တော့ပါဘူး။ ဒါပေမယ့်လည်း Lock လုပ်တဲ့အတွက် ဖြစ်လာနိုင်တာက Lock ပေးနိုင်ဖို့ သက်ဆိုင်တဲ့ System တစ်ခုလိုအပ်လာပါတယ်။ တစ်ခါတစ်ရံမှာ တူညီတဲ့ ဖိုင်တစ်ခုဖြစ်ပေမယ့် မတူညီတဲ့နေရာတွေကို နှစ်ဦးပြင်ဆင်လိုခဲ့ပါက Lock ဟာခွင့်ပြုပေးလို့မရတဲ့အတွက် အခြားပြင်ဆင်လိုသူတစ်ဦးဟာ စောင့်ဆိုင်းရမှာဖြစ်ပါတယ်။
Version Control System(VCS) တွေမှာတော့ အောက်မှာဖော်ပြထားတဲ့ ပုံမှာပြထားတဲ့အတိုင်း အထက်ပါအခက်အခဲတွေကိ ဖြေရှင်းလေ့ရှိပါတယ်။ ဖြေရှင်းပုံကိုတော့ Copy-Modify-Merge လို့ခေါ်လေ့ရှိပါတယ်။ သာမန် Shared directory တွေအတိုင်း လူအများအနေနဲ့ ကူးယူပြီးတော့ ပြင်ဆင်နိုင်ပါတယ်။ VCS အနေနဲ့ မည်သူကမည်သည့် Version ကို ကူးယူသွားတယ်ဆိုတာ မှတ်သားထားလိုက်ပြီး Repository ထဲမှာမူရင်း Version ရှိမှသာပြင်ဆင်ခွင့်ပေးပါတယ် အကယ်၍သာ အခြားလူတစ်ဦးက ဝင်ရောက်ပြင်ဆင်သွားပါက ပြင်ဆင်ခွင့်မပေးတော့ပဲ Version ပြောင်းသွားကြောင်း အကြောင်းကြားပြီး ပြောင်းလဲသွားတဲ့ Version ကိုထပ်မံဖတ်ရှု့စေပြီး ထပ်မံပြင်ဆင်စေမှာဖြစ်ပါတယ်။ ဒီနည်းအားဖြင့် Shared directory ရဲ့အခက်အခဲကို ပြေလည်စေပြီး Lock မလိုအပ်ပဲ တစ်ပြိုင်နည်း လူအများပြင်ဆင်နိုင်စေမှာ ဖြစ်ပါတယ်။ Lock မလိုအပ်ဘူးဆိုပေမယ့် ချို့ယွင်းချက်အနေနဲ့ လိုအပ်နိုင်တဲ့ အခြေအနေတွေလည်း ဖြစ်လာနိုင်ပါသေးတယ်။
VCS တွေမှာအများအားဖြင့် အောက်မှာဖော်ပြထားတဲ့ အချက်များကို အထောက်အကူပြုလေ့ရှိပါတယ်။
(၁) Backup and Restore: သက်ဆိုင်ရာဆော့ဝဲ Soruce Code များကို Backup and Restore လုပ်ပေးနိုင်ရပါမယ် Backup and Restore ဆိုရာမှာ အချိန်အလိုက်လုပ်ဆောင်ပေးနိုင်ရပါမယ် ဒီအချက်ဟာတော့ shared directory မှာလည်း လုပ်ပေးနိုင်တာဖြစ်တာကြောင့် ထူးခြားတယ်မဆိုနိုင်ပါဘူး ဒါပေမယ့် VCS မှာတစ်ခါတည်း ပါလာတဲ့အတွက် Backup and Restore ပိုမိုလွယ်ကူနိုင်ပါတယ်။
(၂) Synchronization: ပုံမှန်အားဖြင့် Soruce Code များဟာ တစ်နေရာတည်းမှာ ထိမ်းသိမ်းထားတာဖြစ်ပြီး ပြင်ဆင်လိုတယ်ဆိုပါက မိမိရဲ့ကိုယ်ပိုင် စက်အတွင်းကို ကူးယူပြီးမှသာပြင်ဆင်လို့ရပါတယ် ပြင်ဆင်ပြီးလျင်တော့ မူရင်းထိမ်းသိမ်းတဲ့နေရာကို ပြန်လည်ပို့ပြီး အပြောင်းအလဲများကို မှတ်တမ်းတင်ရပါတယ်။ လူအများတစ်ပြိုင်တည်း ပြင်ဆင်နေတာ ဖြစ်တဲ့အတွက် မိမိယူထားတဲ့ Soruce Code များဟာ နောက်ဆုံးအပြောင်းအလဲကို လိုကောင်းလိုမှာ ဖြစ်လာနိုင်ပါတယ် VCS များမှာတော့ Synchronization ကိုလုပ်ပေးနိုင်စွမ်း ပါလေ့ရှိတာကြောင့် Synchronization ဟာ လူကိုယ်တိုင်လုပ်စရာမလိုအပ်ပါဘူး။
(၃) Undo: မိမိပြင်ဆင်လိုတဲ့ Soruce Code တွေကိုကူးယူပြင်ဆင်ပြီးမှ မူရင်းအခြေအနေ ပြန်လိုချင်ခဲ့လျင် လိုအပ်တဲ့ နောက်ဆုံးအခြေအနေကို အလွယ်တကူပြန်လည်ရရှိနိုင်ပါတယ်။ အများအားဖြင့် မိမိတိုပြန်လည်ရောက်ရှိချင်တဲ့ Version or Revision အခြေအနေကို ပြန်လည်ကူးပြောင်းလို့ရပါတယ်။
(၄) Track Changes: မိမိတို့ပြင်ဆင်လိုက်တဲ့ အကြောင်းအရာတွေကို မှတ်ချက်များရေးသား ပြင်ဆင်ချင်တယ်ဆိုရင် ပြောင်းလဲတဲ့အကြိမ်တိုင်းမှာ မိမိတို့မှတ်သားလိုတဲ့ ပြောင်းလဲချက်များကို ရေးသားထိမ်းသိမ်းလို့ရပါတယ်။ ဒီအချက်တွေဟာ မိမိတို့ရဲ့ဆော့ဝဲမှာ ဘယ်လိုအပြောင်းအလဲတွေ ရှိခဲ့တယ်ဆိုတာတွေကို လိုအပ်လာပါကပြန်လည် စီစစ်ရာမှာ အသုံးပြုကြပါတယ်။
(၅) Track Ownership: လူအများနဲ့ အလုပ်လုပ်တာ ဖြစ်တဲ့အတွက် ပြုလုပ်သွားတဲ့ အပြောင်းအလဲတွေကို ပြန်လည်စီစစ်နိုင်ဖို့လိုပါတယ်။ VCS တွေမှာ Track Changes တွေအပေါ်မှာ ဘယ်သူကဘယ်လို ပြောင်းလဲသွားတယ်ဆိုတာကို ပြန်လည်ပြီးတော့ စီစစ်နိုင်အောင် မှတ်သားထားပေးနိုင်ပါတယ်။ တစ်ချိန်မှာပြဿနာရှိလာရင် မည်သူပြောင်းလဲသွားလို့ ဖြစ်ရတယ်ဆိုတာမျိုး ပြန်လည်ရှာဖွေပေးနိုင်ပါတယ်။
(၆) Sandboxing: မူရင်း Soruce Code များကို ပြင်ဆင်လိုပါက VCS ထံကနေ မိမိတို့ထံကိုကူးယူပြီးတော့ ပြင်ဆင်စမ်းသပ်တာ ဖြစ်တဲ့အတွက် စမ်းသပ်မှု့တွေ ပြင်ဆင်မှု့တွေပြီးတဲ့ အချိန်မှသာ VCS ထဲကို ပြောင်းလဲမှု့ပြုလုပ်တဲ့အတွက် မူရင်း VCS ကိုထိခိုက်စေမှု့မရှိပါဘူး။ ဒီနေရာမှာ VCS ဟာ File Server မဟုတ်ဘူးဆိုတာ ဆိုလိုပါတယ် မိမိတို့ပြင်ချင်သလောက်ပြင် VCS ထဲကိုပို့ဆိုတာမျိုးမလုပ်သင့်ပါဘူး အတိုင်းအတာတစ်ခုအထိ ပြုပြင်ပြီးမှသာ VCS ထဲကိုပြောင်းလဲရပါတယ် ဒါမှသာ Revision တစ်ခုနဲ့တစ်ခု ဘယ်လောက်ကွာခြားတယ်ဆိုတဲ့ Track Changes များဟာအသုံးဝင်မှာဖြစ်ပါတယ်။
(၇) Branching and merging: အပေါ်မှာပြောခဲ့တဲ့ Sandboxing ဟာကိုယ်ကူးယူထားတဲ့ Source code များကိုစိုက်ကြိုက် စမ်းသပ်မှု့ဖြစ်ပါတယ် အကယ်၍သာ အဲဒီ့စမ်းသပ်မှု့များမှာလည်း အဆင့်တွေများနိုင်သလို Track Changes တွေကိုလည်း မူရင်း VCS လိုလိုချင်တယ်ဆိုရင် VCS မှာပဲ စမ်းသပ်ဖို့အတွက် Branching အဖြစ်ခွဲထုတ်ပြီး အသုံးပြုနိုင်ပါတယ်။ Branch တစ်ခုစမ်းသပ်ပြီးလို့ မူရင်းထဲကို ပြောင်းလဲမှု့တွေကို ပေါင်းထည့်တာကိုတော့ VCS မှာ merging လုပ်တယ်လို့ ခေါ်လေ့ရှိပါတယ်။
( VCS များမှအခေါ်အဝေါ်များ၊ SVN ဖြင့်သရုပ်ပြ၍ ပုံနှင့်ပြထားခြင်းများ ဆက်ရန် )
အောက်ဖော်ပြပါ References များမှဖတ်ပြီး အဆင်ပြေသလို ရေးထားခြင်းဖြစ်သည် မူရင်းနှင့်လွဲနိုင်ပါသည် စိတ်ဝင်စားလျှင်သွားဖတ်ပါ စာရင်းများအောက်တွင်ပြထားသည်။
References
[1] http://betterexplained.com/articles/a-visual-guide-to-version-control/
[2] http://svnbook.red-bean.com/en/1.5/index.html
[3] http://www.dwheeler.com/essays/scm.html
[4] http://en.wikipedia.org/wiki/Version_control
[5] http://en.wikipedia.org/wiki/Versioning_file_system
[6] http://www.ericsink.com/scm/source_control.html
[7] http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
[8] http://better-scm.berlios.de/comparison/
အလွယ်ဆုံးဖြေရှင်းနည်းကတော့ အသုံးပြုသူတစ်ယောက်အနေနဲ့ ပြုပြင်လိုခဲ့ပါက Lock ချတဲ့နည်းနဲ့ ဖြေရှင်းလေ့ရှိပါတယ် အချို့သော Operating System များမှာလည်း Shared file တွေကို Lock ချပေးထားနိုင်ပါတယ်။ သရုပ်ပြပုံကိုအောက်မှာ ကြည့်ရှု့နိုင်ပါတယ်။ Lock ကိုသုံးချင်းအားဖြင့် သာမန်အနေအထားအတိုင်း Shared လုပ်ရင်ြဖစ်လေ့ရှိတဲ့ နှစ်ယောက်ပြိုင်ရေးတဲ့ ပျောက်ဆုံးတာမျိုးမဖြစ်နိုင်တော့ပါဘူး။ ဒါပေမယ့်လည်း Lock လုပ်တဲ့အတွက် ဖြစ်လာနိုင်တာက Lock ပေးနိုင်ဖို့ သက်ဆိုင်တဲ့ System တစ်ခုလိုအပ်လာပါတယ်။ တစ်ခါတစ်ရံမှာ တူညီတဲ့ ဖိုင်တစ်ခုဖြစ်ပေမယ့် မတူညီတဲ့နေရာတွေကို နှစ်ဦးပြင်ဆင်လိုခဲ့ပါက Lock ဟာခွင့်ပြုပေးလို့မရတဲ့အတွက် အခြားပြင်ဆင်လိုသူတစ်ဦးဟာ စောင့်ဆိုင်းရမှာဖြစ်ပါတယ်။
Version Control System(VCS) တွေမှာတော့ အောက်မှာဖော်ပြထားတဲ့ ပုံမှာပြထားတဲ့အတိုင်း အထက်ပါအခက်အခဲတွေကိ ဖြေရှင်းလေ့ရှိပါတယ်။ ဖြေရှင်းပုံကိုတော့ Copy-Modify-Merge လို့ခေါ်လေ့ရှိပါတယ်။ သာမန် Shared directory တွေအတိုင်း လူအများအနေနဲ့ ကူးယူပြီးတော့ ပြင်ဆင်နိုင်ပါတယ်။ VCS အနေနဲ့ မည်သူကမည်သည့် Version ကို ကူးယူသွားတယ်ဆိုတာ မှတ်သားထားလိုက်ပြီး Repository ထဲမှာမူရင်း Version ရှိမှသာပြင်ဆင်ခွင့်ပေးပါတယ် အကယ်၍သာ အခြားလူတစ်ဦးက ဝင်ရောက်ပြင်ဆင်သွားပါက ပြင်ဆင်ခွင့်မပေးတော့ပဲ Version ပြောင်းသွားကြောင်း အကြောင်းကြားပြီး ပြောင်းလဲသွားတဲ့ Version ကိုထပ်မံဖတ်ရှု့စေပြီး ထပ်မံပြင်ဆင်စေမှာဖြစ်ပါတယ်။ ဒီနည်းအားဖြင့် Shared directory ရဲ့အခက်အခဲကို ပြေလည်စေပြီး Lock မလိုအပ်ပဲ တစ်ပြိုင်နည်း လူအများပြင်ဆင်နိုင်စေမှာ ဖြစ်ပါတယ်။ Lock မလိုအပ်ဘူးဆိုပေမယ့် ချို့ယွင်းချက်အနေနဲ့ လိုအပ်နိုင်တဲ့ အခြေအနေတွေလည်း ဖြစ်လာနိုင်ပါသေးတယ်။
VCS တွေမှာအများအားဖြင့် အောက်မှာဖော်ပြထားတဲ့ အချက်များကို အထောက်အကူပြုလေ့ရှိပါတယ်။
(၁) Backup and Restore: သက်ဆိုင်ရာဆော့ဝဲ Soruce Code များကို Backup and Restore လုပ်ပေးနိုင်ရပါမယ် Backup and Restore ဆိုရာမှာ အချိန်အလိုက်လုပ်ဆောင်ပေးနိုင်ရပါမယ် ဒီအချက်ဟာတော့ shared directory မှာလည်း လုပ်ပေးနိုင်တာဖြစ်တာကြောင့် ထူးခြားတယ်မဆိုနိုင်ပါဘူး ဒါပေမယ့် VCS မှာတစ်ခါတည်း ပါလာတဲ့အတွက် Backup and Restore ပိုမိုလွယ်ကူနိုင်ပါတယ်။
(၂) Synchronization: ပုံမှန်အားဖြင့် Soruce Code များဟာ တစ်နေရာတည်းမှာ ထိမ်းသိမ်းထားတာဖြစ်ပြီး ပြင်ဆင်လိုတယ်ဆိုပါက မိမိရဲ့ကိုယ်ပိုင် စက်အတွင်းကို ကူးယူပြီးမှသာပြင်ဆင်လို့ရပါတယ် ပြင်ဆင်ပြီးလျင်တော့ မူရင်းထိမ်းသိမ်းတဲ့နေရာကို ပြန်လည်ပို့ပြီး အပြောင်းအလဲများကို မှတ်တမ်းတင်ရပါတယ်။ လူအများတစ်ပြိုင်တည်း ပြင်ဆင်နေတာ ဖြစ်တဲ့အတွက် မိမိယူထားတဲ့ Soruce Code များဟာ နောက်ဆုံးအပြောင်းအလဲကို လိုကောင်းလိုမှာ ဖြစ်လာနိုင်ပါတယ် VCS များမှာတော့ Synchronization ကိုလုပ်ပေးနိုင်စွမ်း ပါလေ့ရှိတာကြောင့် Synchronization ဟာ လူကိုယ်တိုင်လုပ်စရာမလိုအပ်ပါဘူး။
(၃) Undo: မိမိပြင်ဆင်လိုတဲ့ Soruce Code တွေကိုကူးယူပြင်ဆင်ပြီးမှ မူရင်းအခြေအနေ ပြန်လိုချင်ခဲ့လျင် လိုအပ်တဲ့ နောက်ဆုံးအခြေအနေကို အလွယ်တကူပြန်လည်ရရှိနိုင်ပါတယ်။ အများအားဖြင့် မိမိတိုပြန်လည်ရောက်ရှိချင်တဲ့ Version or Revision အခြေအနေကို ပြန်လည်ကူးပြောင်းလို့ရပါတယ်။
(၄) Track Changes: မိမိတို့ပြင်ဆင်လိုက်တဲ့ အကြောင်းအရာတွေကို မှတ်ချက်များရေးသား ပြင်ဆင်ချင်တယ်ဆိုရင် ပြောင်းလဲတဲ့အကြိမ်တိုင်းမှာ မိမိတို့မှတ်သားလိုတဲ့ ပြောင်းလဲချက်များကို ရေးသားထိမ်းသိမ်းလို့ရပါတယ်။ ဒီအချက်တွေဟာ မိမိတို့ရဲ့ဆော့ဝဲမှာ ဘယ်လိုအပြောင်းအလဲတွေ ရှိခဲ့တယ်ဆိုတာတွေကို လိုအပ်လာပါကပြန်လည် စီစစ်ရာမှာ အသုံးပြုကြပါတယ်။
(၅) Track Ownership: လူအများနဲ့ အလုပ်လုပ်တာ ဖြစ်တဲ့အတွက် ပြုလုပ်သွားတဲ့ အပြောင်းအလဲတွေကို ပြန်လည်စီစစ်နိုင်ဖို့လိုပါတယ်။ VCS တွေမှာ Track Changes တွေအပေါ်မှာ ဘယ်သူကဘယ်လို ပြောင်းလဲသွားတယ်ဆိုတာကို ပြန်လည်ပြီးတော့ စီစစ်နိုင်အောင် မှတ်သားထားပေးနိုင်ပါတယ်။ တစ်ချိန်မှာပြဿနာရှိလာရင် မည်သူပြောင်းလဲသွားလို့ ဖြစ်ရတယ်ဆိုတာမျိုး ပြန်လည်ရှာဖွေပေးနိုင်ပါတယ်။
(၆) Sandboxing: မူရင်း Soruce Code များကို ပြင်ဆင်လိုပါက VCS ထံကနေ မိမိတို့ထံကိုကူးယူပြီးတော့ ပြင်ဆင်စမ်းသပ်တာ ဖြစ်တဲ့အတွက် စမ်းသပ်မှု့တွေ ပြင်ဆင်မှု့တွေပြီးတဲ့ အချိန်မှသာ VCS ထဲကို ပြောင်းလဲမှု့ပြုလုပ်တဲ့အတွက် မူရင်း VCS ကိုထိခိုက်စေမှု့မရှိပါဘူး။ ဒီနေရာမှာ VCS ဟာ File Server မဟုတ်ဘူးဆိုတာ ဆိုလိုပါတယ် မိမိတို့ပြင်ချင်သလောက်ပြင် VCS ထဲကိုပို့ဆိုတာမျိုးမလုပ်သင့်ပါဘူး အတိုင်းအတာတစ်ခုအထိ ပြုပြင်ပြီးမှသာ VCS ထဲကိုပြောင်းလဲရပါတယ် ဒါမှသာ Revision တစ်ခုနဲ့တစ်ခု ဘယ်လောက်ကွာခြားတယ်ဆိုတဲ့ Track Changes များဟာအသုံးဝင်မှာဖြစ်ပါတယ်။
(၇) Branching and merging: အပေါ်မှာပြောခဲ့တဲ့ Sandboxing ဟာကိုယ်ကူးယူထားတဲ့ Source code များကိုစိုက်ကြိုက် စမ်းသပ်မှု့ဖြစ်ပါတယ် အကယ်၍သာ အဲဒီ့စမ်းသပ်မှု့များမှာလည်း အဆင့်တွေများနိုင်သလို Track Changes တွေကိုလည်း မူရင်း VCS လိုလိုချင်တယ်ဆိုရင် VCS မှာပဲ စမ်းသပ်ဖို့အတွက် Branching အဖြစ်ခွဲထုတ်ပြီး အသုံးပြုနိုင်ပါတယ်။ Branch တစ်ခုစမ်းသပ်ပြီးလို့ မူရင်းထဲကို ပြောင်းလဲမှု့တွေကို ပေါင်းထည့်တာကိုတော့ VCS မှာ merging လုပ်တယ်လို့ ခေါ်လေ့ရှိပါတယ်။
( VCS များမှအခေါ်အဝေါ်များ၊ SVN ဖြင့်သရုပ်ပြ၍ ပုံနှင့်ပြထားခြင်းများ ဆက်ရန် )
အောက်ဖော်ပြပါ References များမှဖတ်ပြီး အဆင်ပြေသလို ရေးထားခြင်းဖြစ်သည် မူရင်းနှင့်လွဲနိုင်ပါသည် စိတ်ဝင်စားလျှင်သွားဖတ်ပါ စာရင်းများအောက်တွင်ပြထားသည်။
References
[1] http://betterexplained.com/articles/a-visual-guide-to-version-control/
[2] http://svnbook.red-bean.com/en/1.5/index.html
[3] http://www.dwheeler.com/essays/scm.html
[4] http://en.wikipedia.org/wiki/Version_control
[5] http://en.wikipedia.org/wiki/Versioning_file_system
[6] http://www.ericsink.com/scm/source_control.html
[7] http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
[8] http://better-scm.berlios.de/comparison/