تسلیم می‌شویم

در یکی از مجموعه‌ها خیلی اصرار کردم که به جای TFS از SVN استفاده شود. اما نتوانستم حرفم را به کرسی بنشانم. الان در آن مجموعه تقریباً از همه امکانات سورس کنترلی TFS استفاده شده و به غیر از دو سه ماه اول که دوستان خطاهای Runtime برنامه‌شان را هم به گردن TFS می‌انداختند مشکل خاصی وجود ندارد.

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

۱- قبل از صدور دستور commit، فایل‌های تغییر یافته‌شان را save کنند،

۲- حذف و اضافه فایل به پروژه در ویژوال استودیو نیاز به Save all یا اقلاً یک Rebuild Solution دارد،

۳- اگر دو نفر یک جای یکسان از یک فایل واحد را تغییر دهند، merge conflictی به وجود می‌آید که خود git نمی‌تواند آن را به طور خودکار resolve (حل) کند. و این از منطق کار تیمی و منطق فکری نشات می‌گیرد و جز نقایص git یا هر سورس کنترل دیگری نیست،

۴- ساختار پروژه در ویژوال استودیو خودش در یک فایل خاص با پسوند csproj نگهداری می‌شود پس به وجود آمدن merge conflict در آنجا هم امکان‌پذیر است،

۵- برای پیشگیری از merge conflict اول هر روز کاری یا حتی دو سه بار در روز، قبل از شروع کار باید اول تغییرات دیگران را دریافت کرد،

۶- نگهداری فایل یک کلاس یا winform با بیش از ۱۵۰۰ خط کار درستی در یک محیط تیمی و تحت سورس کنترل نیست،

۷- …

تنها فرق حالت اول و دوم این است در که در حالت اول خود ویژوال استودیو همه کارها را انجام می‌دهد. مثلاً قبلاً از check-in شما را مجبور می‌کند که همه فایل‌ها را save کنید. بنابراین کسی مجبور نیست از معدن گچش استفاده کرده و حواسش به save فایل‌ها قبل از ارسال به سرور باشد.

این است که دست‌هایمان را به نشانه تسلیم بالا برده و اجازه می‌دهیم دوستان به جای استفاده از git، سورس مشترکشان را روزی ده بار از طریق usb flash با هم به اشتراک بگذارند و خودشان نقش سورس کنترل را بازی کنند.

البته این بازی یک درس هم برای من داشت. آن هم این که اگر افراد به طور داوطلبانه از سورس کنترل git یا حتی svn استفاده کردند معنی‌اش آن است که آنها افراد دقیق و قابل اعتمادی هستند.

.
.
.
.

باشد که روزی به راه راست هدایت شویم.

‫تبدیل سورس‌های svn به git

یک بار وقتی که می‌خواستم سورس‌های موجود در Source Safe را به یک سورس کنترل Subversion منتقل کنم متوجه شدم که کار خیلی سختی است. به این علت که ابزارهای خیلی کمی برای این کار وجود داشت. علاوه بر اینها به نظر می‌رسید history فایل‌ها را نمی‌توان به svn منتقل کرد. هیچ کس هم این کار را توصیه نمی‌کرد. این تبدیل از نظر آنها به درد نخور بوده و توصیه می‌شد که آخرین نسخه سورس Source Safe به صورت یک نسخه کاملاً fresh و بدون هیچ history به svn منتقل شود. من هم در آن زمان مجبور شدم همین کار را بکنم.

اما حالا یک بار دیگر می‌خواهم سورسی را از یک Source Control به یک Source Control دیگر منتقل کنم اما این بار با history. خوشبختانه چون می‌خواهم این بار سورس کد را از svn به git منتقل کنم مشکل چندانی ندارم. این کار چندان سخت نیست. کافی است با کمی جستجو به یک راهنمای خلاصه برسید و مراحل را دنبال کنید. من با کمک این راهنمای چند خطی توانستم سورس یک پروژه موجود در Codeplex را از svn به git منتقل کنم. البته دقت به چند نکته می‌تواند عملیات انتقال را راحت‌تر کند:

