آشنایی با Subversion بخش هفتم(1408 مجموع کلمات موجود در متن) (6977 بار مطالعه شده است)  آشنایی
با Subversion
بخش
هفتم
بروز
کردن نسخه کاری
همانطور
که ذکر شد چون شما تنها کاربر موجود در
پروژه نیستید، هــر لحظه ممکن است کاربران
دیگر نسخه کاری خود که یک سری فایل در آن
تغییر یافتهاند را بر روی مخزن فایل
اصلی commit
نمایند.
در
اینــصورت شـما نیز باید این تغییرات را
بر روی نسخه کاری خود داشته باشید تا همیشه
در جریان پروژه قرار داشته و جــدیــدترین
فایـلـها را در اخـتیار داشته باشید.
برای
اینکار از دستور svn
update مانند
مثــال قبــل استفاده میکنیم.
اجازه
دهید چهار حـالـت مخـتـلفی کــه به هنگام
بروز کردنcommit
کردن
نسخه کاری پیش میآید را بررسی نماییم:
فایل
موجود در نسخه کاریتان از آخرین لحظه
checkout
تا
بحال تغییر نــکـرده و فایل موجود در
مخزن فایل نیز تغییر نکرده است، به عبارتی
این دو فایل عین هم هستند.
svn commit هیــچ
کــاری را انـجـام نمیدهد، svn
update هم
هیچ کاری را انجام نمیدهد.
فایل
شما در نسخه کاریتات تغییر کرده است، ولی
فایل موجود در سِرور هیچ تغــیـیری
نـکــرده است، در اینصورت svn
commit باعث
میشود تغییرات شما بر روی سِرور منتقل
شود و svn
update هیچ
کاری را انجام نمیدهد.
فایل
در نسخه کاری تغییر نکرده، ولی در مخزن
فایل اصلی سرور تغییر یافته است، در
اینصورت svn
commit هیچ
کاری را انجام نمیدهد، ولی svn
update نسخه
جدید را از سرور گرفته و فایل شما را بروز
میکند.
فایل
هم در نسخه کاری و هم در مخزن فایل اصلی
تغییر کــرده اســت!
در
ایــن حـالت دستور svn
commit پیغام
خطای اینکه فایــل شما بهروز نیــست
را برمیگرداند کـه بــرای رفــع این
خطا باید از دستور svn
update استفاده
نمایید.
پس
از اجرای svn
update،
ابتدا subversion
تــلاش
میکند خــود تصادم (Conflict)
ایجاد
شده را با ترکیب این دو فایل رفع نماید،
اگر تغییرات در این دو نسخــه به گـونهای
باشد که subversion
نتواند
این کار را انجام دهد، وظیفه انجام اینکار
بر دوش کاربر گذاشته میشود.
تنها
در صـــورتی subversion
میتــوانــد
خــود عمــل ترکـیب (merge)
این
دو فایل را انجام دهد که تغییرات ایجاد
شده در آنها بسیار ساده باشد، مثلا فایل
موجود در سرور در خطوط اولیه تغییر کرده
باشد و فایل موجود در نسخه کاری در خطوط
آخــر، در غیـر اینصورت subversion
نمیتواند
این کار را انجام دهد.
همانطور
که دیدید بدترین حالت گزینه آخر است، یعنی
هنگامی کـــه شما نسخه کاری را خــود را
update
کــردهاید
و در حال کار بر روی یــک فــایــل هستید،
بعد از چـنـد وقت که بخواهید تغییرات
خــود را دوباره در ســرور قرار دهید،
ببینید که شخص دیگری نیز همزمان با شما
مشغول به کار بر روی همان فایل بــوده،
منتها او فــایل خــود را زودتــر commit
کــرده
است!
فرض
کنید همین اتفاق برای فایل someOtherFile.php
بیفتد.
اگر
خاطرتان باشد بار اولی که این فایل را
ایجاد کردیم و در مخزن فایل commit
نمودیم،
محتوای آن بصورت زیر بود:
-
|
<?PHP
print
"hello hello hello";
?>
|
و
اگر باز هم خاطرتان باشد، بعد از انجام
ویرایشاتی بر روی آن، محتوای آن به صورت
زیر تغییر پیدا کرد:
-
|
<?PHP
if
( $ILikeYou )
print "hello hello hello";
else
print "go to hell!";
for ($i=0; $i<2000;
$i++)
echo "I should go to military
service...";
?>
|
حال
فرض کنید کاربری همان موقع که ما نسخه
اولیه را در مخزن فایل commit
نمودیم،
این نسخه را دریافت کرده باشد.
او پس
از دریافت این نسخه، تغییرات خودش را بر
روی فایل اعمال کرده است، تغییراتی مشابه
زیر:
-
|
<?PHP
for
($i=5; $i<10; $i++)
{
print "hello hello
hello";
$j=0;
}
?>
|
کاربر
بیچاره ما خبر ندارد که در هنگامی کــه
او در حال انجام ویرایشات خــود بوده، آن
نسخه جدیدتر مــا در مـخــزن فایل commit
شده
است (نمونه
کد شماره ۲ واقع در وسط صفحه قبل).
او بعد
از انجام تغییرات خود میخواهد که کار
خود را commit
نماید
که با پیغام زیر روبرو میشود:
-
|
$
svn commit -m 'Delibrately making a conflict!'
Sending
someOtherFile.php
svn: Commit failed (details
follow):
svn: Out of date: '/someOtherFile.php' in
transaction 'f'
|
کاربر
سرشکسته ما که فهمیده است دلیل بروز این
پیغام همانا انجام ویرایشات او بر روی
فایل قدیمی نسبت به آخرین نسخه موجود در
مخزن فایل بوده است، سعی میکند با اجرای
svn update فایل
جدیدتر را دریافت کند، که با اینکار در
واقع از چاله به چاه میافتد:
-
|
$
svn update
C someOtherFile.php
Updated to revision 12.
|
علامت
C در
کنار نام فایل همان Conflict
است
که نشان میدهد subversion
خود
نتوانسته است تغییرات این دو فایل را
ترکیب نماید.
اگر
subversion خود
موفق به انجام اینکار میشد، آنگاه علامت
G که
همان merGed
است
را میدیدیم.
با
دیدن علامت C
در
کنار نام فایلی بدانید که آن فایل در واقع
update نشده
است و همینطور نمیتوان آنرا در مخزن
فایل نیز commit
کرد،
چرا که خطر این وجود دارد که تغییرات یکی
از طرفین از بین برود.
پس
تکلیف چیست؟ خوب، شما باید خود بصورت دستی
اینکار را انجام دهید.
به
هنگام بروز چنین مشکلی، subversion
سه کار
جالب را برای آگاهسازی هر چه بیشتر شما
انجام میدهد:
علامت
C را
کنار فایل چاپ میکند و به خاطرش میماند
که این فایل مشکل دارد.
اگر
subversion
تشخیص
دهد که در چه نقاطی از فــایل خطــر تصادم
تغییــرات کاربر با تغییرات موجود در
مخزن فـایل وجود دارد، با گذاشتن علامتی
که بعدا با هم میبینیم در فــایل که در
اینجــا هـمــانــا someOtherFile.php
میباشد،
این نقاط را مشخص میکند تـا کـار بــرای
شما که میخــواهـیـد دو فایل را به طور
صحیح با هم ترکیب کنید، آسان شود.
برای
هر فایلی که به مشکل conflict
بربخورد،
۲ و یا ۳ فایل کمکی زیر را ایجاد میکند:
filename.rOLDER_VERSION
این
فایلی است که در نسخه BASE
شما
وجود داشته، به بیــان دیــگـر فایلی که
بعد از آخرین checkout
شروع
به ایجاد تغییرات در آن کردهاید که الان
همین تغییرات مشکل ساز شدهاند.
filename.rNEWER_VERSION
این
فایلی است که در نسخه HEAD
وجود
داشته، به بیان دیگر این هــمــان فایلی
است کـه شما میخواستید از مخزن فایل به
عنوان جدیدترین نسخه دریافت کنید، غافل
از اینکه با تغییراتی کــه در نـسخــه
خــود دادهاید بـاعــث بروز مشکل خواهید
شد.
filename.mine
این
در واقع همان فایلی است که پس از انجام
تغییرات بر روی نسخه BASE
خود
در دست داشتید و میخــواستــید در مخزن
فایل اصلی commit
کنید
کـــه مشـکلات از آنجا شروع شد و ...
فراموش
نکنید که همانطور که ذکر شد در صورتی کــه
subversion
بتواند
نقــاط تفاوت فایلها را با عــلاماتی
مشخص کند، این علامات را در خــود فــایل
اصــلی (در
ایـنـجا someOtherFile.php)
میگذارد،
به بیان دیگر شمــا بــه این فایل
filename.mine
نیــاز
داریــد تــا اصـولا آخرین کار خود را
ببینید.
منتها
اگر subversion
نتواند
نقاط مشکل دار فایلها را مشخص کند، دیگر
فـایل شما را نیز تغییر نمیدهد، بنابر
این دیگر filename.mine
را
نمیسازد.
تئوری
کافیست!
ببینیم
که چه اتفاقی افتاد.
در
وهله اول اگر محتوای شاخه خود را با دستور
ls نگاه
کنید، میبینید که این ۳ فایلی که خدمتتان
عرض شد، واقعا ایجاد شدهاند.
میتوانید
محتوای هر کدام از این فایلها را نیز
مشاهده کنید تا صحت گفتار ما و حسن نیت ما
بر شما ثابت شود!
خــوب،
الان اگر فایل someOtherFile.php
را با
ویرایشگر محبوب خود باز نمایید، خطوط زیر
را مشاهده خواهید کرد.
و
این همان علامات جادویی هستند که ما قرار
بود راجع به آنها صحبت کنیم.
هر کجا
کــه <<<<.mine
آمــده
بـود یعنی اینکه آن قسمت مربــوط بــه
فـایــل مــوجــود در نسخه کاری شما
میباشد، و دقیــقا بعد از آن که آن
قسمت تمام شد، قسمتهای موجود در فایل
موجود در مخزن فایل میآید.
اینگونه
شما براحتی میتوانید تغیــیرات را
مشاهده کرده و آنها را به بهترین وجه که
خود به عنوان برنامهنویس سیستم مطلعید
با هم ترکیب کنید تا حاصل کار شــما و
آخــرین کـار با هم دیــگر نسخــه واحــدی
را بســازند.
بـعـد
از اینــکـه ایــن تغییــرات را انـجــام
دادید، میتــوانید کل محتوای این فایــل
را در someOtherFile.php
کـپــی
کنــیـد، و یــا اصــلا فــایــل
someOtherFile.php
را
پــاک کــرده و اســم ایــن فـایــل را
بــه someOtherFile.php
تغییر
دهید! خلاصه
اینکه در انتها باید نتیجه کار خود را
مجدد در فایلی به همان اسم اولیه، در اینجا
یعنی someOtherFile.php
قرار
دهید. بعد
از آنکه کار خود را تمام کــردید، بــایـد
این ۳ فایلی که توسط subversion
تولید
شدهاند را پاک کنید، آنگاه مجدد دستور
svn commit را
اجرا نمایید.
تا
هنگامی که این فایلها پاک نشدهاند،
subversion هنوز
فکر میکند که شما مشکل تصادم را حل
نکردهاید.
-
|
<<<<<<<
.mine
<?PHP
for ($i=5; $i<10; $i++)
{
print "hello hello hello";
$j=0;
}
?>
======
<?PHP
if ( $ILikeYou )
print "hello hello hello";
else
print "go to hell!";
for ($i=0; $i<2000;
$i++)
echo "I should go to military
service...";
?>
>>>>>>> .r12
|
چگونه
باید این فایلها را پاک کرد؟ آیا توسط
سیستم عامل و بصورت دســتی باید اینکار
را انجام دهیم؟ میتوانید همچین کاری
بکنید، ولی چه لزومی دارد از خود subversion
عــزیز
و دستور svn
resolved کــه
مختص به اینکار ایجاد شده است استفاده
نکنیم؟
-
|
$
svn resolved someOtherFile.php
Resolved conflicted state
of 'someOtherFile.php'
|
با اجرای این
دستور مشکل conflict
ما حل
شده و میتوانیم با خیال راحت commit
نماییم.
بیژن
هومند
 PDF Version
[1]
http://subversion.tigris.org
| 
منوی اصلی
