Что такое система контроля версий? 5 систем управления версиями с открытым исходным кодом

Система контроля версий относится к процессу, касающемуся систематизации версий, объединяемых при редактировании и совместной работе. Хотя контроль версий как термин рассматривается в контексте разработки программного обеспечения, на самом деле, он необходим для профессионалов разных отраслей.

Для крупных проектов по разработке программного обеспечения системы контроля версий отслеживают множество изменений в исходном коде.

Почему так важны системы контроля версий?

Все системы контроля версий обладают следующими возможностями:

• позволяют команде программистов одновременно работать над одним и тем же проектом;
• минимизируют конфликты между разработчиками, которые работают над одним проектом;
• автоматически создают архив каждой версии, включающий в себя все изменения проекта.

Существуют разные системы управления версиями, но какие отличительные черты делают их уникальными? Перечислим три их главные группы:

• в соответствии с расположением репозитория: централизованные и распределенные;
• в соответствии с методами проверки слияния и передачи кода: блокирующие, использующие слияние до фиксации и выполняющие фиксацию до слияния;
• системы управления версиями могут выполнять небольшие операции или операции с файлами.

5 систем контроля версий с открытым исходным кодом

CVS является самой популярной и широко применяемой системой контроля версий на сегодняшний день. После выпуска в 1986 году она быстро стала общепринятым стандартом. CVS приобрела популярность благодаря простой системе поддержки файлов и ревизий в актуальном состоянии.

Существует ряд IDE для CVS , включая Xcode ( Mac ), Eclipse , NetBeans и Emacs .

• Это проверенная временем система, которая используется более трех десятилетий;
• Существует много IDE , которые используют CVS .

• Перемещение или переименование файлов не включается в обновление версии;
• Предоставление символических ссылок на файлы связано с некоторыми рисками безопасности;
• Отсутствие поддержки атомарных операций может привести к повреждению исходного кода;
• Медленные операции установления меток и ветвления;
• Слабая поддержка двоичных файлов.

Еще одна распространенная система управления версиями. Большинство проектов с открытым исходным кодом и крупные платформы, такие как Ruby , Python Apache , используют SVN . Из-за огромной популярности существует множество версий и доступных IDE .

Достоинства системы контроля версий SVN

• Новая и значительно улучшенная система, основанная на CVS ;
• Допускает атомарные операции;
• Операции в ветке проекта малозатратны;
• Доступны различные плагины IDE .

• Выдает ошибки при переименовании файлов и каталогов;
• Недостаточно команд для управления репозиторием;
• SVN работает медленнее по сравнению с другими системами управления версиями.

Благодаря распределенной форме управления без необходимости использования оригинального программного обеспечения многие проекты с открытым исходным кодом предпочитают Git .

• Почти все отрицательные черты CVS/SVN устранены;
• Высокая скорость работы распределенной системы контроля версий;
• Легкость проведения различных операций с ветками проекта;
• Пользователи могут получить доступ к полному дереву истории в режиме офлайн;
• Предлагает высоко распределенную одноранговую модель.

• Высокий порог вхождения для пользователей SVN ;
• Ограниченная поддержка Windows по сравнению с Linux .

Mercurial

Считается эффективной для крупных проектов, в которых участвует много разработчиков и проектировщиков. Mercurial – это высокопроизводительная система, предлагающая оптимальную скорость. Она также известна своей простотой и подробной документацией.

Достоинства Mercurial системы контроля версий

• Низкий порог вхождения по сравнению с Git ;
• Подробная документация;
• Распределенная модель;
• Высокопроизводительная система с отличной скоростью.

• Нельзя объединить две родительские ветки;
• Основана на расширениях, а не сценариях;
• Недостаточно гибкая, чтобы выполнять операции по умолчанию.

Bazaar

Уникальна тем, что может использоваться с распределенной и централизованной базой кода. Это делает ее универсальной системой контроля версий. Кроме этого Bazaar позволяет использовать детальный уровень управления. Ее можно легко развернуть в самых разных сценариях, что делает ее адаптивной и гибкой для всевозможных проектов.

