‫راه اندازی سرویس SVN در ویندوز

هر چند که با وجود git ممکن است کمتر انگیزه‌ای برای انتخاب SVN به عنوان یک سورس کنترل جدید وجود داشته باشد، اما به هر حال اگر نیاز به نصب SVN به عنوان یک سرویس ویندوز باشد می‌توان از راهنمای خوب Jeff Atwood برای این کار استفاده کرد.

این راهنما به طور خلاصه شامل دو مرحله است. اول ایجاد سرویس با کمک ابزار sc و دوم راه اندازی آن با کمک ابزار net. البته اگر با ویندوزهای جدیدتر مثل ویندوز ۷ یا ویندوز ۲۰۰۸ سر و کار دارید، باید حواستان باشد که این ویندوزها هم ip v4 را پشتیبانی می‌کنند و هم ip v6 را. بنابراین باید به هنگام ایجاد سرویس به svn بگویید حواسش به ipهای نسخه ۴ باشد یا نسخه ۶. جهت کسب اطلاعات بیشتر به اینجا مراجعه کنید.

پ.ن.: راه حل مربوط به ipهای نسخه ۴ و ۶ را ناصر حاجلو زحمت کشیده و پیدا کرده.

بی‌اطمینانی به مایکروسافت

سال‌های سال است که با محصولات مایکروسافت کار می‌کنم. دقیقاً از داس ۵ به این طرف. البته هیچ وقت هم با این موضوع مشکل خاصی نداشتم. هر وقت مایکروسافت داس را کنار می‌گذاشت و ویندوز را رو می‌کرد ما هم سراغ ویندوز می‌رفتیم، هر وقت ASP Classic را دور می‌انداخت ما هم همین کار را می‌کردیم و سراغ ASP.NET می‌رفتیم. خلاصه این که هر وقت مایکروسافت یکی از فناوری‌هایش را با فناوری جدیدتری جایگزین می‌کرد ما هم بدون هیچ اعتراضی همین کار را می‌کردیم. این تند تند عوض شدن فناوری را هم می‌گذاشتیم به حساب این که در دنیای کامپیوتر همه چیز تند تند عوض می‌شود و این ماییم که باید خودمان را با این موضوع تطبیق دهیم.

اما از وقتی که با NHibernate آشنا شدم و روال کار آن را با LINQ-to-SQL و Entity Framework مقایسه کردم دیدم که یک جای کار می‌لنگد. NHibernate با احستاب سوابق جاوایی‌اش چندین سال است که به خوبی کار کرده و خیلی کم دچار تغییرات شدید شده است. کلیاتی که از NHibernate یاد گرفته‌ام هنوز همان است و مجبور نشده‌ام به جز LINQ-to-NHibernate که یک افزونه جدید حساب می‌شود نه یک تغییر، چیز اساسی یاد بگیرم. اما کسانی که ORM را با مایکروسافت شروع کرده‌اند مثل من راحت نبوده‌اند. چون اول وقت زیادی روی LINQ-to-SQL گذاشتند ولی بعد از مدت کوتاهی به آنها اعلام شد که LINQ-to-SQL دیگر توسعه داده نخواهد شد و به جای آن باید از Entity Framework استفاده کنند. این یعنی چیزی را که یاد گرفته و به آن عادت کرده‌اید را باید به طور کامل دور ریخته و فناوری جدیدتری را با صرف کلی وقت یاد بگیرید.

مشابه این مسئله را در SourceSafe و جایگزینی آن با TFS هم دیده‌ام. کسانی که با SourceSafe کار می‌کردند مجبور شدند آن را با TFS عوض کنند. اما کسانی که از همان اول با SVN کار می‌کردند هیچ وقت دچار همچین اجباری نشدند. حدس می‌زنم همین مسئله را در مورد Web Serviceها از یک سو و ‎.Net Remoting و WCF از دیگر سو داشته باشیم.

مجموع این قضایا باعث شده که اطمینان‌ام را به مایکروسافت از دست بدهم و سعی کنم همیشه جایگزین‌های غیر مایکروسافتی را انتخاب کنم. این طوری دیگر مجبور نیستم تند تند چیزهای جدید یاد بگیرم. به بقیه همکارانم هم توصیه می‌کنم به این مسئله خوب فکر کنند. توجه شود همه این صحبت‌ها بدون توجه به مسائل اخلاقی و Copyright هستند که خود بحث جداگانه‌ای را می‌طلبد.

