Как установить TortoiseSVN и произвести свои первые изменения в репозитарии


Как отметил Джо, TortoiseSVN имеет собственный синтаксис командной строки. К сожалению, это довольно уродливо, если вы привыкли к командам и игнорируете текущий рабочий каталог, поэтому он не очень полезен — кроме сценариев.

Я создал небольшую программу Python ( ), которая имитирует синтаксис командной строки и соответственно вызывает TortoiseSVN. Таким образом, разница между вызовом обычных инструментов командной строки и вызовом TortoiseSVN сводится к маленькой букве в начале.

Моя программа еще не завершена, но уже полезна. Его можно найти в cheeseshop ( https://pypi.python.org/pypi/tsvn/ )


Мое исправление для получения команд SVN состояло в том, чтобы скопировать файлы .exe и .dll из каталога TortoiseSVN и вставить их в папку system32.

Вы также можете выполнить команду из каталога TortoiseSVN и добавить путь к рабочему каталогу каждой команде. Например:

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

Содержание

Информация


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

  1. Определение пути в переменных среды:

    • откройте « Свойства системы »;
    • на вкладке « Дополнительно » нажмите кнопку « Переменные среды »
    • в разделе « Системные переменные » выберите опцию « Путь » и нажмите « Изменить »,
    • добавьте значение переменной с помощью пути к файлу TortoiseProc.exe , например:

      C: \ Program Files \ TortoiseSVN \ bin

  2. Поскольку вы зарегистрировали TortoiseProc , вы можете использовать его в соответствии с документацией TortoiseSVN.

    Примеры:

    TortoiseProc.exe / command: commit /path:»c:\svn_wc\file1.txt*c:\svn_wc\file2.txt «/ logmsg:» сообщение протокола теста «/ closeonend: 0

    TortoiseProc.exe / команда: update / path: «c: \ svn_wc \» / closeonend: 0

    TortoiseProc.exe / команда: log /path:»c:\svn_wc\file1.txt «/ startrev: 50 / endrev: 60 / closeonend: 0

PS Чтобы использовать дружественное имя типа ‘svn’ вместо ‘TortoiseProc’, поместите файл ‘svn.bat’ в каталог ‘TortoiseProc.exe’. Пример svn.bat:


После выбора «инструментов командной строки SVN» это будет выглядеть следующим образом:


Моим решением было использовать DOSKEY чтобы настроить некоторые псевдонимы для тех команд, которые я использую больше всего:

Google «doskey persist» для подсказок о том, как настроить файл .cmd, который запускается каждый раз, когда вы открываете командную строку, например. * Rc-файл в Unix.

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

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

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

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

Git

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

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

Технические вопросы устройства

Две концепции, используемые для разделения файлов

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

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

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

Физическое представление репозитория

Subversion

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

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

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

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

Логическое представление репозитория

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

Примечание: картинка взята со страницы https://ru.wikipedia.org/wiki/Subversion

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

SVN vs Git.

Настройка SVN

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

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

Git

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

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

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

Логическое представление репозитория

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

Использование систем контроля версий

Получение справочной информации

Subversion (SVN)

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

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

Subversion (SVN)

Продумаем размещение и выберем имя для директории будущего репозитория 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

Subversion (SVN), Системы контроля версийsubversion, svn, svn vs git, для начинающих, краткое руководств, руководствоknzroot

Forthcoming Releases

To find out what is happening with the project and when you can expect the next major release, take a look at our project status page.

Stable Branch Builds

We maintain ongoing Release Candidates as well. These contain the latest official release plus latest bugfixes and will eventually become the next official release. They are not built nightly, but on demand from the current release branch, typically once a week if there has been any significant bugfix activity. If you find that a certain bug has been fixed and you do not want to wait until the next release, install one of these. Because they are built from the stable branch they should be completely compatible with the current official release and with other compatible Subversion clients. You would also help us tremendously by installing and testing release candidates. Note that the stable branch accepts bugfixes only, not new features.

Trunk Nightly Builds

Nightly Builds are available too. They are built from the current development head and are for testing only. This represents the bleeding edge and may be linked against a newer version of the subversion libraries than is used for the current release. Working copies may be upgraded automatically and become incompatible with the official release and with other subversion clients. We would love you to test these builds, but you should be aware of the potential problems and install only on a machine where your working copies are not critical.

Tortoisesvn как пользоваться

Note: This requires Windows Vista SP2 or above. Windows 7 must have SP1 installed.

Older Releases

Older releases are available from the OSDN.net files section.

Source Code

TortoiseSVN is under the GPL license. That means you can get the whole source code and build the program yourself.
The source code is hosted on osdn.net in our own Subversion repository. You can browse the source code with your favorite web browser directly on the repository.
If you have TortoiseSVN installed, you can check out the whole source code by clicking on the tortoise icon below:

Добавить комментарий

Закрыть меню