Знаймо

Додати знання

приховати рекламу

Цей текст може містити помилки.

Subversion


Subversion.png

План:


Введення

Subversion [1] (також відома як "SVN" [2]) - вільна централізована система управління версіями, офіційно випущена в 2004 компанією CollabNet Inc.

Мета проекту - замінити [3] [4] собою поширену на той момент систему Concurrent Versions System (CVS), яка нині вважається застарілою [5] [6] [7]. Subversion реалізує всі основні функції CVS і вільна від ряду недоліків останньої.

В даний час Subversion використовується багатьма спільнотами розробників відкритого програмного забезпечення (у тому числі спільнотами, раніше використовували CVS). У їх числі такі відомі проекти, як Apache, GCC, Free Pascal, Python, Ruby, Mono, FreeBSD, Haiku, AROS і MediaWiki. Subversion також широко використовується в закритих проектах і корпоративній сфері. Хостинг Subversion, у тому числі для проектів з відкритим кодом, також надають популярні хостинг-проекти SourceForge.net, Tigris.org, Google Code і BountySource.

В 2007 незалежна компанія Forrester Research, порівнюючи переваги та недоліки різних систем, оцінила Subversion як "одноосібного лідера в категорії Standalone Software Configuration Management (SCM) і сильного учасника в категорії Software Configuration and Change Management (SCCM)". [8]

За даними статистики використання пакетів Linux - дистрибутивів Debian [9] і Ubuntu [10], кількість активних користувачів Subversion приблизно таке ж, як у Git, і перевершує аналогічний показник для CVS, Mercurial і Bazaar (станом на червень 2011).

В якості офіційної документації позиціонується [11] книга видавництва O'Reilly Media, викладена у вільний доступ на сайті http://svnbook.red-bean.com/ і дописуємо авторами по мірі виходу нових версій SVN. Там же публікуються її переклади на ряд мов, у тому числі російський, але при тому, що англомовні версії книги зараз описують версії 1.6 і 1.5, російською мовою є лише книги, що описують версії до 1.4 включно.


1. Історія

Розробка Subversion була розпочата в 2000 з ініціативи та за фінансової підтримки CollabNet Inc. Ініціатори проекту хотіли створити вільну систему керування версіями, в основному схожу на CVS, але позбавлену її помилок і незручностей. У той час не існувало кращих програм цього класу з вільною ліцензією, CVS була стандартом де-факто серед розробників вільного програмного забезпечення. Вибравши її за основу, розробники Subversion сподівалися спростити розробку за рахунок використання вже перевірених концепцій і в той же час полегшити перехід на нову систему численним користувачам CVS. [12]

Основні події історії розвитку Subversion.

  • 31 серпня 2001 команда розробників перейшла з CVS на Subversion для управління власним вихідним кодом: Subversion стала "самодостатньою".
  • 23 лютого 2004 вийшов реліз 1.0.0 [13]. До цього часу Subversion вже використовувалася приблизно на 1400 серверах з відкритим доступом. [14]
  • 29 вересня 2004 з'явився реліз 1.1.0. Серед основних нововведень - новий формат сховища на основі звичайних файлів (FSFS), на додаток до існуючого раніше (з використанням Berkeley DB). [15]
  • 21 травня 2005 вийшов реліз 1.2.0, в якому додана можливість блокування файлів, [16] що дозволило поліпшити підтримку клієнтів WebDAV / DeltaV, в тому числі, реалізувати автоматичне створення нових версій при редагуванні файлів за допомогою таких клієнтів. Починаючи з цього релізу Subversion за замовчуванням використовує FSFS для нових сховищ.
  • 30 грудня 2005 вийшов реліз 1.3.0. [17] Основними змінами є можливість встановлювати права доступу до директорій при використанні svnserve, додаткові можливості команд, а також безліч поліпшень для розробників.
  • 10 вересня 2006 вийшов реліз 1.4.0. [18] Він підтримує роботу з BerkeleyDB 4.4 і може використовувати її функції самовідновлення. Раніше при збоях Subversion сховище, що використовує BerkeleyDB, могло залишитися в "заклиненого" стані і потрібно втручання адміністратора для відновлення роботи системи (при використанні FSFS цієї проблеми немає).
  • 19 червня 2008 вийшов реліз 1.5.0 [19], в ньому зроблено безліч поліпшень, найзначнішим з яких є базова підтримка відстеження злиттів ( англ. merge tracking ). Ця можливість робить процес злиття пакетів в Subversion більш простим і надійним.
  • 20 березня 2009 вийшов реліз 1.6.0. [20] Покращення підтримки svn: externals, виявлення "конфліктів дерев" ( англ. tree conflict ), Поліпшення ефективності зберігання даних в репозиторії та інші внесені зміни.
  • У лютому 2010 проект Subversion був офіційно переведений під управління Apache Software Foundation (ASF) [21]. Президент Subversion Corporation і директор Open Source в WANdisco виступив з відеозверненням, в якому з ентузіазмом пообіцяв усім, що перехід Subversion до ASF буде лише сприяти більш активному розвитку проекту. [22]
  • 11 жовтня 2011 відбувся реліз 1.7 [23]. Основні поліпшення: тепер тільки одна папка .svn докорінно робочої копії; прискорена робота по HTTP; добавлена ​​утиліта svnrdump; нова команда svn patch.

2. Загальні відомості

