Subversion (SVN) TortoiseSVN NetBeans IDE

В этой статье я не буду Вам рассказывать что такое Subversion (SVN). TortoiseSVN. NetBeans IDE. Я лишь покажу как установить и использовать это все добро вместе. Лишь вкратце скажу:
Subversion (SVN) — свободная централизованная система управления версиями. (материал из ВИКИпедии).
TortoiseSVN — клиент для Subversion. выполненный как расширение оболочки Windows. (материал из ВИКИпедии).
NetBeans IDE — свободная интегрированная среда разработки приложений (IDE) на разных языках программирования.

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

• http://switch.dl.sourceforge.net/project/tortoisesvn/Documentation/1.6.6/TortoiseSVN-1.6.6-ru.pdf — Документация по TortoiseSVN. описание что это вообще такое, установка, настройка, ежедневное использование. Рекомендую как обязательный документ для прочтения.
• http://svnbook.red-bean.com/ — Отличная книга по использованию Subversion (SVN) на русском

• http://www.collab.net/downloads/subversion/ — Subversion (SVN) (Заранее настроенный и готовый к использованию сервер SVN) — CollabNetSubversion-server-1.6.6-4.win32.exe
• NetBeans — (ранее я писал об установке и загрузке данной IDE) — netbeans-6.7.1-ml-php-windows.exe
• http://tortoisesvn.net/downloads — TortoiseSVN (На этой странице Вы сможете скачать саму оболочку и русификатор, также сможете скачать обучающий материал по TortoiseSVN) — TortoiseSVN-1.6.6.17493-win32-svn-1.6.6.msi, LanguagePack_1.6.6.17493-win32-ru.msi

В итоге после загрузки у Вас на компьютере должно быть 4 файла:

Только обязательно обратите внимание на версии ваших файлов, все три файла для работы Subversion (SVN) и TortoiseSVN и русификатор TortoiseSVN должны быть одной какой то версии, в данном контексте это версия 1.6.6 .

• CollabNetSubversion-server-1.6.6-4.win32.exe — Вы может спросите почему не установить SVN, это конечно же Ваше личное дело, но установка данной сборки упрощает и ускоряет установку и настройку в качестве использования локального(на Вашем компьютере) хранилища Subversion (SVN). Этот установщик настроит запуск svnserver в качестве службы Windows, а также в него включены некоторые инструменты которые Вам могут понадобиться. При установки практически не каких проблем не возникает лишь только нужно нажимать кнопку Next->. Единственное что в процессе установки придется выбрать папку в которой будут храниться ваши репозитарии, можно оставить по умолчанию(C:\svn_repository ). Чтобы проверить установку Subversion (SVN), в командной строке Windows следует ввести — svn —version. если Вы все сделали правильно то вы должны увидеть следующее:

• После установки оболочки TortoiseSVN в меню правой кнопки мыши появятся новые пункты меню, с помощью которых можно будет работать с Subversion (SVN). Для нормальной работы русифицированной оболочки требуется сделать следующие действия:
• Открыть меню кликнув в любом месте правой кнопкой мыши, выбрать TortoiseSVN->Settings. после чего откроется окно настроек показанное ниже на рисунке.
• В главном разделе окна настроек (General ), выбрать Language: русский. После чего нажать на кнопку Применить. После этого TortoiseSVN будет говорить с Вами на русском языке.

Теперь все готово для того чтобы использовать Subversion (SVN) с NetBeans IDE .

• Первое что надо сделать — зайти в настройки NetBeans и показать NetBeans где находится Subversion (SVN) для этого заходим Сервис->Настройки->Разное->Управление версиями->Subversion. и в поле Путь к программе SVN вписываем C:\Program Files\CollabNet\Subversion Server. После чего нажимаем на кнопку ОК .

Subversion инструкция на русском