۱- باید به جای دستور git-svn از دستور git با سویچ svn استفاده کنید. یعنی به صورت git svn.

۲- git svn با urlهای فایلی مثل file:///d:/repo خیلی مشکل دارد. سعی کنید از urlی مثل svn://myserver استفاده کنید. درست کردن یک سرور با استفاده از svn کار چندان سختی نیست. به این راهنما مراجعه کنید.

۳- حواستان به این موضوع باشد که ساختار branch در svn تفاوت زیادی با git دارد. یعنی اگر می‌خواهید branchها را هم از svn به git منتقل کنید باید کمی documentationهای git را بالا و پایین کنید.

۴- بهتر است قبل از شروع سری به راهنمای git مخصوص svn کارها بیندازید.

۵- من همه این کارها را با کمک Git Extensions انجام دادم.

‫کار با git

درست یک سال پیش که می‌خواستم سورس کنترل شرکت قبلی را از SourceSafe به یک سورس کنترل جدیدتر ارتقا بدهم به شدت بین svn و git دودل بودم. یکی از دلایل این تردید سخت بودن کار با git بود خصوصاً برای کسانی که قبل از آن فقط با SourceSafe کار کرده بودند. اما حالا بعد از یک سال که حسابی به svn عادت کرده‌ام و مشکل متمرکز بودن svn حسابی اذیتم کرده تصمیم گرفتم یک بار دیگر شانسم را در به کار گیری git امتحان کنم. خوشبختانه این بار خوش شانس بودم و بلد بودن svn باعث شد خیلی سریع بتوانم از روی راهنمای مخصوص svn کارها، عملیات مقدماتی git را یاد بگیرم.

اگر شما هم می‌خواهید کار با git را خیلی سریع شروع کنید بهتر است یک فضای git در assembla.com (این سایت امکان ایجاد repo خصوصی را فراهم می‌کند) ایجاد کرده، Git Extensions یا msysgit را نصب و سپس بر اساس راهنمای git svn crash و instructions خود assembla.com کارتان را شروع کنید. مقداری از اطلاعات مفید:

* git و دستورات خط فرمانی آن خیلی شبیه به svn هستند. با این تفاوت که در git هر کسی برای خودش یک repo دارد و می‌تواند مدام با repoهای دیگر اعضای گروه push و pull کند.

* تعدادی از دستورات git عبارت هستند از git status، git commit -a، git add و git diff. به شباهت آنها با svn توجه کنید.

* شما در git هر وقت که کارتان تمام شد تغییرات را commit می‌کنید. هر وقت هم که خواستید این تغییرات را به repo دیگران بفرستید یا تغییرات repo افراد دیگر را دریافت کنید باید از عملیات pull و push استفاده کنید.

* مدل branch و tag در git کمی فرق کرده.

* git هم add-inهایی هم برای Visual Studio و هم برای Windows Explorer دارد.

* در git شماره versionها مثل svn یکی یکی بالا نمی‌رود بلکه به صورت عددی هگزا دسیمال مشابه Guid است.

* برای شروع کار با یک مخزن دیگر باید با استفاده از git clone یک نسخه از آن را در کامپیوتر خودتان دریافت کنید. این دستور مشابه svn checkout است.

* در git هم می‌توان یک repo را به طور قراردادی repo مرکزی فرض کرد و افراد را ملزم به push/pull با آن کرد.

* از اسم git نترسید، امکانات خوبی دارد!

Good days with Subversion

Despite debate of these days which argue that Subversion‘s gold days has been gone and it must be replaced with a distributed SCM like Git, we recently get rid of SourceSafe and migrated to Subversion happily. Before continuing I must emphasis that we were not the only company that uses SourceSafe. There are yet many other companies in Iran that are using SourceSafe. Even there are many other companies and development teams that are not using any SCM at all.

In my opinion our delay of migrating to an up-to-date SCM just like Subversion, Git or TFS was lack of knowledge about new technologies and tools and fear of change. Fortunately in last 2 month I managed to convince my boss to replace SourceSafe with Subversion by showing him that Subversion could be integrated with Visual Studio too by utilizing AnkhSVN. He went happy with hooks that can send emails and with easy branching provided by Subversion. At last he was satisfied when realized that Subversion has a minimum hardware requirement in comparison with TFS. TFS was an old Subversion competitor in our company when we were planning to find a better replacement for SourceSafe.