2.1. Можливості

  • Зберігання повної історії змін відстежуваних об'єктів ( файлів, каталогів, символьних посилань [24]) в централізованому сховищі (репозиторії), у тому числі при зміні атрибутів (" метаданих "), переміщення, перейменування та видалення
  • Копіювання об'єктів з розгалуженням історії - при копіюванні в сховище з'являються два окремих об'єкта із загальною історією
  • Підтримка перенесення змін між копіями об'єктів, у тому числі повного злиття копій (в робочій копії; без об'єднання історії)
  • Підтримка розгалуження :
    • створення гілок (копіюванням директорій) і роботи з ними
    • злиття гілок (переносом змін)
  • Підтримка міток (копіюванням директорій)
  • Історія змін та копії об'єктів (у тому числі гілки та мітки) зберігаються у вигляді пов'язаних різницевих копій - "дешевих" (не потребують великих тимчасових і дискових ресурсів) при створенні і зберіганні
  • Підтримка конкурентного (у тому числі одночасною, з ізоляцією транзакцій) багатокористувацької роботи з сховищем і, в більшості випадків, автоматичним злиттям змін різних розробників (в робочій копії)
  • Фіксації змін у сховищі (у тому числі многооб'ектний) організуються у вигляді атомарних транзакцій
  • Мережевий обмін між сервером і клієнтом передбачає передачу тільки відмінностей між робочою копією та сховищем
  • Забезпечується однаково ефективна робота як з текстовими, так і з двійковими файлами
  • Різні варіанти доступу до сховища, в тому числі:
    • безпосередній доступ на локальній файловій системі;
    • за власним мережному протоколу;
    • через веб-сервер по протоколу WebDAV / DeltaV.
  • Висновок клієнта командного рядка однаково зручний і для читання, і для розбору програмами
  • Можливість зеркалирования сховища
  • Два можливих внутрішніх формату сховища ( англ. repository ): База даних або набір звичайних файлів
  • Інтернаціоналізовані повідомлення програми (використовуються налаштування локалі)
  • Бібліотеки для мов PHP, Python, Perl, Java дозволяють вбудувати функціональність клієнта Subversion в програми, написані на цих мовах
  • Багаторівнева архітектура бібліотек, спочатку розрахована на клієнт-серверну модель

2.2. Модель роботи

Subversion - централізована система (на відміну від розподілених систем, таких як Git або Mercurial), то є дані зберігаються в єдиному сховищі. Сховище може розташовуватися на локальному диску або на мережевому сервері.

Робота в Subversion мало відрізняється від роботи в інших централізованих системах управління версіями. Клієнти копіюють файли з сховища, створюючи локальні робочі копії, потім вносять зміни в робочі копії і фіксують ці зміни в сховищі. Кілька клієнтів можуть одночасно звертатися до сховища. Для спільної роботи над файлами в Subversion переважно використовується модель копіювання - зміна - злиття. Крім того, для файлів, що не допускають злиття (різні бінарні формати файлів), можна використовувати модель блокування - зміна - розблокування.

При збереженні нових версій використовується дельта-компресія : система знаходить відмінності нової версії від попередньої і записує тільки їх, уникаючи дублювання даних.

При використанні доступу за допомогою WebDAV також підтримується прозоре управління версіями - якщо будь-який клієнт WebDAV відкриває для запису і потім зберігає файл, що зберігається на мережевому ресурсі, то автоматично створюється нова версія.


2.3. Типи репозиторіїв

Subversion пропонує два варіанти організації репозиторіїв [25]. Репозиторії першого типу використовують для зберігання бази даних на основі Berkeley DB, репозиторії другого типу - звичайні файли спеціального формату (доступ до даних організовується за допомогою власних бібліотек, без використання сторонніх баз даних). Розробники Subversion часто називають сховище "файлової системою", тому другий тип отримав назву FSFS, тобто (версіонірованная) файлова система ( англ. File System ) Поверх (звичайної) файлової системи.

Обидва типи сховищ забезпечують достатню надійність при правильній організації [26] (Berkeley DB використовує блокування файлів, тому її не можна використовувати на деяких мережевих файлових системах, що не підтримують блокування), кожна з них має свої переваги й недоліки. Вважається, що FSFS легше правильно налаштувати, вона вимагає меншої уваги від адміністратора. Крім того, до релізу 1.4 сховища, які використовують Berkeley DB могли за певних умов виявитися в так званому заклиненого ( англ. wedged ) Стані; потрібно втручання адміністратора для відновлення його працездатності. Починаючи з релізу 1.2 для нових сховищ за замовчуванням використовується FSFS.


2.4. Доступ до сховища

Subversion надає наступні способи доступу до сховища:

  • прямий доступ до сховища на диску (на локальної або мережної файлової системи)
  • віддалений доступ по протоколу WebDAV / DeltaV поверх HTTP (або HTTPS) з використанням модуля mod_dav_svn для веб-сервера Apache 2
  • віддалений доступ з використанням власного протоколу SVN:
    • на виділеному мережевому з'єднанні (по замовчуванню на TCP-порту 3690)
    • через стандартний ввід-висновок (у тому числі через засоби віддаленого CLI, наприклад SSH)

Всі ці способи можуть бути використані для роботи з репозиторіями обох типів (FSFS і Berkeley DB). Для доступу до одного і того ж сховища можуть одночасно використовуватися різні способи.


3. Основні концепції

3.1. Файлова система

Рис. 1. Двовимірне подання файлової системи в Subversion

З точки зору користувача сховище Subversion являє собою "двовимірну" файлову систему. Об'єкти в сховищі ( файли і директорії) ідентифікуються двома " координатами ": ім'ям і номером ревізії. Іншими словами, сховище являє собою масив миттєвих знімків (ревізій) дерева файлів і директорій, індексований номером ревізії. Кожен такий знімок - звичайна (одномірна) файлова система.

При необхідності вказівки на конкретну ревізію об'єкта використовується запис виду: ім'я @ ревізія, наприклад, / main.c @ 29 - файл / main.c в ревізії 29. Таку вказівку ревізії, використовуване для уточнення імені, називається стрижнева ревізія ( англ. peg revision ).

На рис. 1 показано графічне представлення файлової системи: вертикальна вісь відповідає безлічі імен, горизонтальна - безлічі ревізій.


3.1.1. Імена файлів

Назва об'єкту файлової системи в Subversion утворюється за тими ж правилами, що і в UNIX-подібних операційних системах: існує тільки одна коренева директорія, елементи шляху поділяються косою рисою ("/"). Об'єктами файлової системи є файли і директорії (а також символічні посилання, які емулюються зі звичайних файлів шляхом установки атрибута svn: special).


3.1.2. Номери ревізій

Номер ревізії в Subversion - це натуральне число (або 0 для самої першої ревізії), адреса номер стану сховища в процесі зміни містяться в ньому даних. Кожна успішна фіксація змін породжує рівно одну нову ревізію в сховище, тобто N-я ревізія - це стан сховища після N-й фіксації.

У Subversion ревізія характеризує стан не окремого файлу, а всього сховища в цілому. Наприклад, ревізія 32 (обведено пунктиром на малюнку) - це стан трьох файлів і двох директорій, що існували в сховище на той момент.

Номер ревізії є аналогом часу в тому сенсі, що менші номери ревізій відповідають більш раннім станам сховища, а великі - пізнім.

  • Мінімальний рівень редакції 0 (нуль) відповідає початковому станом сховища, коли ще не було зафіксовано жодної правки. У нульовий ревізії сховище містить тільки порожню кореневу директорію.
  • Максимальний рівень редакції відповідає самому останньому станом сховища, тобто стану після фіксації останньої правки. Замість зазначення номера останньої ревізії можна використовувати ключове слово HEAD (головний ревізія); це зручно, оскільки номер головного ревізії збільшується при кожній фіксації змін.

Номер ревізії можна розглядати як якусь тимчасову позначку в історії сховища. Більше того, з кожним номером ревізії пов'язано абсолютне значення часу, коли ця ревізія була зроблена (властивість svn: date). Проте зазначення номера ревізії зручніше, ніж вказівка ​​часу, так як немає плутанини з часовими поясами, запис номера коротше і номер ревізії не може бути змінений.


3.1.2.1. Оперативна і стрижнева ревізії
Рис. 2. Вказівка ​​стрижневий ревізії

Номер ревізії використовується у двох різних контекстах :

  • оперативної ревізії ( англ. operative revision );
  • стрижневою ревізії ( англ. peg revision ).

Ревізія називається оперативною, якщо вона вказується як ревізія або діапазон ревізій, до якого повинна бути застосована команда, наприклад:

 svn log-r 199:230 http://some.path 

У даному прикладі виконується команда svn log для діапазону ревізій 199:230, який і є діапазоном оперативних ревізій.

Проте вказівка ​​лише оперативної ревізії іноді може неоднозначно вказувати на об'єкти сховища. Наприклад, у ситуації, показаної на рис. 2, виникає неоднозначність при виконанні наступної команди:

 svn log-r 29:33 http://some.path/bar.txt 

У команді вказаний діапазон оперативних ревізій ( 29:33), але області, виділені на малюнку блакитним і зеленим фоном, в рівній мірі можна вважати історією файлу / bar.txt в діапазоні ревізій 29:33. У подібних випадках необхідно вказувати ще і стрижневу ревізію для вирішення неоднозначності. Стрижнева ревізія - це номер редакції, зазначений у додатку до URL об'єкта файлової системи (використовується запис виду "URL @ ревізія"). URL зі стрижневою ревізією завжди однозначно ідентифікує об'єкт (файл або директорію). Команда застосовується до тієї єдиної ланцюжку станів, якій належить вказана пара URL @ ревізія. У наведеному нижче прикладі перша команда виведе історію, виділену на малюнку блакитним фоном, а друга - історію, виділену зеленим фоном:

 svn log-r 29:33 http://some.path/file.txt @ 32 svn log-r 29:33 http://some.path/bar.txt @ 34 

Як стрижневий ревізії слід вказувати якомога пізніший стан об'єкта, що цікавить. Причина цього в тому, що ланцюжок станів однозначно відстежується "назад", але не "вперед". Наприклад, URL зі стрижневою ревізією http://some.path/foo.txt @ 31 належить двом ланцюжках станів (виділені відповідно зеленим і сірим фоном). З цих двох ланцюжків вказаний URL адресує сіру ланцюжок, тобто при русі "вперед" від стрижневий ревізії операції копіювання ігноруються.


3.1.3. Операції над файловою системою

Над об'єктами файлової системи в сховище Subversion можуть бути зроблені перераховані нижче операції [27] (див. рис. 1). У дужках зазначено стислий іменування операції в позначеннях команди svn status.

  • Додавання (A). Додавання об'єкта в файлову систему. Доданий об'єкт не має історії ревізій. Приклад на малюнку:
  • файл / main.c був доданий в ревізії 27.
  • Модифікація (M). Модифікація об'єкта, наприклад, зміна вмісту файлу або зміна властивостей файлу або директорії. Приклад на малюнку:
  • файл / main.c був модифікований в ревізії 28.
  • Видалення (D). Видалення файлу з головної і наступних ревізій. При цьому файл залишається в попередніх ревізіях. Приклад на малюнку:
  • файл / main.c був видалений в ревізії 30.
  • Додавання з історією (A +). Являє собою копіювання об'єкта всередині файлової системи сховища, тобто об'єкт імя_істочніка @ ревізія_істочніка копіюється в імя_копіі @ HEAD. Скопійований об'єкт успадковує від джерела історію ревізій до моменту копіювання (успадкування історії показано на малюнку пунктирними зв'язками). Приклади на малюнку:
  • в ревізії 29 директорія / tags/R1 була скопійована з директорії / trunk @ 27;
  • в ревізії 31 файл / main.c був скопійований з / main.c @ 29, тобто з більш ранньої ревізії самого себе, таким чином, вироблено відновлення раніше віддаленого (в ревізії 30) файлу зі збереженням історії ревізій.
  • Заміна (R +). Має місце у випадку, коли в одній ревізії вироблено та видалення об'єкта (D), і додавання з історією (A +) об'єкта з тим же самим ім'ям. Хоча ім'я при операції заміни залишається незмінним, Subversion розглядає об'єкт до і після заміни як два різних об'єкта з різними історіями ревізій (історія старого закінчується в точці заміни, історія нового успадковується від джерела копіювання і продовжується далі). Приклад на малюнку:
  • в ревізії 30 файл / file.txt був замінений: старий файл / file.txt вилучений, а новий файл з тим же ім'ям скопійований з файлу / bar.txt @ 29.