Данная статья открывает цикл статей о работе с Subversion — системе управления версиями. Системы управления версиями в основном используются программистами, но система Subversion может быть полезна не только разработчикам, но и более широкому кругу людей, которым приходиться работать над большим числом текстовых или относительно небольших файлов, периодически вносить в них изменения, что-то переделывать, возвращаться к более старым вариантам файлов. Поэтому часть или даже все статьи из этого цикла будут ориентироваться на простых людей не обязательно связанных с разработкой программного обеспечения, статьи должны быть достаточно просты для понимания и с большим числом конкретных практических примеров и приемов работы. В данной статье я постараюсь объяснить кому может быть полезен Subversion.

В данной статье мы базовые методы работы с системой управления версиями Subversion на примере оконных svn-клиентов TortoiseSVN (для Windows) и kdesvn (для Linux).

Программы для работы с Subversion называются svn-клиентами, от названия svn — утилиты командной строки из официального пакета Subversion. Кроме официального пакета есть множество сторонних программ реализующих функции svn-клиента.

В большинстве аналогичных статей по началам управления версиями в Subversion в примерах используется официальный пакет Subversion, который предоставляет набор утилит командной строки. Его можно скачать с сайта http://subversion.tigris.org/. Так как данный цикл статей ориентируется не только на разработчиков, но и на простых людей, то большая часть примеров будет рассматриваться на основе оконных svn-клиентов.

Для пользователей операционной системы Windows рекомендую использовать TortoiseSVN: http://tortoisesvn.net/. После установки он встраивается в Проводник (Explorer), благодаря чему мы получаем файловый менеджер с поддержкой svn-клиента. Однако TortoiseSVN можно использовать совместно с другим не менее популярным файловым менеджером Total Commander, после небольшой настройки последнего.

Для пользователей Linux (и других Unix-подобных операционных систем) можно привести более широкий список svn-клиентов, однако все известные автору данной статьи svn-клиенты схожи друг с другом как братья близнецы. Все svn-клиенты под Linux можно условно разделить на два класса — самостоятельные svn-клиенты (kdesvn, RapidSVN, Subcommander), и оконные оболочки для консольных утилит Subversion (eSVN). Автор очень скептически и недоверчиво относиться к оконным оболочкам вообще и в частности рекомендует использовать самостоятельные svn-клиенты. В статье примеры будут рассматриваться на примере kdesvn 0.12.1.

Мы будем рассматривать Subversion от простого к сложному, потому начнем с тривиальных вещей, которыми можно воспользоваться не вдаваясь дебри теории. Subversion использует клиент-серверную модель: есть сервер который хранит все необходимые данные и клиенты, которые получают данные от сервера, модифицируют их и отправляют обратно серверу. Сервер Subversion управляет хранилищем (repository, репозитарий) файлов. Чтобы работать с этими файлами нужно получить их копию с помощью svn-клиента. Хранилище указывается с помощью ссылки, например http://example.com/Repos или svn://example.com/Repos. Как видите Subversion поддерживает несколько протоколов (http://, svn://, file://. ssh+svn://). Число протоколов не фиксировано и в будущем могут появляться новые протоколы, всё что нам сейчас нужно знать, так это то, что хранилище указывается ссылкой.

Для получения копии файлов используется команда checkout (примечание, пока нет устоявшихся переводов названий команд на русский язык, потому я привожу английский вариант и возможные переводы на русский язык), в kdesvn это пункт меню «Subversion/Общие/Получить из репозитария» (пункт меню продублирован на панели инструментов). Когда вы его выбираете перед вами появляется диалоговое окно.

В самом первом поле «Введите URL» нам предлагают ввести URL хранилища, во втором «Укажите целевой каталог» нужно указать пустую папку, куда будут скопированы файлы из хранилища. Далее предлагается выбрать правку. О том, что такое правка мы поговорим далее, сейчас же просто выберем HEAD (последняя). Это три основных параметра для получения копии. Далее можно отметить дополнительные параметры, для начала я рекомендую снять галочку с параметра «Append source url name subfolder» и установить «Рекурсивно». После чего нажимаем на кнопку «ОК». Если вы ввели все правильно, то svn-клиент начнет скачивать с сервера рабочую копию. Попробуйте сделать это, для примера вы можете указать ссылку svn://svn.shamangrad.net/test