• Идеально подходит для разнообразных проектов;
• Предоставляет гораздо более продвинутый набор команд и поддержку IDE ;
• Включает в себя настраиваемый набор функций, который подходит для разнообразных проектов.

• Является новой и недостаточно проработанной системой управления версиями;
• Отсутствует поддержка IDE .

Что касается популярности, порога вхождения, производительности и адаптивности, рассмотренные в этой статье системы контроля версий существенно превосходят другие.

AutoLISP / VisualLISP

Памятуя о статье Коротко о системе контроля версий и подозревая, что самому масса вещей еще понадобится, за две недели нарисовал этот текст. Сначала думал сделать одну большую статью, но объем такой статьи получился запредельным (больше 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. Вот каждую из них и рассмотрим
Для установки ПО потребуются права локального администратора, для работы они уже не являются необходимыми. Также в процессе установки может потребоваться доступ в интернет. Клиенты нередко обновляются, поэтому крайне желательно время от времени проверять наличие новых версий.

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

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

Контроль версий на локальном компьютере windows

Достаточно давно пишу одну программу. Для сохранения всех данных использую бэкапы. Но вот решил использовать систему контроля версий. И так что я хочу от системы контроля версий:

1. Она должна работать на локальном компьютере и под Windows
2. Иметь как консольный так и GUI интерфейс
3. Интегрирована с Visual Studio

И тут возникают трудности: любая статья для чайников предлагает либо использовать гитхаб, либо ставить и настраивать прорву программного обеспечения (база данных, веб сервер. ). А может кто подсказать (или кинуть в меня ссылкой) как просто и быстро настроить систему контроля версий (git предпочтительней) с сервером на локальном компьютере?

2 ответа 2

1. Установка

Git не нуждается в сервере. Под Windows ставьте это: gitforwindows.org. Там есть 32- и 64-битная версия.

Вместе с git будет установлена unix-подобная консоль git-bash и GUI-инструмент. В качестве ещё одного GUI вы сможете использовать Visual Studio. Есть множество других GUI, но при умении работать через консоль и наличии полноценной IDE они вам не пригодятся.

1.1. Интеграция с Visual Studio

Если нужна интеграция с Visual Studio, вы можете установить http://gitextensions.github.io/. В комплекте есть плагин для VS. (Ссылка из комментария KoVadim)

2. Запуск и первоначальная конфигурация:

Откройте командную оболочку git-bash: кликните правой кнопкой мыши на свободном месте в любой папке и выберите пункт git bash here .

Выполните базовую конфигурацию, это нужно сделать один раз. Используйте ваше имя и принадлежащий вам почтовый ящик. Если вы настраиваете Git на рабочем месте, скорее всего вам нужно использовать рабочую почту.

И чтобы использовать окончания строк CRLF, как принято в Windows:

Вместо консольных команд можно редактировать файл конфига в любом текстовом редакторе (локальный расположен в %папка_проекта%\.git\config , глобальный в C:\Users\%имя_юзера%\.gitconfig ).

3. Начало использования

Если git bash уже открыта, перейдите в папку проекта:

Или сразу кликните правой кнопкой мыши на свободном месте в папке проекта и выберите пункт git bash here .

Теперь, чтобы создать локальный репозиторий и таким образом начать контроль версий проекта:

Система контроля версий (cvs) — Сравниваем: Git, SVN, Mercurial

У вас появилась новая замечательная бизнес-идея, связанная с разработкой ПО? Вам нужно разработать технологически сложное решение? Или у вас большая команда программистов, работающих над одной задачей? Тогда запомните эти три слова: система контроля версий .

Система контроля версий (cvs), 2017 — Сравниваем: Git, SVN, Mercurial

Система контроля версий , или vcs — это то, что не даст проекту развалиться на куски, когда над ним работает много людей. Программисты, менеджеры, копирайтеры могут работать каждый над своим кусочком, не мешая друг другу и не нанося ущерба, который невозможно было бы исправить.

Если вы еще не знакомы с концепцией системы контроля версий , то вот здесь все очень наглядно показано.

Или посмотрите видео от GitHub.

Итак, какая система контроля версий подойдет для вашего проекта?

Мы сравнили несколько популярных решений, чтобы вам было проще сделать выбор.

Это узкоспециальная техническая тема. Мы постарались сделать наш обзор понятным для всех. Но если у вас нет опыта в программировании, обязательно посоветуйтесь с вашим отделом разработки, прежде чем принимать решения.

Системы контроля версий , в том числе широко известные SVN (Subversion) и Git, изначально создавались, чтобы команды разработчиков могли работать над совместными проектами, не создавая путаницы. В системе контроля не надо самостоятельно отслеживать ветви кода и изучать примечания к ним. Вместо этого используется центральный репозиторий, где всё упорядочено, структурировано. Здесь удобно обновлять файлы, добавлять комментарии и даже проводить слияние веток проекта.

Мнения в отношении того, какая система контроля версий самая лучшая, сильно разнятся, и это приводит к бурным спорам в среде программистов. Подбирая и изучая системы контроля версий для вашего проекта, не забывайте, что преимущества того или иного решения часто субъективны. Например, личные предпочтения программиста или, скажем, такие показатели как быстродействие, возможности плагинов IDE и т.д.

Главное отличие между системами контроля версий состоит в том, какие они: клиент-серверные или децентрализованные (p2p). Есть ли у них центральный репозиторий (сервер), откуда код берется и куда возвращается с внесенными изменениями. Или это копия в локальном хранилище, обновляемая посредством пиров: более децентрализованная сеть, используемая для синхронизации, обмена патчами (наборами изменений) и для поддержки текущего кода.

Стоит также учесть быстродействие, функциональность и порог вхождения/освоения конкретной системы контроля . Рассмотрим наиболее распространенные системы контроля версий и те причины, по которым программисты предпочитают те или иные решения.

Система одновременных версий (CVS)

CVS появилась в 1980-х и до сих пор популярна как у разработчиков коммерческих продуктов, так и у open-source разработчиков.

CVS распространяется на условиях Открытого лицензионного соглашения GNU и позволяет получать с сервера нужную версию проекта — « check-out» (извлечение) , а затем пересылать обратно на сервер, « check-in» (возврат), с внесенными изменениями.

Изначально CVS была создана, чтобы избежать конфликта версий. Всем участникам для работы предоставлялась только самая последняя версия кода. Это была первая система контроля версий. Пользователю нужно было быстро фиксировать изменения в репозитории, пока другие не опередили его.

Сейчас CVS имеет поддержку работы над проектами с ветками кода. Получается несколько вариантов продукта с разными характеристиками, которые можно будет объединить позднее.

Сервера CVS обычно работают под управлением Unix, но CVS -клиенты доступны и в других популярных операционных системах. CVS — «зрелая», проверенная временем система контроля версий . Это по-прежнему опенсорсная система, но на сегодняшний день новые функции добавляются довольно редко.

При этом CVSNT, — выделившаяся в отдельный проект версия CVS для серверов Windows, — сейчас достаточно активно расширяет функционал.

Преимущества:

• Испытанная временем технология, которая удерживается на рынке десятки лет.

Недостатки:

• Переименование или перемещение файлов не отражается в истории
• Риски безопасности, связанные с символическими ссылками на файлы
• Нет поддержки атомарных операций, что может привести к повреждению кода
• Операции с ветками программного кода дорогостоящие, так как эта система контроля не предназначена для долгосрочных проектов с ветками кода

Apache Subversion (SVN)

SVN создавалась как альтернатива CVS с целью исправить недостатки CVS и в то же время обеспечить высокую совместимость с ней.

Как и CVS , SVN это бесплатная система контроля версий с открытым исходным кодом. С той лишь разницей, что распространяется под лицензией Apache, а не под Открытым лицензионным соглашением GNU.

Для сохранения целостности базы данных SVN использует так называемые атомарные операции. При появлении новой версии к финальному продукту применяются либо все исправления, либо ни одно из них. Таким образом, код защищают от хаотичных частичных правок, которые не согласуются между собой и вызывают ошибки.

Многие разработчики переключились на SVN, так как новая технология унаследовала лучшие возможности CVS и в то же время расширила их.

В то время как в CVS операции с ветками кода дорогостоящие и не предусмотрены архитектурой системы, SVN создана как раз для этого. То есть, для более крупных проектов с ветвлением кода и многими направлениями разработки.

В качестве недостатков SVN упоминаются сравнительно низкая скорость и нехватка распределенного управления версиями. Распределенный контроль версий использует пиринговую модель, а не централизованный сервер для хранения обновлений программного кода. И хотя пиринговая модель работает лучше в open source проектах, она не идеальна в других случаях. Недостаток серверного подхода в том, что когда сервер падает, то у клиентов нет доступа к коду.

Преимущества:

• Система на основе CVS
• Допускает атомарные операции
• Операции с ветвлением кода менее затратны
• Широкий выбор плагинов IDE
• Не использует пиринговую модель

Недостатки:

• Все еще сохраняются ошибки, связанные с переименованием файлов и директорий
• Неудовлетворительный набор команд для работы с репозиторием
• Сравнительно небольшая скорость

Эта система была создана для управления разработкой ядра Linux и использует подход, который в корне отличается от CVS и SVN.

В основу Git закладывались концепции, призванные создать более быструю распределенную систему контроля версий , в противовес правилам и решениям, использованным в CVS . Так как Git разрабатывалась главным образом под Linux, то именно в этой ОС она работает быстрее всего.

Git также работает на Unix-подобных системах (как MacOS), а для работы на платформе Windows используется пакет mSysGit.

Программный код может быть недоступен, когда используется компьютер без репозитория. Для решения этой проблемы есть обходные пути и некоторые разработчики полагают, что быстродействие Git является справедливой платой за неудобства.

Кроме того, в Git есть множество инструментов для навигации по истории изменений. Каждая рабочая копия исходного кода содержит всю историю разработки, что крайне полезно, когда программируешь без Интернет-соединения.

Преимущества:

• Прекрасно подходит для тех, кто ненавидит CVS /SVN
• Значительное увеличение быстродействия
• Дешевые операции с ветками кода
• Полная история разработки доступная оффлайн
• Распределенная, пиринговая модель

Недостатки:

• Высокий порог вхождения (обучения) для тех, кто ранее использовал SVN
• Ограниченная поддержка Windows (по сравнению с Linux)

Mercurial

Mercurial была выпущена одновременно с Git. Это также распределенная система контроля версий .

Mercurial создавалась в качестве альтернативы Git для разработки модулей ядра Linux. Но так как выбрали все-таки Git, то Mercurial используется меньше. Тем не менее, многие ведущие разработчики работают именно с этой системой, например OpenOffice.org .

Система контроля версий Mercurial отличается от других систем контроля версий тем, что главным образом она написана на Python (а не С). Однако, некоторые части выполнены в качестве модулей-расширений на C.

Поскольку система децентрализованная и написана на Python, многие Python-программисты склоняются к переходу на Mercurial.

Пользователи отмечают, что Mercurial сохранила некоторые характеристики SVN, являясь при этом распределенной системой, и благодаря этой схожести, порог вхождения у нее ниже для тех, кто уже знаком с SVN. Также документация по Mercurial более полная, что помогает быстрее освоиться с различиями.

Один из существенных недостатков Mercurial заключается в том, что в отличии от Git в ней нельзя объединить две родительские ветки, так как Mercurial использует систему плагинов, а не поддержку скриптов. Это отлично подходит для некоторых программистов, но многие не хотят отказываться от возможностей Git.

Преимущества:

• По сравнению с Git легче в освоении
• Подробная документация
• Распределенная модель системы контроля версий

Недостатки:

• Нет возможности слияния двух родительских веток
• Использование плагинов, а не скриптов
• Меньше возможностей для нестандартных решений

Какая система контроля версий мне подходит?

В большинстве случаев разработчики используют CVS потому что это им привычнее. Если команда уже работает над проектом, то перспектива переноса всех наработок в другую систему контроля как-то не вдохновляет. Если бы им все-таки пришлось менять систему, то, скорее всего, они переключились бы на SVN.

CVS уже достигла статуса “зрелой технологии”, а это значит, что в ней уже не появится радикально новых функций и решений. Инерция привычки теряется, так как люди переходят на SVN. А значит CVS постепенно уходит в прошлое.

Сегодня SVN удерживает пальму первенства среди серверных систем контроля версий . Она включает в себя преимущества CVS и превосходит их. Если же говорить о распространенности, то вы, скорее всего, будете чаще сталкиваться с CVS или SVN, чем с Git или Mercurial. Таким образом, знание одной серверной технологии, хотя и не является необходимым, облегчит вам переход.

Благодаря широкому использованию и зрелости технологии, в SVN накоплена большая база знаний, что дает пользователям возможность легко получать помощь.

У Git явно выше быстродействие по сравнению с конкурентами. Для проектов, которые создаются под распределенные системы контроля версий , это очевидное улучшение.

Существенным недостатком Git является то, что порой трудно объяснить нюансы работы данной системы контроля , и это тормозит рабочий процесс, пока программисты привыкают к ней. Однако, как только «порог вхождения» преодолен, продуктивность возрастает и удобство управления ветками кода сполна окупит потраченное время.

Для тех, кто терпеть не может Git (а у этой системы есть свои противники в среде разработчиков), Mercurial — это компромисс между SVN и Git. Эта система используется во многих известных проектах, а также у нее хорошая документация.

Совместимая с Windows версия Git также прогрессирует, приближаясь по своему быстродействию к Linux-версии, так что эта система может быть для вас актуальна, даже если вы не ведете разработку в Linux.

Чтобы понять, какая же лучше для вас, учитывайте особенности проекта и вашей команды. Поговорите с разработчиками!

Если для проекта требуется единое дерево исходного кода, над которым будет работать небольшая группа программистов, то SVN – это ваш вариант. Она надежна и предназначена как раз для таких случаев.

Если же вы запускаете open-source проект, над которым в разное время будут трудиться несколько программистов или, если предполагается постоянное обновление кода, то выбирайте Git. Скорость и управление деревом исходного кода здесь намного лучше, чем в SVN.

Если вы на распутье или вам просто не нравится, как работают SVN или Git, тогда к вашим услугам Mercurial.

Все эти системы полностью функциональны. А также бесплатны. Они используются для создания программного обеспечения, сайтов и даже операционных систем, которыми вы пользуетесь, и которые вам известны.

Прежде всего, решите, подходит ли та или иная система контроля версий для вашего бизнеса, а затем — что не менее важно — убедитесь, что этот выбор не приведет в ярость программистов.

Приступая к работе с SVN

Если вы никогда не работали с SVN или Git, и понятия не имеете, как начать, то хостинговое решение в сочетании с графическим интерфейсом помогут вам быстро освоиться.

Как и в большинстве случаев, самое главное — начать работу, а там уже придет понимание. Эксплуатация системы контроля версий очень похожа на работу с файлами на сервере с использованием FTP-клиента.

ПРИМЕЧАНИЕ: Есть множество хостинговых решений для системы контроля версий , в том числе с бесплатным пробным периодом. Вы можете создать на их базе свой первый репозиторий (место для совместной работы с файлами кода) совершенно бесплатно. Вот некоторые из этих сервисов:

Хостинг SVN & GIT

— безопасный, надежный и подходящий для хостинга Git и Subversion. Просмотр активности, файлов, сравнение ревизий. Отличный пользовательский интерфейс. Интеграция со многими популярными сервисами, включая Twitter! Цена вопроса: от $15 в месяц

– популярный среди разработчиков ПО хостинг для SVN, Git и управления проектами с хостинговым решением. С помощью виджета для Mac OS с простым и понятным интерфейсом вы можете следить за активностью в аккаунте во всех ваших проектах. 2 пользователя бесплатно + 1 проект с хранилищем до 200MB

– еще одна опция для бесплатного хостинга, но не такая хорошая как Unfuddle. 1 пользователь бесплатно + 1 проект с хранилищем до 100MB

– хостинг Subversion, Git и Mercurial. Отличное соотношение цены и функционала. От $5 в месяц, неограниченное число проектов, пользователей и хранилище до 2GB

Создание первого репозитория

После того как вы создали аккаунт, необходимо создать репозиторий — для каждой платформы отдельно. Обычно это выглядит так:

• Войдите в свой аккаунт, кликните по вашим проектам.
• Создание проекта:

• В строке «Create a New Project» введите имя вашего проекта
• Кликните по кнопке «Create Project»

• Подключение SVN:

• После создания проекта, выберите вкладку «Source Control» (версиями исходного кода)
• Кликните по ссылке «Enable Source Control»
• Присвойте репозиторию имя
• Нажмите «Save»

Графические клиенты SVN и GIT

Итак, репозиторий создан. Теперь нужно, чтобы в нем все отображалось просто и наглядно. Для этого вам понадобится графический интерфейс.

— удобная программа для работы с системами контроля версий в Microsoft Windows и, возможно, лучший из представленных Apache Subversion клиент. TortoiseSVN реализован как расширение оболочки Windows, что позволяет легко интегрировать его в браузер. Кроме того, это программа с открытым исходным кодом, для которой доступны 34 языковых пакета

– графический клиент Git (Open Source распределенная система контроля версий ). Работает в Windows, Mac OS X и Linux. Стоимость лицензии — $39

– SVN клиент для MAC OS X – Versions: простейшая с истема контроля версий для Mac. По их собственным словам: «Благодаря нашему подходу, вы сможете начать без раскачки». Данный клиент прост в использовании. Цена вопроса: £39 (примерно $50 согласно текущему курсу)

– Клиент GIT для MAC OS X – еще одно элегантное решение, идеально подходящее для пользователей GIT, которые уже знакомы с синтаксисом командной строки. Есть также хороший ознакомительный обзор продукта, содержащий множество базовых концепций GIT (см. ниже).

примерно $50 за лицензию, доступны менее затратные мульти-лицензионные опции.

«Извлечение» репозитория (“Checkout”)

Итак, клиент выбран. Теперь необходимо создать репозиторий для системы контроля. Нужно ввести URL-адрес вашего репозитория, имя пользователя и пароль.

URL-адрес обычно выглядит так: https://svn .hostname.com/svn/ > (вы можете использовать https:// (SSL), если у вас платный аккаунт)

1. Перейдите в корневую папку, нажмите кнопку «Check Out» («Извлечение») и создайте рабочую папку для клиента. Теперь вы можете добавлять в нее файлы.
2. После извлечения файлов проекта вы сможете редактировать их в локальной директории на вашем компьютере.

После внесения изменений в файлы для их сохранения нажмите кнопку «Check-in» («Возврат») на панели инструментов. Вы можете просматривать изменения и добавлять к ним комментарии — это довольно хорошая идея, так как в дальнейшем вы будете точно знать, над чем работали, какие изменения внесены и будете держать в курсе других участников проекта.

В вашем клиенте также должна быть предусмотрена возможность в любой момент начать работу с ревизиями, открыв журнал ревизий или историю изменений — тогда, если понадобится, вы сможете сделать «откат» к предыдущей версии для каждого файла в отдельности. Теперь, когда вы знакомы с базовыми концепциями, документация системы контроля версий послужит вам хорошей отправной точкой для освоения ее расширенных функциональных возможностей.

Мнения Клиентов Тайм Доктор: