ورود/ایجاد حساب کاربری
   منوی اصلی
· خانه
· لیست کاربران
· جستجو
· آمار مشاهدات
· آرشیو مقالات


- شرح
· راهنمای نویسندگان
· درباره ما

   همکاری با نشریه
در صورتی که مایل به همکاری با نشریه هستید، می‌توانید در لیست پستی نشریه عضو شده و در جریان امور قرار گیرید. برای اطلاعات بیشتر، اینجا کلیک کنید.

   کاربران
سردبیر
هیچ مدیر کمکی حاضر
همکاران
هیچ مدیر کمکی حاضر
اعضا:
جدیدترین:جدید امروز:0
جدیدترین:جدید دیروز:0
جدیدترین:مجموع:2471
جدیدترین:جدیدترین:
ufumenarayu
اعضا:حاضر
اعضا:اعضا:0
مهمان‌ها:مهمان‌ها:10
مجموع:مجموع:10
کاربران حاضر
هیچ کاربر حاضری وجود ندارد

   ورود کاربران




 


 برای ورود مشکل دارید؟
 ثبت نام کاربران جدید

آشنایی با Subversion بخش دوم

(1860 مجموع کلمات موجود در متن)
(7911 بار مطالعه شده است)  نسخه چاپی

آشنایی با Subversion بخش دوم


مفاهیم اولیه
تمام سیستمهای کنترل ورژن به دنبال یک هدف ساده و اولیه هستند که همانا ساده سازی مشارکت کاربران مختلف در انجام پروژه و مدیریت فایلها به قسمی‌است که هیچ کاربری نتواند پا در کفش کاربر دیگری کرده و کار او را خواسته و یا ناخواسته خراب کند. مشکل کنترل ورژن و پیامدهای آن چیزی نیست که امروزه به آن پی برده باشند، بلکه از بدو ایجاد کامپیوترها و برنامه نویسی گسترده و گروهی این مشکل وجود داشته و همیشه سعی شده که راههایی برای مقابله با آن طراحی شود.


مخزن فایل (Repository)

در قلب subversion یــک مخزن فایــل وجود دارد که تمام فایلهای پروژه در آن ذخیره می‌شود. این سیستم دقیقا یک سیستم خادم/مخدوم (Client/server) است، به این معنا که کل فایلهای یک پروژه درون مخزن فایل سِرور مرکزی قرار میگیرد و تمام اعضاء پروژه در قالب دستگاههای کلاینت به سِرور متصل شده و فایلهای مورد نیاز را دانلود می‌کنند. هر کاربر می‌تواند پس از انجام تغییرات لازم، فایلهای تغییر داده شده را دوباره به مخزن برگرداند و بدین صورت بقیه را از انجام تغییرات باخبر کند.



شکل۱ یک سیستم خادم/مخدوم نمونه


با دیدن این مدل ممکن است این تصور در شما ایجاد شود که subversion تنها یک فایل سیستم است، و خوب این کاملا تصور درستی است! منتها subversion یک فایل سیستم معمولی و مشابه چیزهایی که تا بحال با آنها آشنا بوده اید نیست، عاملی که subversion را در این قضیه متمایز میکند این است که subversion فایل سیستمی‌است که تمام تغییراتی که در آن نوشته شود را بخاطر می‌سپارد: تمام تغییراتی که روی تمام فایلها و یا حتی شاخه ها انجام شود، و این شامل عملیاتی چون پاک سازی، اضافه کردن و حتی عوض کردن ترتیب فایلها/شاخه ها می‌شود.

وقتی که یک کاربر در حال دریافت فایلها/شاخه های پروژه از این فایل سیستم است، در واقع در حال مشاهده آخرین نسخه فایلهای موجود در فایل سیستم می‌باشد. منتها او امکان این را دارد که مثلا نسخه مربوط به ۵ سال پیش را از فایل سیستم بخواهد و در آن صورت subversion مخزن را به حالت ۵ سال پیش که کاربر تقاضا کرده برای او نمایش می‌دهد. به بیان دیگر subversion می‌تواند در هر لحظه برای هر کاربر تصویر مورد نظر او از پروژه را در هر بازه زمانی که بخواهد ارائه دهد. به عنوان مثال کاربر می‌تواند سوالات مختلفی از تاریخچه سیستم را بپرسد، سوالاتی چون: “این شاخه که در حال حاضر در حال مشاهده آن هستم در چهارشنبه دو هفته پیش شامل چه فایلهایی بوده" و یا "اسم آخرین کاربری که بر روی این فایل تغییرات ایجاد کرده چه بوده و چه تغییراتی را ایجاد کرده است؟"

مشکل به اشتراک گذاری فایلها

همانطور که در مقدمه ذکر شد، هنگامی‌که تعداد کاربران بر روی یک پروژه از یک نفر بیشتر باشد، همیشه امکان دوباره کاری و مشکلات عدم هماهنگی وجود دارد. با توجه به شکل ۲-۲ فرض کنید که هَری و سَلی همکار باشند. آنها هر دو در آن واحد تصمیم می‌گیرند که بر روی یک فایل واحد از مخزن کار کنند. اگر هَری ابتدا تغییرات خود را در مخزن ذخیره کند، این امکان وجود دارد که چند لحظه بعد سَلی اشتباهاً بخواهد که تغییرات خود را ذخیره کند و بدین صورت نسخه فایل سَلی روی فایل هَری نوشته شود. با اینکه تغییرات هَری برای همیشه از بین نرفته اند (چون همانطور که ذکر شد سیستم تمام تغییرات را به خاطر می‌سپارد و تنها فایل سَلی به عنوان جدیدترین نسخه از آن فایل در مخزن قرار گرفته است)، با اینحال تغییرات هَری در فایل سَلی وجود نخواهند داشت، چون سَلی هیچوقت فرصت این را پیدا نکرده بود که قبل از ذخیره فایلش در مخزن از آخرین تغییرات هَری باخبر شود. کار هَری هم در سیستم گم شده است، حداقل اینکه دیگر در آخرین ورژن مخزن قرار ندارد. این دقیقا شرایطی است که ما میخواهیم جلوی آنرا بگیریم!



شکل ۲ مشکل کار همزمان هَری و سَلی


راه حل اول: روش قفل گذاری-ایجاد تغییرات-آزاد سازی

خیلی از سیستمهای کنترل ورژن از این مدل استفاده می‌کنند. در این روش مخزن فایل تنها اجازه کار یک کاربر را بر روی یک فایل می‌دهد. به عنوان مثال اگر هَری بخواهد که بر روی فایل A کار کند، ابتدا باید آنرا قفل کرده، سپس تغییرات لازم را روی آن اعمال نماید و پس از آن دوباره فایل را ‌آزاد کند. بدین صورت اگر بعد از قفل گذاری هَری و هنگامی‌که او در حال اعمال تغییرات روی فایل است، سَلی بخواهد بر روی فایل کار کند، سیستم اجازه اینکار را به او نمی‌دهد. تنها کاری که او می‌تواند انجام دهد این است که می‌تواند فایل را بخواند و منتظر شود تا تغییرات هَری تمام شود. وقتی که هَری فایل را آزاد کند، دیگر نوبت او تمام شده است و سَلی می‌تواند فایل را مجدد قفل کرده و شروع به کار کند که در آنصورت کاربران دیگر حق اعمال تغییرات بر روی فایل را نخواهند داشت. شکل ۳-۲ روش کار این مدل را نشان میدهد.



شکل ۳ روش قفل گذاری- اعمال تغییرات- آزاد سازی