Примечание: кроме собственно копий файлов, svn-клиент создаст скрытые каталоги с файлами, в которых хранится служебная информация для svn-клиента. Их не стоит удалять, переименовывать или править. Чтобы получить чистую копию без этой служебной информации используется команда export (экспорт), но об этом позже.

Итак, в указанном каталоге вы получили копию файлов. Эта копия называется «рабочей копией» (working copy). Полученные файлы можно редактировать.

Отредактируем какой-нибудь файл. После того, как мы его отредактируем и сохраним. Файлы которые были измены будут отмечены как измененные (modified). В хорошем svn-клиенте также будут отмечены каталоги в которых были изменены файлы (и не важно на каком уровне вложенности файла), но к сожалению не все svn-клиенты умеют это делать (kdesvn 0.12.1 умеет это делать см. рис 3).

После того, как вы отредактировали файлы их можно зафиксировать в хранилище (commit), для этого используется команда commit (зафиксировать). Вы выделяете файл или каталог изменения которых вы хотите зафиксировать и в контекстном меню выбираете пункт «зафиксировать изменения». Перед нами появиться диалоговое окно.

В верхнем списке нам предлагают отметить те файлы изменения которых мы хотим зафиксировать. В низу в поле «Enter a log message» (введите сообщение для журнала) можно и желательно ввести краткое сообщение описывающее внесенные вами изменения. Позже можно будет просматривать эти сообщения и, в случае необходимости, будет проще понять что выделали в тот или иной момент. В качестве дополнительного параметра нам предлагают отметить пункт «Keep locks» (удерживать блокировки). О блокировках будем говорить позже, по умолчанию эта опция не отмечена и отмечать её не нужно. Нажимаем кнопку «ОК» и, если все было сделано правильно, наш svn-клиент начнет отправлять наши изменения на сервер.

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

Если вы просто создадите новый файл или каталог, то svn-клиент отметит его как «Вне контроля версий».

Дело в том, что сервер и svn-клиент управляет только теми файлами и каталогами, которые вы явно указываете с помощью команды add (добавить). Чтобы добавить новый файл или каталог под контроль версий (отметить на добавление в хранилище) нужно выделить файлы и в контекстном меню выбрать пункт «Добавить выбранные файлы/каталоги» или через главное меню «Subversion/Рабочая копия/Add selected files/dir recursive» (добавить выделенные файлы/каталоги рекурсивно, т.е. со всеми вложенными файлами и каталогами). После добавления файла он будет отмечен «Добавлен локально» и при следующей фиксации он будет записан в хранилище.

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

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

Как писалось выше хранилище и svn-клиент отслеживают структуру файлов и каталогов. Поэтому, если вам нужно удалить файл из хранилища, то это нужно указать явно — нельзя просто взять и удалить файл/каталог из рабочей копии и надеяться, что всё будет так как вам хочется. Для удаления файлов и каталогов находящихся под контролем версий используется команда svn delete (удалить). Для это нужно выделить файлы и каталоги, который мы хотим удалить и в контекстном меню выбрать пункт «Удалить» и выбранные вами файлы будут удалены, а каталоги будет отмечены на удаление и при следующей фиксации они будут окончательно удалены из хранилища и рабочей копии.

Рис 9. Удаление файлов и каталогов, находящихся под контролем версий