3.2. Фіксація змін

3.2.1. Робоча копія

Робоча копія - це створена клієнтською програмою Subversion локальна копія частини даних зі сховища, що містить крім власне даних деяку службову інформацію (приховані директорії з іменем. Svn). Службова інформація необхідна для правильного функціонування робочої копії; що-небудь міняти в службових даних не можна. Мінімальною одиницею даних, яку можна отримати з сховища як робочу копію, є директорія (можна також отримати директорію без піддиректорій, а потім докачувати їх у міру потреби). Іншими словами, в Subversion робоча копія завжди відповідає рівно одній директорії сховища. Витягти з сховища окремий файл як робочу копію неможливо.

Особливістю Subversion (на відміну від інших систем керування версіями) є те, що будь-яка піддиректорії робочої копії також є повноцінної робочої копією, оскільки в кожній директорії зберігаються її службові дані. Робоча копія є самодостатньою в тому сенсі, що Subversion не зберігає будь-яких даних, що відносяться до робочої копії, поза нею. Тому, маючи одну робочу копію, можна зробити ще кілька копій простим копіюванням без витрат мережевого трафіку.

У службових директоріях робочої копії, крім іншого, зберігається (в директоріях .svn / text-base /) так звана чиста копія ( англ. pristine copy ) - Файли робочої копії в незміненому вигляді, як вони були витягнуті зі сховища (для svn це ревізія з ім'ям BASE). Наявність чистої копії дозволяє швидко і без звернення до сховища виконувати операції перегляду і відкату локальних змін. Проте розмір робочої копії на диску приблизно в два рази більше (дані + чиста копія даних), ніж розмір самих даних. Такий підхід обумовлений тим, що дискові ресурси дешевше і доступніше, ніж ресурси мережі передачі даних.

Як правило, створення робочої копії є першим і необхідним етапом для фіксації локальних змін, оскільки зафіксувати в сховищі можна тільки зміни, зроблені в робочій копії. Винятком є ​​операції, які можуть бути виконані прямо в сховище без створення робочої копії.


3.2.2. Транзакції

Робота зі сховищем в Subversion організована у формі транзакцій з властивостями атомарности та ізоляції з набору властивостей ACID. Таким чином система управління версіями гарантує цілісність, несуперечність і доступність сховища в будь-який момент часу.

  • Атомарність фіксацій ( англ. atomic commits ) - Зміни в декількох файлах або директоріях фіксуються єдиної транзакцією породжуючи при цьому одну ревізію. У разі невдалої фіксації, при будь-якому збої або помилку, система гарантує що сховище не виявиться в частково зміненому стані - у сховище потраплять або всі зміни, або (при невдачі) - жодного.
  • Ізоляція гарантує, що проміжні стану сховища в транзакції не видно іншим транзакцій і користувачам. Наприклад, якщо один користувач фіксує однією транзакцією зміни в декількох файлах, то інші користувачі не можуть побачити такого стану сховища, в якому частина файлів вже змінена, а частина - не змінена.

Робоча копія Subversion, на відміну від сховища, при збої може опинитися в проміжному або заблокованому стані.


3.2.3. Локальні і віддалені форми команд

Усі команди клієнта Subversion можна розділити на наступні групи:

  • модифікуючі робочу копію;
  • модифікуючі сховище;
  • модифікуючі та робочу копію, і сховище;
  • не модифікують нічого.

3.3. Структура сховища

3.3.1. Структура проекту в сховище

Формально Subversion не накладає жодних обмежень на файлову структуру проекту - вона може бути якою завгодно в рамках правил іменування об'єктів файлової системи. Тим не менш, існують рекомендації, покликані полегшити роботу з гілками та мітками. У найпростішому випадку в кореневій директорії сховища рекомендується створити як мінімум три піддиректорії:

/.
trunk
branches
tags

де вся файлова структура проекту (основної лінії розробки) повинна утримуватися в піддиректорії trunk, піддиректорії branches повинна містити гілки проекту, а tags - мітки. Наприклад, наступна структура директорій сховища:

/.
trunk
branches
branch_1
tags
tag_1
tag_2

передбачає наявність у проекту (trunk) однієї гілки "branch_1" і двох міток "tag_1" і "tag_2". Кожна з цих директорій (trunk, branch_1, tag_1 і tag_2) містить копію відповідної версії проекту.

Якщо (під) проектів в сховище декілька, то така структура піддиректорій створюється для кожного (під) проекту:

/.
project1
trunk
branches
tags
project2
trunk
branches
tags

тобто в кореневій директорії знаходяться директорії проектів, і в кожному з них є свої trunk, branches, tags, відносяться тільки до цього проекту. Описані структури директорій сховища є лише прикладами, на практиці сховище можна організувати таким способом, який оптимально підходить в даному конкретному випадку. [28] [29]

Іншим способом зберігання кількох проектів є створення декількох сховищ. У різних сховищах слід розташовувати проекти, які ніяк не пов'язані між собою, оскільки між сховищами не можна буде виконати операції копіювання, переміщення і злиття. Кілька сховищ можна при необхідності об'єднати в одне із збереженням історії ревізій (шляхом імпорту командою svnadmin load з параметром - parent-dir).


3.3.2. Гілки

Subversion використовує "файлову" модель (таку ж, як і в Perforce [30]) для реалізації гілок і міток, тобто гілка є звичайною директорією (можна також зробити гілку з одного файлу, а не директорії). Нова гілка створюється командою svn copy. Гілка може бути створена в будь-якій директорії сховища, однак має сенс дотримуватися описаних вище угод про те, де створювати нові гілки. Більш детальна інформація про гілках наведена в розділах Галуження і Злиття.


3.3.3. Мітки

Створення мітки також проводиться командою svn copy, тобто технічно не відрізняється від створення гілки. Відмінність тільки в способі використання: передбачається, що ніхто не буде змінювати дані в мітці (фіксувати в неї зміни). Наприклад, на рис. 1 мітка створена в ревізії 29: директорія / trunk з ревізії 27 скопійована під ім'ям / tags/R1. Тепер, якщо не змінювати дані в директорії / tags/R1, то вона назавжди залишиться точною копією директорії / trunk @ 27, тобто буде міткою.

Концепція міток, використовувана в Subversion, відрізняється від концепції міток в інших системах управління версіями. Зазвичай мітка є символічним ім'ям, яке адресує набір файлів та їх стан. У Subversion мітка копіює набір файлів та їх стан. Мітки-копії в Subversion мають свої переваги і недоліки.

Переваги:

  • мітка створюється практично миттєво при будь-якому розмірі позначуваних даних (завдяки дешевим операціями копіювання);
  • мітка видно в структурі директорій, можна зробити зручну деревоподібну організацію міток.

Недоліки:

  • важко дізнатися, в які мітки увійшов файл (те ж для директорії);
  • якщо права доступу встановлені індивідуально [31] для директорій, то мітка ці права не успадковує;
  • вміст мітки може бути змінено;
  • якщо з тега створити робочу копію і зафіксувати з цієї робочої копії будь-які зміни, то це змінить саму позначку, а не ті дані, які були помічені. Правильним способом роботи "від мітки" є створення робочої копії не з мітки, а з того, що є джерелом цієї позначки.

3.4. Властивості (properties)

Однією з важливих можливостей Subversion є підтримка властивостей, тобто текстових пар ім'я = значення, які можуть бути встановлені для об'єктів у сховище. Властивості використовуються в двох різних контекстах: для об'єктів файлової системи і для ревізій.

3.4.1. Властивості об'єктів файлової системи

Кожному файлу або директорії в сховище може бути присвоєно набір властивостей. Зміни властивостей зберігаються в історії так само, як і зміни у файловій системі. Користувачі можуть встановлювати властивості з будь-якими іменами; існує також визначений набір службових властивостей, які використовуються клієнтською програмою Subversion (імена службових властивостей мають префікс "svn:").

3.4.1.1. Властивості файлів
svn: executable
Робить файл виконуваним (для робочих копій під операційними системами сімейства UNIX).
svn: mime-type
Зберігає MIME -тип файлу. Впливає на спосіб роботи команд, які показують різницю файлів, а також об'єднують зміни (merging).
svn: keywords
Список ключових слів ( англ. keywords ), Які будуть замінені у файлі відповідними значеннями. Щоб заміна відбулася, ключове слово повинне бути присутнім у файлі у вигляді $ keyword $. Використовується для того, щоб автоматично оновлювати у файлі значення, мінливі від версії до версії (наприклад, номер ревізії).
svn: eol-style
Визначає правило перетворення символів кінця рядка ( англ. end-of-line, EOL ) В текстовому файлі. Використовується у випадках, коли файл повинен мати конкретний тип символів EOL. Зазвичай використовується "native" - ​​при цьому тип символів кінця рядка відповідає прийнятому в тій операційній системі, в якій відбувається створення робочої копії.
svn: needs-lock
Означає, що при вилученні з сховища файл буде доступний тільки для читання. Це властивість призначено для використання спільно з механізмом блокування. Заборона запису в файл є нагадуванням того, що треба отримати блокування на цей файл, перш ніж його редагувати: при отриманні блокування клієнтська програма Subversion автоматично робить файл доступним для запису (розблокування знову робить файл захищеним від модифікацій). Блокування можуть бути використані і без установки цієї властивості. Однак робити це не рекомендується, тому що існує ризик того, що інший користувач може почати редагувати заблокований файл, і це виявиться тільки при фіксації змін.
svn: special
Властивість не призначене для установки або модифікації користувачами. В даний час використовується для зберігання символьних посилань в репозиторії. Коли символьне посилання додається в репозиторій, в репозиторії створюється файл з встановленим властивістю svn: special. Коли цей файл витягується в UNIX -подібній системі, клієнтська програма Subversion перетворює його назад на заслання.
svn: mergeinfo
Зберігає інформацію про те, з яких шляхів було вироблено злиття в цей файл. Властивість введено у версії 1.5, воно використовується для відстеження злиттів ( англ. merge tracking ). Являє собою набір рядків виду ім'я_файлу: діапазон_ревізій. Тут ім'я_файлу - повне (з шляхом від кореня файлової системи репозиторію) ім'я файлу або директорії, звідки було вироблено злиття зазначеного діапазону ревізій. Рядки модифікуються автоматично при операціях злиття; при подальших злиттях Subversion враховує раніше вписані рядки, уникаючи тим самим повторних злиттів одних і тих же змін. Не рекомендується змінювати властивість svn: mergeinfo вручну - це може порушити механізм відстеження злиттів.

3.4.1.2. Властивості директорій
svn: ignore
Список шаблонів імен файлів і директорій, які клієнтська програма Subversion ігноруватиме в даній директорії. Це властивість аналогічно файлу. Cvsignore в CVS. Як правило, властивість настроюється таким чином, щоб клієнтська програма "не бачила" файли і директорії, які автоматично створюються різними програмами і не повинні бути версіоніровани (наприклад, об'єктні файли, тимчасові файли і т. п.). Дія цієї властивості не поширюється на піддиректорії.
svn: externals
Дозволяє автоматично отримати в робочу копію набір директорій, вказавши їх URL (можна навіть з іншого сховища).
svn: mergeinfo
Те ж, що і для файлів.

3.4.2. Властивості ревізій

Другий тип об'єктів, для яких існують властивості, - це самі ревізії. У цьому випадку імена властивостей також можуть бути будь-якими; деякі властивості з префіксом "svn:" мають спеціальне значення. Відмінність властивостей ревізій від властивостей об'єктів файлової системи в тому, що для перших поняття історії версій не придатним (оскільки конкретне значення властивості приписано однієї ревізії). Іншими словами, властивості ревізій можна змінити, але старе значення при цьому втрачається. За замовчуванням зміна властивостей ревізій заборонено; для розв'язання адміністратор повинен створити скрипт ( англ. hook ) Обробки події pre-revprop-change.

svn: date
Дата і час створення ревізії.
svn: author
Ім'я користувача, який зафіксував зміни, що увійшли в цю ревізію.
svn: log
Опис змін, зафіксованих у цій ревізії (текст, введений користувачем при фіксації змін).

Як правило, властивості ревізій змінюються тільки адміністратором сховища з метою виправлення некоректних даних. Наприклад, якщо користувач забув вказати текстовий опис при фіксації своїх змін, то адміністратор може створити цей опис шляхом редагування властивості svn: log.


4. Використання Subversion

4.1. Робочий цикл

Типова ітерація робочого циклу з Subversion включає наступні етапи.

  • Оновлення робочої копії зі сховища (svn update) або її створення (svn checkout).
  • Зміна робочої копії. Зміни директорій та інформації про файли проводиться засобами Subversion, у зміні ж (вмісту) файлів Subversion ніяк не задіяний - зміни виробляються програмами, призначеними для цього ( текстові редактори, засоби розробки і т. п.):
    • нові (ще не зафіксовані в сховище) файли і директорії потрібно додати (команда svn add), тобто передати під управління версіями;
    • якщо файл або директорію в робочій копії необхідно використовувати засоби Subversion (svn mkdir, svn delete, svn move, svn copy);
    • перегляд стану робочої копії і локальних (ще не зафіксованих) змін (svn info, svn status, svn diff);
    • будь-які локальні зміни, якщо вони визнані невдалими, можна відкотити (svn revert).
  • При необхідності - додаткове оновлення, для отримання змін, зафіксованих у сховищі іншими користувачами і злиття цих змін з своїми (svn update).
  • Фіксація своїх змін (та / або результатів злиття) у сховищі (svn commit).

4.2. Галуження

Галуження є важливим аспектом роботи систем управління версіями, оскільки типові прийоми [32] управління версіями (принаймні, при розробці програмного забезпечення) мають на увазі використання гілок. Subversion має досить розвиненими можливостями для розгалуження та злиття (однак не підтримує злиття перейменованих файлів і директорій).

Рис. 3. Приклад еволюції гілок в Subversion

На рис. 3 умовні показаний приклад еволюції гілок в сховище. Зеленим кольором показана основна лінія розробки проекту ( англ. mainline, trunk ), Жовтим - гілки, синім - мітки, пурпурним - гілка, розробка якої припинено. Червоними стрілками показані злиття змін.


4.2.1. Створення гілок

Нова гілка (а також мітка) створюється командою svn copy, яка створює в сховище копію з успадкуванням історії ревізій джерела (операція A +). Для створення гілок завжди слід використовувати "віддалену" форму команди svn copy, наприклад:

 svn copy http://.../trunk/dir http://.../branches/branch_name-m "Creating a branch of dir" 

Отримана копія буде гілкою (або міткою, в залежності від способу роботи з нею). Надалі зміни, зроблені на гілки, можуть бути внесені в джерело, з якого була створена ця гілка, таке поширення змін називається злиття ( англ. merge ).

Операції копіювання в Subversion дешеві ( англ. cheap copy ), Тобто вимагають невеликого фіксованої кількості часу і дискового простору. Сховище спроектовано таким чином [33], що за будь копіюванні відбувається не дублювання даних, а створення посилання на джерело (аналогічно жорсткої посиланням), проте цей механізм чисто внутрішній - з точки зору користувача відбувається саме створення копії. Завдяки високій ефективності створення гілок їх можна створювати настільки часто, наскільки це необхідно (проте злиття - необхідне доповнення до розгалуження - виконується в Subversion повільніше, ніж в інших сучасних системах управління версіями).


4.2.2. Робота з гілками

В цілому робота на гілки не відрізняється від роботи на основній лінії розробки (trunk). Специфічні команди потрібні тільки для дій, в яких задіяно більше однієї гілки. До таких відносяться командам (крім команди створення гілки svn copy):

  • svn switch - перемикання робочої копії на іншу гілку - використовується для того, щоб переключити наявну робочу копію на іншу гілку. В результаті переключення службові дані робочої копії змінюються так, як ніби ця робоча копія отримана операцією svn checkout з тієї гілки, на яку вона переключена. При цьому обсяг мережевого трафіку менше, ніж при svn checkout, так як передається тільки різниця між даними у робочій копії та цільової гілкою;
  • svn merge - копіювання набору змін між гілками - використовується для злиття.

Як правило, повний цикл роботи з гілками включає наступні етапи:

  • створення гілки (svn copy);
  • переключення наявної робочої копії на гілку (svn switch) або створення нової робочої копії шляхом закачки (svn checkout);
  • зміна файлів і директорій в робочій копії, фіксація цих змін (svn commit);
  • копіювання в гілку останніх редагувань з батьківської гілки, зроблених після розгалуження (svn merge, svn commit);
  • копіювання змін з гілки в батьківську гілка (svn merge, svn commit);
  • видалення гілки (svn delete), якщо її життєвий цикл закінчений.

4.3. Злиття

4.3.1. Копіювання змін між гілками

Злиття в Subversion - це застосування до гілки набору змін, зроблених на інший (або тієї ж самої) гілки. Для здійснення злиття необхідно використовувати команду svn merge - вона застосовує набір змін до робочої копії; потім потрібно зафіксувати внесені зміни (svn commit).

Термінологія, пов'язана зі злиттям, кілька заплутана. Термін злиття ( англ. merge ) Є не зовсім точним, оскільки як такого об'єднання гілок не відбувається. Крім того, не слід ототожнювати злиття і команду svn merge: по-перше, для злиття потрібно виконати (крім svn merge) вирішення конфліктів і фіксацію, по-друге, застосування svn merge не обмежується злиттям.


4.3.2. Інші застосування команди svn merge

Команду svn merge можна використовувати не тільки для злиття. Фактично команда виробляє внесення в робочу копію змін, рівних різниці між двома директоріями або файлами у сховищі, тому svn merge є універсальним засобом для перенесення змін. Можна навести такі приклади використання команди svn merge:

  • відкат вже зафіксованих змін, у тому числі цілого діапазону ревізій;
  • зручний перегляд (у вигляді змін до робочої копії) різниці між двома станами сховища.

4.4. Створення сховища

Для створення сховища використовується команда svnadmin create. Ця операція створить пусте сховище у вказаній директорії.

5. Subversion і CVS

5.1. Порівняння

Нижче наведено порівняння параметрів систем Subversion і CVS, так як Subversion позиціонується саме як поліпшення CVS. Приведено порівняння тільки за тими параметрами, за якими ці системи відрізняються. В цілому Subversion перевершує CVS по всіх параметрах, окрім підтримки міток в загальноприйнятому сенсі (тобто міток, що адресують об'єкти файлової системи).

Параметр Subversion CVS
Можливості
Директорії Відстежує версії не тільки файлів, але і директорій. Версії директорій не відслідковуються, тобто структура директорій одна і та ж (та, яка існує в сховище на даний момент) для всіх ревізій і всіх гілок. Якщо змінити структуру директорій, то при вилученні старих станів отримуємо правильні (старі) ревізії файлів, але в неправильній (існуючої на момент вилучення) структурі директорій.
Транзакції Атомарність багатофайлова фіксацій. Атомарність тільки на рівні однофайлових фіксацій. Фактично фіксація змін у декількох файлах розбивається на послідовність фіксацій змін окремих файлів. Якщо така послідовність фіксацій перервана, то деякі файли залишається зафіксованою, частина - не зафіксованою.
Набори змін Набори змін ( англ. changeset ) Підтримуються. Набори змін не підтримуються.
Модифікації імен файлів Підтримує копіювання, переміщення і перейменування файлів і директорій без втрати історії змін. При копіюванні, переміщенні та перейменування файлів файл з новим ім'ям не має ніякої історії, тобто зв'язок зі старим ім'ям і його історією версій повністю втрачається. Те ж саме для файлів всередині директорії при модифікації її імені [34].
Властивості (properties) З кожним файлом і директорією може бути пов'язаний довільний набір властивостей, що складаються з назви і значення. Властивості теж знаходяться під управлінням версіями. Властивості не підтримуються.
Блокування Підтримується необов'язкова блокування файлів (починаючи з версії 1.2). Блокування не підтримуються, але є схожий механізм, званий стеження.
Гілки Гілки (branch, см. словник) реалізовані в просторі шляхів. Це означає, що для створення гілки проводиться копіювання директорії (копія і буде гілкою). Створення таких копій - швидка і не ресурсномістка операція, тому що дані не дублюються, натомість фіксується нова версія, що відрізняється від попередньої лише розташуванням файлів. Гілки реалізовані в "третьому вимірі". Це означає, що файл на гілки адресується трьома параметрами: шляхом у файловій системі, ревізією (або іншим способом вказівки ревізії, наприклад, часом), ім'ям гілки.
Мітки Немає міток (tag, см. словник) як таких. Замість них використовується ієрархія директорій - для мітки створюється окрема директорія (як і для галузі). Мітка - це гілка, в якій за домовленістю більше не роблять змін. Мітка є копією позначеного стану файлів і директорій. Мітки підтримуються. Мітка адресує позначене стан файлів.
Ефективність
Клієнт-серверний обмін За будь-яких оновленнях версій між клієнтом і сервером передаються тільки відмінності між файлами, що може істотно зменшити мережевий трафік. З сервера до клієнта передаються відмінності, з клієнта на сервер об'єкт передається повністю.
Двійкові файли Однаково ефективно працює як з текстовими, так і з двійковими файлами. Робота з двійковими файлами менш ефективна: кожна нова версія зберігається у сховищі повністю.
Створення гілок і ярликів Потрібне невелике фіксовану кількість часу і дискового простору. Витрати часу великі (залежать від кількості задіяних файлів). Імена гілок і ярликів зберігаються надлишково (в усіх задіяних файлах).
Накладні витрати в робочій копії У службових директоріях робочої копії зберігається чиста копія. Тому операції перегляду і відкату локальних змін виконуються швидко (без звернення до сховища), проте розмір робочої копії на диску приблизно в два рази більше, ніж розмір самих даних. Чистий копія не зберігається, розмір робочої копії приблизно дорівнює розміру даних. Внаслідок цього операції перегляду і відкату локальних змін вимагають доступу до сховища і виконуються повільно.
Витрата пам'яті на сервері Менше [35]. Більше.

5.2. Міграція з CVS на Subversion

5.2.1. Перетворення репозиторія

Існує програма cvs2svn, призначена для перетворення сховища CVS в готовий репозиторій Subversion (або в репозиторій git) або в текстовий дамп, який можна потім імпортувати в репозиторій за допомогою утиліти svnadmin. При цьому cvs2svn зберігає всю інформацію, що міститься в репозиторії CVS: гілки, мітки, опису змін, імена авторів, дати фіксації змін. Крім того, зміни в різних файлах, зафіксовані спільно, перетворюються в одну ревізію.


5.2.2. Відмінності у використанні

5.2.2.1. Відмінності в роботі з файлами

У CVS операції з переміщення (перейменування) і копіювання файлів і директорій виконуються повторним додаванням об'єкта з новим ім'ям і (при переміщенні та перейменування) видаленням старого об'єкта. При такій роботі файли і каталоги в сховище створюються заново і втрачають історію змін. У Subversion для виконання цих операцій повинні використовуватися команди переміщення (move або mv) і копіювання (copy). Їх використання зберігає історію змін і дозволяє уникнути зайвих операцій (особливо при операціях з директоріями або навіть гілками файлової системи).

На відміну від CVS, деякі операції в робочій копії (наприклад, видалення або переміщення файлу) Subversion виконує самостійно. Описані й інші відмінності при роботі з файлами робочої копії підсумовані в наступній таблиці (операція commit, там де вона потрібна в обох випадках, опущена):

Операція CVS Subversion Нотатки
Видалення файлу rm file
cvs rm file
svn rm file файл не потрібно попередньо видаляти вручну
Видалення файлів за маскою rm *
cvs rm file1 file2 ...
svn rm * файли не потрібно попередньо видаляти вручну
не потрібно перерахування всіх файлів
Перейменування / переміщення mv file1 file2
cvs rm file1
cvs add file2
svn mv file1 file2 файл не потрібно переміщати вручну
історія файлу зберігається
Копіювання cp file1 file2
cvs add file2
svn copy file1 file2 файл не потрібно копіювати вручну
історія файлу зберігається (розгалужується)
Додавання (створення) директорії mkdir dir
cvs add dir
svn mkdir dir
svn commit
директорію можна не створювати вручну
після додавання директорії необхідний commit
Додавання директорії з файлами cvs add dir
cd dir
cvs add file1 file2
svn add dir директорія додається з містяться в ній файлами
Перейменування директорії з файлами
(Без піддиректорій)
mkdir dir2
cvs add dir2
mv dir1 / * dir2
cvs rm dir1/file1 dir1/file2 ...
cvs add dir2 / *
svn mv dir1 dir2 не потрібно створювати і додавати директорії
не потрібно переміщати файли вручну
не потрібно перерахування всіх файлів
історія файлів зберігається
Перейменування гілки файлової системи
(Директорії з файлами і піддиректоріями)
повторювати команди вище
для кожного рівня вкладеності
або кожної піддиректорії [36]
svn mv dir1 dir2 див. вище
не залежить від кількості рівнів і директорій

5.2.2.2. Адресація стану сховища

У Subversion для адресації стану сховища не обов'язково створювати мітки або використовувати дату / час, в простих випадках (наприклад, для отримання версії після певної фіксації) буде простіше вказати потрібний номер ревізії.

6. Внутрішня структура

6.1. Рівні

Subversion спроектований як набір бібліотек, розділених на декілька рівнів. Кожен з них виконує конкретне завдання і дозволяє розробникам створювати свої власні інструменти, залежно від складності та завдання.

Fs
Найнижчий рівень; реалізує версіонірованную файлову систему, яка і зберігає дані.
Repos
Рівень сховища, реалізованого на файловій системі. На цьому рівні реалізовано безліч допоміжних функцій, а також підтримується запуск обробників ( англ. hooks ), Тобто скриптів, які запускаються при настанні деякої події. Разом рівні Fs і Repos складають інтерфейс файлової системи.
mod_dav_svn
Забезпечує WebDAV / Delta-V-доступ через Apache 2.
Ra
Реалізує доступ до сховища (і локальний, і віддалений). Починаючи з цього рівня на сховищі можна посилатися по URL, тобто
  • file: / / / path / для локального доступу,
  • http://host/path/ або https://host/path/ для доступу через WebDAV, або
  • svn: / / host / path / або svn + ssh: / / host / path / для доступу через протокол SVN.
Client, Wc
Найвищий рівень. Абстрагує доступ до сховища і забезпечує виконання типових завдань клієнта, таких як аутентифікація користувача або порівняння версій. Client використовує бібліотеку Wc для управління локальною робочою копією.

6.2. Конфігурація клієнта

Стандартна клієнтська утиліта Subversion - SVN, конфігурується змінними оточення і INI-файлами, що створюються в домашньому каталозі користувача у підкаталозі. subversion (розташування конфігурації в Windows-системах, в файлах або реєстрі, залежить від системних налаштувань). У конфігурації SVN також кешує SSL-сертифікати, логіни, паролі і т. п. (якщо це не заборонено в конфігурації) для доступу до серверів Subversion.

Cодержімое каталогу. Subversion:

  • файл servers - містить інформацію про способи мережевого підключення до віддаленого репозиторію;
  • файл config - містить іншу конфігураційну інформацію [37]
  • каталог auth - містить кеш серверів, сертифікатів, логінів і паролів
  • файл README.txt - документація по конфігурації SVN

7. Недоліки

7.1. Проблеми при перейменуванні файлів

Subversion не завжди може правильно обробити операції перейменування файлів, якщо одночасно з перейменуванням змінюється і вміст файлу. Проблеми можуть також виникнути, якщо файл, перейменований в локальній копії, хтось інший змінив у сховище. Частина цих проблем виправлена ​​у версії 1.5, проте це рішення поки не повне. [38]

7.2. Слабка підтримка злиття гілок

Також слабким місцем Subversion вважають операції злиття гілок. До версії 1.5 всі такі операції користувачам доводилося відслідковувати вручну, за допомогою детальних записів у журналі змін. Починаючи з версії 1.5 з'явилася базова підтримка автоматичного відстеження злиттів, яку розробники планують поліпшити в наступних релізах [39]. В даний час Subversion досить добре підтримує типові сценарії злиття; в більш складних випадках можливі проблеми. Рекомендується [40] організувати робочий процес так, щоб уникнути проблемних сценаріїв. Злиття перейменованих файлів і директорій не підтримується.


7.3. Неможливість видалення даних зі сховища

Інформація, одного разу поміщена в сховище Subversion, залишається там назавжди: файл можна видалити в поточній ревізії, але завжди є можливість отримати з сховища одну з попередніх ревізій, в яких файл існував. Хоча збереження минулих ревізій і є, власне, метою використання систем контролю версій, іноді буває необхідно повністю видалити зі сховища інформацію, що потрапила туди помилково. У Subversion не передбачено для цього ніякого штатного способу [41]; єдина можливість полягає у створенні дампа сховища, його редагуванні (це текстовий файл) і наступному відновленні сховища з дампа. Існують сторонні програми для автоматизації цього процесу, але, в будь-якому випадку, для виконання цієї операції потрібно тимчасове припинення доступу до сховища і втручання адміністратора з привілеями, досить високими для того, щоб повністю стерти старе сховище і замінити його новим.


8. Додаткове програмне забезпечення

  • Клієнти :
    • RapidSVN - кросплатформенний клієнт Subversion на C + +;
    • SmartSVN - кросплатформенний клієнт Subversion на Java;
    • TortoiseSVN - клієнт Subversion, реалізований як розширення для провідника Windows;
    • RabbitVCS - клієнт Subversion, реалізований як розширення для файлового менеджера в Linux (раніше називався NautilusSVN);
    • VisualSVN Server - пакет установки Subversion і графічних утиліт адміністрування для Windows.
  • Модулі :
  • Веб-інтерфейси :
    • Trac - інструмент, заснований на технології Wiki,
    • Redmine - додатково відстежує помилки,
    • USVN - утиліта для створення і управління доступом до репозиторіїв, спеціалізована під SVN,
    • ViewVC,
    • WebSVN,
    • SVNManager - PHP-утиліта для управління репозиторіями (створення, видалення, завантаження і вивантаження, управління користувачами і групами),
    • Submin - утиліта для управління репозиторіями і користувачами, включаючи управління контролем доступу до окремих каталогами в репозиторії.
  • Порівняльна таблиця: Веб-інтерфейси:

Найменування

Опис

Мова

БД

Ліцензія

Сайт

Оновлення

Версія

Trac

інструмент, заснований на технології Wiki

Python

SQLite, PostgreSQL, MySQL і MariaDB

Модифікована ліцензія BSD

trac.edgewall.org

31.01.2011

0.12.2

Redmine

додатково відстежує помилки

Ruby

MySQL, PostgreSQL, SQLite, Oracle.

GNU General Public License

redmine.org

11.07.2011

1.2.1

USVN

утиліта для створення і управління доступом до репозиторіїв, спеціалізована під SVN

PHP

MySQL, SQLlite

CeCill (GPL сумісна ліцензія).

www.usvn.info

20.09.2009

1.0.1

ViewVC

без управління користувачами, не вимагає підтримки DAV web-сервером.

Python

MySQL

Two-clause Berkeley-style

www.viewvc.org

02.12.2010

1.1.8

WebSVN

интерфес перегляду до SVN

PHP

XML

GNU General Public License

websvn.tigris.org

12.10.2010

2.3.2

SVNManager

утиліта для управління репозиторіями (створення, видалення, завантаження і вивантаження, управління користувачами і групами)

PHP

MySQL or SQLite

svnmanager.sourceforge.net

23.08.2009

1.08

Submin (MIT)

утиліта для управління репозиторіями і користувачами, включаючи управління контролем доступу до окремих каталогами в репозиторії

Python

MIT / X

02.02.2011

2.0


Примітки

  1. Англійське cлово subversion можна перевести двояко - як "повалення" (subversion) і як "підверсія" (sub - version)
  2. За назвою програми-клієнта для командного рядка, що входить до складу пакета
  3. Subversion Features - subversion.apache.org / features.html (Англ.)
  4. The Risks of Distributed Version Control - blog.red-bean.com/sussman /? p = 20 Бен Коллінз-Сассман (Англ.)
  5. CVS is out, Subversion is in - www.redhat.com/magazine/010aug05/features/subversion/ (Англ.) Red Hat magazine, серпень 2005
  6. CVS - sourceforge
  7. CVS - система управління версіями - www.citforum.ru/programming/application/cvs/
  8. The Forrester Wave: Software Change and Configuration Management, Q2 2007 - www.collab.net / forrester_wave_report / index.html. Forrester Research. архіві - www.webcitation.org/61CgLWnEn з першоджерела 25 серпня 2011.
  9. Popularity contest statistics for bzr, git, git-core, mercurial, subversion - qa.debian.org / popcon-graph.php? packages = bzr, git, git-core, mercurial, subversion, cvs & show_vote = on & want_legend = on & from_date = 2006 - 01-01 & to_date = & hlght_date = & date_fmt =% Y-% m & beenhere = 1
  10. http://popcon.ubuntu.com/by_inst - popcon.ubuntu.com / by_inst
  11. см. http://subversion.apache.org/docs/ - subversion.apache.org / docs / (Англ.)
  12. Бен Коллінз-Сассман, Брайан У. Фіцпатрік, К. Майкл Пилат Історія Subversion / Управління версіями в Subversion - svnbook.red-bean.com/nightly/ru/svn.intro.whatis.html # svn.intro.history (2007) . - Для Subversion 1.4. Статичний - www.webcitation.org/61CgMJhTd з першоджерела 25 серпня 2011.
  13. Список змін - svn.apache.org / repos / asf / subversion / trunk / CHANGES (Англ.)
  14. Goliath Business News - goliath.ecnext.com/coms2/gi_0199-140633/CollabNet-Primary-Sponsor-of-Subversion.html
  15. Subversion 1.1 Release Notes - subversion.apache.org/docs/release-notes/1.1.html
  16. Subversion 1.2 Release Notes - subversion.apache.org/docs/release-notes/1.2.html
  17. Subversion 1.3 Release Notes - subversion.apache.org/docs/release-notes/1.3.html
  18. Subversion 1.4 Release Notes - subversion.apache.org/docs/release-notes/1.4.html
  19. Subversion 1.5 Release Notes - subversion.apache.org/docs/release-notes/1.5.html
  20. Subversion 1.6 Release Notes - subversion.apache.org/docs/release-notes/1.6.html
  21. Subversion переведена під контроль Apache Software Foundation - nixp.ru
  22. Subversion & the Move to the Apache Software Foundation - subversion.wandisco.com/jomsocial/videos/12-Subversion the Move to the Apache Software Foundation.html? userid = 70, (відеозвернення президента Subversion Corporation)
  23. Apache Subversion 1.7 Release Notes - subversion.apache.org/docs/release-notes/1.7.html
  24. робота з символьними посиланнями підтримується тільки в робочих копіях під UNIX -системами
  25. Терміни сховище і репозиторій є синонімами.
  26. Глава 5. Адміністрування сховища - svnbook.red-bean.com/nightly/ru/svn.reposadmin.basics.html # svn.reposadmin.basics.backends в книзі "Управління версіями в Subversion"
  27. Тут перераховані операції саме з точки зору файлової системи сховища. У робочій копії дії над об'єктами дещо інші. Проте зміни в робочій копії, будучи зафіксованими, викличуть у сховищі описані тут дії. Наприклад, команда svn move в робочій копії зробить операції D, A + в сховище.
  28. Структура проектів на C + + з використанням Subversion і Mxx_ru - rsdn.ru / article / devtools / subversions.xml # EDC
  29. Зберігання складних проектів в репозиторії і установка tag'ов на кілька проектів відразу - rsdn.ru / article / devtools / VrezkaSVN.xml
  30. Inter-File Branching in Perforce - www.perforce.com / perforce / branch.html
  31. Path-Based Authorization - svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html
  32. Типові приклади - svnbook.red-bean.com/nightly/ru/svn.branchmerge.commonuses.html, розділ у книзі "Управління версіями в Subversion, версія 1.4"
  33. Bubble-Up Method - svn.apache.org / repos / asf / subversion / trunk / notes / subversion-design.html # server.fs.struct.bubble-up (Англ.)
  34. У CVS директорію можна перемістити прямо в сховище засобами файлової системи, при цьому файли в ньому не втратять історію. Однак ця модифікація подіє на всі ревізії та гілки файлів в цій директорії (оскільки в CVS директорії взагалі не мають версійність інформації)
  35. Subversion FAQ - subversion.apache.org / faq.html # server-requirements
  36. більш прийнятним варіантом може бути хакинг сховища CVS - перейменування каталогу безпосередньо в сховище на сервері
  37. Runtime Configuration Area. Customizing Your Subversion Experience - www.webcitation.org/61CgMlCTi з першоджерела 25 серпня 2011.
  38. Copy / move-related improvements in Subversion 1.5 - subversion.tigris.org/svn_1.5_releasenotes.html # copy-move-improvements
  39. Merge tracking (foundational) - subversion.tigris.org/svn_1.5_releasenotes.html # merge-tracking
  40. Subversion merge reintegrate - blogs.open.collab.net/svn/2008/07/subversion-merg.html (Англ.)
  41. svn obliterate - subversion.tigris.org / issues / show_bug.cgi? id = 516

Цей текст може містити помилки.

Схожі роботи | скачати
© Усі права захищені
написати до нас