با اینکه در نگاه اول ممکن است این روش خیلی کارآمد به نظر برسد، ولی اگر شما هم نگاهی به مشکلات آن بیندازید با من هم عقیده خواهید شد که این روش احمقانه ترین روشی است که برای کار گروهی ممکن است پیشنهاد شود!


  • این روش مشکلات مدیر سیستم را چند برابر میکند ممکن است بعد از اینکه هَری فایل را قفل کرد و تغییرات خود را انجام داد، به کل فراموش کند که فایل را دوباره آزاد کند. حتی ممکن است او به یک مسافرت دو هفته ای برود، در این صورت سَلی بیچاره دست از پا دراز تر باید منتظر آزاد سازی قفل هَری بماند. در اینحالت او به مدیر سیستم مراجعه می‌کند و از او می‌خواهد که قفل هَری را آزاد کند، که این خود دردسری خواهد بود برای مدیر بیچاره سیستم، بعلاوه اینکه هیچوقت تضمین صد در صدی وجود ندارد که در هنگام آزاد سازی قفل توسط مدیر کل سیستم، هَری واقعا در حال کار بر روی فایل نبوده باشد!

  • قفل کردن دست و پا گیر است از کجا معلوم که هَری تنها در حال تغییر بر روی خطوط اولیه فایل نباشد، در حالی که سَلی فقط بخواهد خطوط انتهایی را تغییر دهد؟ در اینصورت می‌بینید که تغییرات این دو در واقع هیچ تاثیری روی یکدیگر نداشته و ما با اعمال سیاست قفل گذاری تنها کار را برای آنها مشکل کرده ایم.

  • قفل گذاری حس امنیت غلطی را ایجاد می‌کند فرض کنید که هَری بخواهد روی فایل A کار کند، او این فایل را قفل کرده و کار بر روی آنرا شروع می‌کند. حال اگر سَلی بخواهد که روی فایل B کار کند او نیز این فایل را قفل کرده و کار بر روی آنرا شروع می‌کند. در این حالت هر دو بسیار احساس خوبی داشته و مطمئنند که فایلی که بر روی آن کار می‌کنند متعلق به آنهاست و هیچ بنی بشر دیگری نمی‌تواند تغییرات آنها را از بین ببرد و اخلالی در کار فایلشان ایجاد کند، در صورتی که اگر فایل A به گونه ای نوشته شده باشد که برای کار نیاز به متغیرها و توابع فایل B داشته باشد، آنگاه ممکن است سَلی فایل B را جوری تغییر دهد که فایل A هَری بیچاره دیگر هیچگاه کار نکند! بدتر از همه اینکه هَری در حین تغییر فایل A متوجه می‌شود که فایل کار نمی‌کند و این کار نکردن این فکر را در او ایجاد می‌کند که تغییرات او باعث از کار افتادن فایل شده است!


راه حل دوم: روش کپی- ایجاد تغییرات- ترکیب

subversion، CVS و بعضی دیگر از سیستمهای کنترل ورژن از این روش استفاده می‌کنند. در این روش هر کاربر پس از برقراری ارتباط با مخزن فایل که بر روی سرور قرار گرفته است، نسخه ای از آخرین ورژن موجود بر روی مخزن فایل را بر روی کامپیوتر خود (کلاینت) کپی می‌کند. به این نسخه کپی شده که عینا مشابه با آخرین نسخه فایلهای موجود بر روی مخزن فایل در لحظه کپی برداری است، نسخه کاری (Working Copy) می‌گویند. بدین صورت هر کاربری بر روی کامپیوتر خود نسخه ای از فایلهای موجود در مخزن فایل را ذخیره می‌کند و تغییرات خود را بجای اینکه مستقیما بر روی مخزن فایل موجود در سِرور اعمال نماید، بر روی فایلهای موجود در کامپیوتر خود اعمال می‌کند. در نهایت او بعد از اینکه از تغییرات انجام شده راضی بود، با دادن دستوری به کامپیوتر خود، تمام فایلهای موجود در دستگاه را دوباره به مخزن فایل منتقل می‌کند و بدین صورت ورژن جدیدتری از فایلهایی که او تغییرات در آنها اعمال کرده است بر روی سِرور مرکزی قرار می‌گیرد. اگر در هنگامی‌که او در حال انجام تغییرات بر روی فایلهای موجود بر روی کامپیوتر خود بوده، کاربر دیگری زودتر از او بر روی فایلهای موجود در نسخه کاری خود کار کند و آنها را در سِرور قرار دهد، دیگر مخزن فایل به کاربر اول ما اجازه قرار دادن آن فایلها را بر روی سِرور نمی‌دهد و پیغامی‌مناسب مبنی بر اینکه این فایلها در هنگامی‌که او غایب بوده توسط شخص/اشخاص دیگری تغییر یافته اند صادر می‌نماید. در این حالت کاربر ما باید تغییراتی که در هنگام غیبت او اتفاق افتاده است را مجددا از مخزن فایل دریافت کرده و آن تغییرات را با تغییرات خود ترکیب نماید و سپس حاصل کار را که مخلوطی از تغییرات خود بعلاوه تغییرات کاربران دیگر است را مجددا در مخزن فایل قرار دهد. بدین صورت دیگر کاربر ما از تغییرات انجام شده مطلع می‌شود و خطر اینکه تغییرات اعمال شده توسط کاربران دیگر را نبیند از بین می‌رود. در بیشتر موارد subversion کاربر را در عمل ترکیب یاری می‌کند، بدین صورت که تفاوت فایل موجود در نسخه کاری او را با آخرین نسخه از آن فایل موجود در مخزن فایل نمایش می‌دهد، ولی در نهایت برای یک ترکیب درست در بیشتر مواقع به هوش یک انسان نیاز است.