Вы получили рабочую копию, начали править файлы, добавлять новые, удалять старые и т.д. Допустим вы где-то ошиблись: удалили не тот файл, добавили файл который не нужно было добавлять или неудачно отредактировали какой-то файл и хотите отменить это редактирование. Пока вы не зафиксировали изменения на сервере, вы можете их отменить локально. Вы можете отменить изменения в любом отдельно взятом файле, можете убрать с файла пометку на удаление или добавления. Все эти операции объединяются одной операцией — «отменой» (svn revert). Как писалось выше, svn-клиент создает скрытые каталоги в которых храниться служебная информация, в частности там хранятся копии всех файлов в том виде, как они были получены с сервера. С помощью этих скрытых копий и производиться отмена изменений.

Для того, чтобы отменить изменения нужно выделить файлы и каталоги изменения в которых мы хотим отменить и выбрать пункт главного меню «Subversion/Рабочая копия/Revert current changes». Перед нами появиться диалоговое окно, которое покажет нам список файлов в которых будет отменены изменения и запросит подтверждение на отмену.

Когда мы фиксировали изменения, мы оставляли короткие комментарии фиксируемых изменений. Как писалось выше мы можем просматривать журнал изменений любого файла или каталога. Для этого выделим файл или каталог, в главном меню выберем «Subversion/Общие/Полный журнал» и перед нами откроется окно журнала изменений.

Здесь можно просмотреть все изменения которые были зафиксированы на сервере, просмотреть комментарии, узнать какие файлы были добавлены, удалены или обновлены.

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

Под «атомарной транзакцией» понимается следующие: либо в хранилище вносятся все изменения полностью, либо не вносятся вообще. Subversion ведёт себя так, принимая в расчет возможные программные сбои, системные сбои, проблемы с сетью, а также неверные действия пользователя.

Каждый раз, когда происходит фиксация, создаётся новое состояние файловой системы, которое называется «правка» (revision). Каждая правка получает уникальный номер, на единицу больший номера предыдущей правки. Начальная правка только что созданного хранилища получает номер 0 и не содержит ничего, кроме пустого корневого каталога.

В отличие об обычной файловой системы, хранилище Subversion хранит все версии файлов и мы в любой момент можем получить старую версию отдельного файла или дерева каталогов. Когда мы создавали рабочую копию в диалоговом окне см рис. 1 нам предлагали указать номер правки. Мы указывали HEAD — что означало выбор последней правки, но мы могли указать любую другую правку по её номеру. Попробуйте.

Чтобы получить более раннюю правку не обязательно делать создавать новую рабочую копию. Вместо этого можно перевести нашу рабочую копию (или даже отдельные файлы) на другую правку. Для этого выберем интересующий нас файл или каталог (для начала лучше выберите корневой каталог нашей рабочей копии), потом в главном меню выбираем «Subversion/Рабочая копия/Обновиться до правки». Перед нами появиться диалог.

Мы выбираем номер правки и нажимаем «OK». Необходимость в переходе к более старым правкам возникает крайне редко. В случае, если с хранилищем работает несколько человек, то чаще возникает необходимость в переходе к последней правке для того, чтобы получить с сервера изменения, которые внесли другие пользователи. Для этого есть отдельный пункт меню «Обновиться до HEAD» (или svn update).

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

Вы уже научились добавлять файлы под контроль версий. Поэтому эта операция вас не поставит в тупик. Вы просто скопируете файл/каталог и добавите его под контроль версий и это вполне допустимо. Однако, есть и другой способ. Если вы хорошо поэкспериментировали с просмотром журнала изменений, то вы уже обратили внимание на то, что Subversion запоминает историю всех изменений каждого файла. Если вы просто скопируете файл как обычно и добавите его под контроль версий, то Subversion будет думать что это новый файл и начнет вести для него новую историю изменений. Однако, можно указать Subversion, что вы не просто хотите добавить новый файл или каталог, а скопировать файл/каталог со всей историей изменений. После подобного копирования у нас будет два файла которые имеют общую историю изменений, но далее они будут жить каждый своей жизнью. Рассмотрение всех нюансов копирования выходит за пределы данной статьи, сейчас же нужно только сказать, что если речь идет действительно о копировании файла/каталога то нужно воспользоваться командой svn copy (копировать). Для выделяем интересующий нас файл/каталог после чего в главном меню выбираем «Subversion/Общие/Копировать». После чего появиться диалог, который спросит у нас куда мы хотим скопировать наш файл/каталог.