It is second week that we turned SourceSafe into read-only mode, moved all needed sources to Subversion and updated all process to use Subversion. And fortunately this was a happy migration, nothing went bad, we got no trouble and our client machines and developers complained of nothing. Our style of utilizing Subversion included using 3 excellent tools: Slik Subversion 1.6.9, TortoiseSVN 1.6.7.18415 and AnkhSvn 2.1.7819.411.

Installing Subversion

Congratulations to myself! Finally beat SourceSafe and installed Subversion instead of it. There was a long time that we thought it’s the end of SourceSafe specially when using it offline but we needed confirmation of boss. Nowruz holidays was a good time for a thorough reading of Subversion. Just days after end of holidays, we migrated from SourceSafe to Subversion.
Installing Subversion was not as hard as I thought. In server I just installed slik subversion and followed a very concise guideline in CODING HORROR. After then each client installed TortoiseSVN and AnkhSVN and desired SourceSafe sources imported to Subversion. The only problem that we saw was an incompatibility between Subversion itself and its clients, AnkhSVN and TortoiseSVN. I was using latest version (at the time) of TortoiseSVN and AnkhSVN with an relative old version of Subversion. This caused AnkhSVN error message that was saying you should downgrade something. To get rid of this error I uninstalled everything, downloaded all latest versions (Slik Subversion 1.6.9, TortoiseSVN 1.6.7.18415 and AnkhSvn 2.1.7819.411) and installed them again.

Is SVN better than TFS?

These days I’m convincing some colleagues and managers to not use TFS and use SVN instead. I’m pretty sure that SVN fits better into our hardware and knowledge limitations. Additionally we are going to use TFS just for source controlling.

For me, SVN has many advantages over TFS even when pricing is not a matter:

  1. SVN can be installed on old machines; it requires just few mega bytes of hard disk. It also does not need additional resources like MS SQL.
  2. SVN has a very larger user community than TFS.
  3. SVN is common in open source world but TFS not.
  4. SVN can work disconnected, and supports patches.
  5. More companies use SVN than TFS (near me).

‫دلایل برتری SVN بر SourceSafe

همه می‌دانند که دوران SourceSafe خیلی وقت است به سر آمده و به جای آن باید جایگزین بهتری مثل SVN یا git پیدا کرد. اما با وجود آن هنوز هم باید برای برای از رده خارج کردن SourceSafe از بعضی جاها، دلایل واضح و گویایی پیدا کرد. از آنجا که من هم در حال براندازی SourceSafe از اینجا و جایگزینی آن با SVN هستم تصمیم گرفتن بعضی مزایای این دو را نسبت به هم بسنجم. البته این متن یک مقایسه کلی بدون عمیق شدن زیاد به خصوص در SVN است. اما به هر حال می‌کنم همین مقایسه سرسری هم بتواند فاتحه SourceSafe را بخواند. من برای تهیه این مقایسه از کتابچه Subversion وحید نصیری استفاده کرده‌ام.

امکانات SVN که یا در SourceSafe وجود ندارند یا استفاده از آنها سخت و پردردسر است:

۱- منابع یادگیری و آموزشی در مورد SVN خیلی بیشتر از SourceSafe است.
۲- سرعت کار با SVN بیشتر است.
۳- مکانیزم patch در SVN در تیم‌های پراکنده خیلی به درد بخور است در حالی که SourceSafe اصلاً چنین امکانی ندارد.
۴- انشعابات و تگ‌گذاری در SVN خیلی راحت‌تر و رایج‌تر است.
۵- SVN دارای ابزاری به نام hooks است که در اتوماسیون پروسه تولید نرم‌افزار خیلی مفید و به درد بخور است.
۶- با SVN خیلی راحت‌تر می‌توان سرورهای کنترل سورس ایجاد کرده و به اینترنت متصل کرد.
۷- با SVN خیلی راحت‌تر می‌توان Continuous Integration را (با کمک ابزارهایی مثل CruiseControl) پیاده‌سازی کرد.
۸- بلد بودن SVN در بازار کار با ارزش‌تر از بلد بودن SourceSafe است.
۹- SVN بر خلاف SourceSafe علاوه بر ویندوز در سیستم عامل‌های دیگر هم قابل استفاده است.