شکل ۴ روش کپی- ایجاد تغییرات- ترکیب، قسمت اول


پاراگراف بالا به اندازه کافی واضح بود، ولی برای کامل تر شدن مطلب مثال معروف هَری و سَلی خود را برای این قسمت نیز تکرار می‌کنیم! فرض کنید هَری و سَلی هر دو نسخه های کاری خود را با کپی کردن فایلهای موجود در مخزن فایل بر روی کامپیوترهای خود ایجاد نمایند. آنها هر دو با هم بصورت موازی کار می‌کنند و تغییراتی در فایل A می‌دهند. سَلی ابتدا تغییرات خود را بر روی مخزن فایل اصلی ذخیره می‌کند (فایل موجود در نسخه کاری خود را بروی سِرور منتقل می‌کند). حال اگر چند لحظه بعد هَری بخواهد که تغییرات خود را در مخزن فایل ذخیره نماید، پیغامی‌دریافت می‌کند مبنی بر اینکه فایل موجود در نسخه کاری او از آخرین باری که نسخه کاری خود را از روی مخزن فایل بروزکرده است تغییر کرده است. بنابر این هَری از کامپیوتر خود می‌خواهد که آخرین تغییراتی که بر روی فایل موجود در مخزن فایل اعمال شده است را با فایل موجود در نسخه کاری او ترکیب نماید، بدین معنا که خطوط تغییر یافته و یا اضافه شده را در فایل موجود در نسخه کاری او کپی نماید. اگر این تغییرات بگونه ای باشد که خود کامپیوتر بتواند آنرا انجام دهد، مانند اینکه سَلی تنها تغییراتی را در خطوط اولیه فایل داده باشد، در حالی که هَری تنها خطوط انتهایی فایل را عوض کرده باشد، آنگاه خود کامپیوتر می‌تواند این ترکیب را انجام دهد، در غیر اینصورت همانطور که ذکر شد هَری ناچار است که خود شخصا هر ۲ فایل را با هم مقایسه کرده و ترکیبات لازم را انجام دهد. بعد از اینکه عمل ترکیب انجام شد، هَری نسخه خود را که هم اکنون جدیدترین نسخه از آن فایل حساب می‌شود (چون هم شامل تغییرات خودش می‌باشد و هم تغییرات سَلی) درون مخزن فایل قرار می‌دهد و بدین صورت همه چیز ختم به خیر می‌شود!




شکل ۵ روش کپی- ایجاد تغییرات- ترکیب، قسمت دوم


ممکن است در نگاه اول این روش به نظر کمی‌نامنظم و سرسری برسد، و لیکن تا کنون بهترین روشی است که برای اینکار شناخته شده و دست کاربران و مدیر/مدیران سیستم را به اندازه کافی باز می‌گذارد، در عین حالی که جلوی اشتباه و تصادم (Conflict) را تا حد بسیار بالای می‌گیرد. همانطور که مشخص است اصل هر سیستم کنترل ورژنی به تعامل کاربران با یکدیگر و در تماس بودن آنها با هم دیگر پایه گذاری شده است. حال اگر این سیستم بصورت دستی و ایرانی پیاده شود، همانطور که گفته شد مشکلات عدیده خود را دارد. با پیاده سازی یک سیستم اتوماتیک و آنلاین، هدف ما تنها حــذف روابــط فیــزیــکــی کاربران با یکدیگر و بوجود آوردن سیستمی‌قوی جهت نظم بخشیدن به این فرآیند می‌باشد؛ هیچگاه فراموش نکنید که در انتها این کاربران هستند که باید پروژه خود را به انجام برسانند و هیچ سیستم مکانیزه ای تاکنون چنین وظیفه ای را به عهده نگرفته است!



بیژن هومند

PDF Version

تمامی مطالب و مقالات این سایت تحت مجوز GNU FDL قرار دارند. بنابراین کپی و ایجاد تغییر در آنها مطابق شرایط این مجوز آزاد می‌باشد.