Для упражнения скопируйте какой-нибудь файл и зафиксируйте это изменение. После чего просмотрите и сравните истории изменений нового и старого файла. Чем отличаются их истории изменений?

Для перемещения и переименования файлов/каталогов также есть специальная команда svn move (Переместить). Фактически в Subversion нет понятия перемещения — данная команда вводиться только для удобства и на самом деле является комбинацией двух других операций: svn copy (копирование) и svn delete (удаление). Файл сначала копируется, а потом старый файл отмечается как удаленный. Для того, чтобы переместить файл/каталог под контролем версий нужно выделить перемещаемый файл/каталог, затем в главном меню выбрать пункт «Subversion/Общие/Переместить», после чего появиться диалог аналогичный как при копировании файла.

Практическое краткое руководство по Subversion (SVN) и Git для начинающих

Материал страницы находится в разработке!

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

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

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

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

Subversion — система управления версиями в свободной лицензии. Известна под сокращенным именем SVN. Разработка Subversion началась в 2000 году по инициативе и финансовой поддержке компании CollabNet Inc.

Основной целью проекта Subversion считается замена устаревший, на тот момент системы контроля версий CVS (Concurrent Versions System). Новый проект должен был сохранить всю функциональность CVS и избавиться от ряда его недостатков.

Официальный выпуск Subversion — 2004 год.

Разработка Git началась в 2005 году, по инициативе разработчика Linux — Линуса Торвальдса.

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

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

1. Lock-Modify-Unlock — чтобы внести изменение, надо заблокировать файловое хранилище, выполнить изменение и, после этого, разблокировать (вернуть в общее пользование). Такая схема может работать в полностью автоматическом режиме, так как исключает возможные коллизии изменений, и используется в многопоточном программировании для защиты критических секций данных. В файловых репозиториях, такая схема не удобна, так как исключает возможность параллельной работы пользователей над изменением файлов.
2. Copy-Modify-Merge — каждый из пользователей работает со своей копией данных, которая потом синхронизируется с состоянием центрального репозитория. Недостатком таких схем является необходимость ручного вмешательства в процесс синхронизации разных копий, если в них содержатся изменения одного и того же фрагмента данных.

Обе системы, Subversion и Git, используют вторую схему разделения данных (Copy-Modify-Merge ), но делают это немного по-разному.

SVN относится к типу централизованных систем. в отличии от Git и Mercurial, которые являются представителями класса распределенных систем. Централизованность означает работу схемы только при наличии централизованного хранилища данных.

Развертывание системы Subversion может опираться на две разные физические системы хранения данных репозитория. Исторически, первый вариант организации репозитория был основан на использовании СУБД Berkeley DB. Позже, была выполнена реализация на основе специального файлового хранилища данных (FSFS), поддерживаемое собственными программными библиотеками. Начиная с релиза 1.2 для новых хранилищ, по умолчанию, используется FSFS.

Реализацию на основе СУБД Berkley DB можно считать более капризной. Во-первых, ее настройка требует большего внимания администратора. Во-вторых, Berkley DB требовательна к выбору низлежащей файловой системы — она должна поддерживать блокировки.

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

Репозиторий проекта может быть логически представлен двумерным массивом в котором вертикальным индексом является имя файла, а горизонтальным — номер ревизии — целое
число, растущее при каждой фиксации кода в хранилище. Каждая выборка из репозитория представляет собой «срез» файлов по номеру ревизии. Если номер ревизии не указывается
(обычно через опцию -r), то берется самый последний номер ревизии.

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