۱۰- SVN قابلیت integrate شدن با خیلی ابزارهای دیگر مثل Apache را دارد ولی SourceSafe ندارد.

۱۱- SVN کدباز است و استفاده از آن هم مجانی و بدون دردسر crack است و هم اخلاقی.
۱۲- SVN با کمک TortoiseSVN با ویندوز integrate می‌شود در نتیجه کار با آن SVN در خارج از Visual Studio هم خیلی راحت است.

امکانات SourceSafe که یا در SVN وجود ندارند یا استفاده از آنها سخت و پردردسر است:

۱- به نظر می‌رسد (خودم هنوز امتحان نکرده‌ام) که integration ابزار SourceSafe با Visual Studio راحتی و امکانات بیشتری نسبت به برنامه‌های integration ابزار SVN (مثل ابزار کدباز AnkhSVN و ابزار تجاری VisualSVN) به دست بدهد.

نکات تکمیلی:
در ادامه موضوع این نوشته، به پیوندهای زیر هم نگاهی بیندازید:

‫انتخاب بین SVN و git

مدت‌هاست که به دنبال خلاصی از دست SourceSafe هستیم ولی چون رییس نمی‌خواهد، نمی‌شود که نمی‌شود. رییس آنقدر به SourceSafe علاقه دارد که من خودم هم بعضی وقت‌ها یادم می‌رود چرا می‌خواهم آن را کنار بگذارم. برای جایگزینی SourceSafe دو گزینه را نامزد کرده‌ام: SVN و git. ولی متاسفانه انتخاب بین این دو برایم آنقدر سخت شده که بی‌حساب.

git در این دو سه ساله محبوبیت خیلی خیلی زیادی پیدا کرده است و روز به روز در حال پیشی گرفتن از SVN بوده است. git امکانات خیلی خوبی برای تیم‌های decentralize دارد. به عنوان مثال وقتی که سرور خاموش است یا به اینترنت دسترسی ندارید باز هم می‌تواند از نسخه local خود به عنوان یک سورس کنترل استفاده کنید و بعداً که به سرور دسترسی پیدا کردید آن check-inهای local را به راحتی در سرور اصلی check-in کنید.

هم git و هم SVN محبوبیت خوبی در پروژه‌های کدباز دارند ولی حدس می‌زنم جا افتادن git در شرکت‌های ایرانی خیلی طول بکشد. چون با وجود add-inهایی که برای Visual Studio دارد (مثل Git Extension) باز هم مهمترین ابزار کار با آن git bash است که یک ابزار خط فرمانی است. از دیگر سو SVN در حال حاضر توسط تعدادی از برنامه‌نویسان ایرانی و قاعدتا شرکت‌های ایرانی مورد استفاده قرار می‌گیرد. add-inهای معروف‌تری مثل AnkhSVN دارد و رابط معروفی مثل TortoiseSVN دارد.

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

توجه: StackOverflow پر است از بحث‌های مقایسه git و SVN.

به روز رسانی: برای مقایسه این دو از دید یک برنامه‌نویس ایرانی، نگاهی هم به اینجا بیندازید.

In praise of Source Control Software

We are a small semi-distributed development team. Our team use MS Visual Source Safe 2005 on an internal server at company. One of colleagues sends her patches via email to me and I’m forced to check-in her changes. This manual operation is very tedious and time waster. Everyone knows that there is better source control softwares that if configured properly, she could compile her patches in a pack and I will check-in them in a very easier manner even if we have not an connected server.

In an ideal situation I wish ourselves:
1. Adoption the need for a better source control software like SVN or git by BOSS.
2. Knowledge of using desired source control software among colleagues.
3. A connected-to-internet server for hosting source control software