‫تبدیل سورس‌های 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 نترسید، امکانات خوبی دارد!

Private SVN hosting

سایت‌های رایگان خیلی زیادی برای نگهداری سورس تحت svn وجود دارد. از جمله CodePlex و SourceForge. اما متاسفانه این سایت‌ها فقط برای نگهداری سورس‌های کد باز (Open Source) قابل استفاده‌اند چون نمی‌توان سورس آنها را از دید عموم خارج کرد. بعضی سایت‌های دیگر مثل github هم هستند که امکان میزبانی سورس‌های غیر کد باز را ارائه می‌دهند اما نه به صورت مجانی. اگر می‌خواهید از این سرویس استفاده کنید باید پول پرداخت کنید. و اگر می‌خواهید از سرویس‌های رایگان این طور سایت‌ها استفاده کنید باز هم مجبور می‌شوید سورس خود را به صورت کد باز روی آنها قرار دهید.

اما این پایان راه نیست. اگر شما می‌خواهید سورس خود را به صورت غیر Open Source و به صورت مجانی در جایی نگهداری کنید می‌توانید از سایت‌های زیر استفاده کنید:

Assembla.com

دارای backup است.
محدودیتی در تعداد کاربر ندارد.
یک گیگا بایت فضا در اختیار می‌گذارد که نسبت به بقیه خیلی بیشتر است.
ثبت نام و کار با آن نیاز به تشریفات کمتری دارد.
از https استفاده می‌کند. در نتیجه ممکن است به علت محدودیت‌های اینترنت در ایران در بعضی روزهای خاص از کار بیفتد.
خیلی کند است.

http://unfuddle.com/about/tour/plans
به نظر خوب می‌آید

http://www.xp-dev.com
به نظر خوب می‌آید.

http://www.projectlocker.com
به نظر خوب می‌آید.

http://www.myversioncontrol.com
به نظر خوب می‌آید.

http://codesion.com
به نظر کند می‌رسد

http://www.sliksvn.com
خیلی قابل اطمینان است. ولی به نظر می‌رسد دارای تشریفات خیلی بیشتری برای ثبت نام است.

منبع:
http://www.svnhostingcomparison.com

‫چرا SVN بهتر از TFS است؟

دلایل خیلی زیادی برای این برتری وجود دارد. ولی فعلاً به این یکی بسنده کنید. فرایند پشتیبان‌گیری و برگرداندن پشتیبان‌ها (backup/restore) در svn خیلی ساده ولی در TFS خیلی پیچیده است.

برای پشتیبان‌گیری از مخزن SVN کافی است فولدر آن را در ویندوز کپی کرده و در جای مطمئنی نگه دارید. برای برگرداندن پشیبان هم کافی است فولدر پشتیبان را مجدداً در جای قبلی کپی کنید.

اما در TFS 2010 شما باید به کلی از کارهای admin ویندوز و  Sql Server مسلط باشید و برای انجام یک restore ناقابل مراحل زیادی را طی کنید. اگر باور نمی‌کنید نگاهی به لینک‌های زیر که همگی مربوط به فرایند backup/restore در TFS 2010 است نگاهی بیندازید.

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.

Joy of complete reading

Many times we need to learn new technologies. There is two major ways for reading a new technology’s book. Firstly reading miscellaneous articles and papers about that technology and second way is reading a complete book about that thing.

In first approach you find short articles or blog posts about desired subject, read it and then try to find all other parts that you need to learn. In this way there is an opportunity to consume your time in an efficient way by not reading none interesting parts of subject. And there is a threat that says you won’t create a complete picture about the subject in your mind. For example some times you will never realize if ever exists a special feature in a technology or just it is you that don’t know anything about it.

In second approach you consume more time for reading (and practicing) whole book or manual. But instead you will understand anything about it. And you will enjoy of a complete reading. Notice that in this approach you still have the chance to by pass unrelated parts.

Recently I was forced to learn SVN, a well known source code management software. As described before I preferred to use second approach by complete reading svn book. This book covers all needed commands and have been partitioned into some chapters very nicely.

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).