SVN vs Git. Здесь мы наблюдаем существенное различие в использовании, и, особенно,
администрировании систем SVN и Git. В Git, под каждый проект в любой директории
можно реализовать работу локального репозитория, чего, часто, для индивидуальной
работы, бывает достаточно. Централизованный репозиторий, при его необходимости,
так же организуется под каждый проект отдельно, позволяя для каждого проекта
построить свою политику прав доступа. Если быть более точным, то Git значительно
сосредоточен именно на средствах управления версиями и, при использовании
централизованных репозиториев, для тонкого разделения доступа к коду проекта
множества пользователей удобнее использовать дополнительные оберточные средства
администрирования Git. Cреди последних, известными являются gitolite и gitosys.

Различают понятия стержневых ревизий (peg revision) и оперативных ревизий (operative revision). Стержневая ревизия представляет собой номер ревизии предназначенный для уточнения файловых историй для оперативных ревизий по которым выполняются операции команд. Т.е. Команда может быть задана по диапазону оперативных ревизий в которых может быть коллизии файловых историй связанных с операциями копирования, перемещения и уничтожения файлов. Чтобы однозначно указать требуемую файловую историю необходимо указывать стержневую ревизию по правому краю диапазона оперативных ревизий, так как история файла однозначно отслеживается только в обратном направлении. При
отслеживании истории в прямом направлении можно столкнуться, например, с разветвлением, созданным при копировании файла. Работа пользователя с файлами проекта выполняется в рабочей копии репозитория, которая создается получением файлового снимка всего репозитория SVN или его части (через уточнение нужной поддиректории) с помощью операции svn checkout (по умолчанию будет передана последняя ревизия). Если пользователь хочет зафиксировать изменения в репозитории проекта, то он должен выполнить операцию svn commit. При каждой фиксации кода создается новая ревизия с большим номером.

Основная суть организации репозитория Git в том, что он хранит файлы в виде файлов, а в качестве имени файла в репозитории используется значение хэш-функции SHA1, вычисленной по содержимому файла.

Таким образом, одинаковые файлы имеют одинаковое значение хеш-функции и хранятся один раз.

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

Объекты репозитория Git бывают четырех типов — blob, tree, commit и tag.

Справочная информация по командам svn может быть получена обращением к самой утилите svn через команду svn help. Введя эту команду в консоли, вы получите полный список всех команд поддерживаемых текущей версией утилиты svn. Для получения информации по конкретной команде надо добавить ее после help. Например:

svn help checkout
svn help commit
svn help mkdir

Продумаем размещение и выберем имя для директории будущего репозитория SVN. При этом подумайте о правах доступа, если репозиторий будет разделяемый. Для простоты я
сделаю репозиторий в своем домашнем каталоге /home/knz с именем 0-svn-repository. Имя начинающееся с нуля предоставит дополнительный приоритет для данной директории для
многих типов сортировок при выводе списка директорий и такая директория не затеряется в окружении многих других директорий домашнего каталога.

Находясь в домашней директории выполним команду.

svnadmin create 0-svn-repository

Репозиторий создан. Пустой репозиторий имеет нулевой номер ревизии. Теперь в него можно добавлять проекты для управления. Дальнейшая последовательность действий может быть такая.

1. Создадим где-нибудь начальный оригинал будущего проекта.
2. Выполним импорт этого оригинала проекта в репозиторий SVN с помощью команды svn import.
3. Оригинал проекта теперь стратегического смысла не имеет и его можно удалить.
4. Создаем рабочую копию проекта из репозитория SVN с помощью команды svn checkout.
5. Работаем с рабочей копией, вносим в нее изменения. Чтобы зафиксировать изменения необходимо передать их в репозиторий SVN с помощью команды svn commit. При
   этом, в репозитории проекта, будет создана очередная по счету ревизия.

Игнорирование файлов SVN
Сделать файл list с именами или масками, разделённые переводом строки
$ svn propset ‘svn:ignore’ -F list