Системы контроля версий и клиенты для Windows

Памятуя о статье Коротко о системе контроля версий и подозревая, что самому масса вещей еще понадобится, за две недели нарисовал этот текст. Сначала думал сделать одну большую статью, но объем такой статьи получился запредельным (больше 5 метров со всеми картинками), поэтому разбил на несколько кусочков.
Получился небольшой цикл из 4 статей (включая эту), посвященный работе с 3 клиентами cvs: TortoiseSVN, SourceTree и GitExtensions. Разбирался с ними по русскому принципу - т.е. инструкцию начинал читать только когда понимал что "все, звездец, сломал". Так что особо строго не судите

Это модное и не очень понятное слово "дисклайм"
Ну как бы предупреждение по принципу "кто не спрятался, я не виноват", "я не несу никакой ответственности бла-бла-бла", "это не мануал, а просто рассказ о моих поисках" и т.д.
Это всего лишь рассказ о собственных мучениях при выборе системы контроля версий и небольшая попытка свести все воедино. Ну и плюс, как обычно, шпаргалка для себя любимого – чтобы не забыть, что, откуда, как и почему. Если не испугал – добро пожаловать
Чуть-чуть о системах контроля версий
В свое время остро встал вопрос с хранением исходных кодов, компилированных вариантов (chm, в частности, под понятие компилированных подошел как нельзя более кстати) файлов и, что самое главное, истории их изменения. Крайне желательно иметь историю с комментариями – кто чего сделал и почему.
Такие системы есть, называются Control Version System (сокращают как CVS или VCS - где как), или системы контроля версий. Все хорошо, но надо выбрать наиболее удобную (для конечного пользователя) и гибкую (это уже для поисков "кто чего натворил"). Прежде чем приступать к экспериментам, дадим некоторые вводные условия:

1. Клиентская программа (или клиент) работает под Windows. Без вариантов. Должна работать и под 32, и под 64 бита. Бесплатна и эта бесплатность – официальная.
2. Есть сетевой диск с большим количеством информации на нем. Отслеживать изменения надо только для некоторых папок / каталогов.
3. Вся работа выполняется в условиях недоступности интернета (но софт скачать можно).

В принципе, этого достаточно. Примем также идею, что есть некое центральное хранилище (т.н. "репозиторий"), в котором собственно и хранятся все данные (возможно, в каком-то не очень доступном виде). Есть "рабочие" копии, внутри которых хранятся файлы уже в привычном для человека виде. При этом "рабочей" копией является и сам сетевой диск. Клиентская программа должна позволять быстро и просто как вносить изменения в центральный репозиторий, так и восстанавливать их оттуда.
Вроде ничего не забыл
Естественно, что обязательно должен предоставляться вариант "посмотреть, что и где изменилось". Естественно, что должен быть вариант разрешения конфликтов, неизбежно возникающих при слиянии с центральным репозиторием.
Это модное и не очень понятное слово "дисклайм"
Все эксперименты провожу над Windows 7 Pro x32, со всеми обновлениями. Никакого стороннего софта на компьютере нет вообще (даже антивирус не установлен). Единственное, что изменил – отключил UAC, поскольку каждый раз говорить, что "да, я знаю, чем это грозит; да, я согласен внести изменения" - утомляет.
Примем, что на локальном компьютере есть каталог c:\git_test, преобразованный в сетевой диск v: командой subst, выполненной в командной строке Windows:

Все, виртуальный диск создан и подключен.

В этот каталог поместим несколько подкаталогов – как тех, которые надо отслеживать, так и "лишних" с точки зрения системы контроля версий. Кроме того, поместим несколько файлов напрямую в "сетевой" диск – тоже для имитации реальной ситуации и для того, чтобы научиться такие файлы игнорировать (целиком или частично). Общий объем перебрасываемой информации – около 2 ГБ, отслеживать надо около 200 МБ (если конкретнее – то каталоги Apps, dotnet, Settings).
Наш центальный репозиторий будем располагать на этом же диске. Для этого создадим там каталог VersionControl. Естественно, что VersionControl надо будет исключать из отслеживаемых каталогов.

Выбор системы контроля версий
Иногда (точнее, не иногда, а почти всегда) ситуация складывается так, что приходится выполнять как бы ветвление разработки. Т.е. выполнять отдельную разработку какого-либо куска кода. При этом внесение этих изменений не должно затрагивать основную массу исходников. Такое понятие тоже есть, называется "Ветка", или "Бранч" (Branch). Ветки потом можно забросить или "слить" с основным потоком разработки.
Т.е. теоретически используемая система должна все это поддерживать и спокойно со всем этим богатством работать. При этом (повторюсь) работать надо из-под Windows и крайне желательно с GUI-интерфейсом. Командную строку я, конечно, уважаю, но не до такой степени, чтобы становиться юниксоидом ради одной утилитки
Не очень продолжительный поиск привел к выбору между SVN и GIT. Вот каждую из них и рассмотрим
Для установки ПО потребуются права локального администратора, для работы они уже не являются необходимыми. Также в процессе установки может потребоваться доступ в интернет. Клиенты нередко обновляются, поэтому крайне желательно время от времени проверять наличие новых версий.

Краткое содержание следующих серий

К сожалению, только сейчас сообразил, что не рассмотрел вариант конфликта версий или веток Ну не получилось у меня пока что наступить на эти грабли Как только столкнусь - расскажу (если не забуду, конечно)