Чи можна налаштувати svn-сервер на локальному комп'ютері без доступу до мережі?

Я хочу створити сховище SVN на своєму комп’ютері без доступу до мережі. Я працюю над кодом без співпраці, тому не хочу, щоб він був загальнодоступним.

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

Тож мені було цікаво, чи можу я встановити локальний сервер на своїй машині Windows XP, до якого я отримую доступ, навіть коли у мене немає підключення до Інтернету?

Найпростіший спосіб налаштування локального сервера - це використання svnserve :

Subversion включає Svnserve - легкий автономний сервер, який використовує користувацький протокол за звичайним TCP / IP-з'єднанням. Він ідеально підходить для менших установок або там, де повноцінно підірваний сервер Apache неможливо використовувати.

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

Ви можете отримати доступ до сховища за допомогою протоколу file: //, тому вам знадобиться тільки встановлений SVN Tortoise та більше нічого. Дивіться це запитання у FAQ: Чи можна використовувати TortoiseSVN без сервера?

Ви навіть можете мати сховище в USB-пристрої, щоб ви могли взяти джерело з собою та працювати з іншими комп'ютерами.

Якщо ви використовуєте TortoiseSVN , ви можете знайти вказівки у створенні сховища за допомогою TortoiseSVN :

1. Відкрийте провідник Windows

2. Створіть нову папку та назвіть її, наприклад, SVNRepository

3. Клацніть правою кнопкою миші на новоствореній папці та виберіть TortoiseSVN → Створити тут сховище ....

Безпосередньо вище на цій сторінці також описано, як створити сховище з командного рядка .

Сказавши це, я рекомендую вам поглянути на Mercurial або Git як на альтернативу svn. Якщо ви знайомі з TortoiseSvn, ви знайдете TortoiseHg і TortoiseGit простий перехід, плюс це надає вам можливість працювати розподіленим способом пізніше, якщо вам потрібно. Наприклад, раніше я використовував картки пам'яті для передачі hgсховищ між машинами без доступу до мережі, і коли ви працюєте таким чином, ви отримуєте безкоштовну резервну копію в угоду.

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

Для того, щоб використовувати цей сервер, ви маєте в будь-якому порожньому каталозі в будь-якому місці виклику CLI-команди svnadmin з відповідною підкомандою та параметрами (не можу пригадати, чи є адміністративні програми в наборі клієнтів CLI чи ні і не можуть перевірте це - я не встановив CLI svn-клієнт, тільки TortoiseSVN, у яких ці програми встановлені у версії 1.7) - сподіваюся, ви зможете його знайти.

svnadmin helpпокажіть нам усі доступні підкоманди, ми зараз зацікавлені в підкоманді create.

svnadmin help create надайте всі необхідні нам деталі

create: usage: svnadmin create REPOS_PATH

Create a new, empty repository at REPOS_PATH.

Valid options:
...

На початковому етапі для першого репо ми можемо проігнорувати всі параметри тонкої настройки та запам’ятати лише основну форму svnadmin create REPOS_PATH, там REPOS_PATH - абсолютний або відносний шлях до порожнього каталогу, запланованого на репо. Оскільки в більшості випадків звичайні Windows-люди для крос-платформних застосувань можуть заплутатися в людях, які позначення (прямі або зворотні косої риси) використовувати в шляху (metoo), найбезпечнішим способом є cdмісце розташування, звідки наш редактор видно без тривалого шляху - батько майбутнього репо-каталогу або сам каталог. Для запланованого на репо z:\Main раніше svnadmin create

Z:
cd \Main

і, нарешті,

svnadmin create .

У результаті ми створюємо порожній сховище в каталозі, яке показано в Провіднику Windows із спеціальним значком як контент-індикатором

Тепер, кожного разу, коли потрібен цей сховище , ми використовуємо звичайні SVN-команди, там частина URL-адреси або параметри здаються такими, якfile:///Z:/Main

c:\>svn ls file:///Z:/Main
branches/
tags/
trunk/

(Я додав стандартне дерево репозиторію в репо).

Розберемо цю дивну URL-адресу:

• file:///, як і для будь-якої URL-адреси, означає протокол доступу, у нашому випадку протокол є спеціальним і має три, а не дві косої риски
• Z:/Main це повний шлях до репо з диском і шлях всередині диска, там усі нахили на вікні Windows замінені на "класичні" косої риски

З будь-якого іншого пункту цей сховище не має відмінностей від "Big Brothers" зі спеціальними Subversion-серверами

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

По-перше, так, ви можете використовувати Subversion на автономному комп'ютері - ви можете встановити сервер локально або можете працювати з файлом: //

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

Однією з переваг DVCS є те, що після встановлення інструментів сховища знаходяться в папці, і ви можете синхронізувати вміст між різними папками, що містять "ту саму" репо, доки у вас є доступ до файлового рівня. У вас також є можливість поговорити з "серверними" версіями тих репостів (які є приватним розміщенням або доступні як послуга). Це робить життя набагато простішим за допомогою всього локально.

Є і інші переваги для DVCS.

Як я вже зазначав, я не думаю, що у вас справді є відповідне рішення VCS, поки ваш код є щонайменше на двох машинах (зокрема, на двох чітких жорстких дисках і в ідеалі в більш ніж одному місці - хоча клонування і натискання говорити на USB-накопичувач або "хмарне" зберігання (skydrive, dropbox тощо) - це ще один спосіб, який також повинен працювати.

З точки зору DVCS - я би дивився на Mercurial (Hg) і Git, а також на Veracity . Я використовую Mercurial, тому що його все ще приємно на Windows ...

Якщо ви погоджуєтесь із сервісами розміщених сервісів, я дійсно погоджуюся, що github можна похвалити дуже багато - але є також багато приємних речей щодо bitbucket та Fogbugz / Kiln ... і те саме, мабуть, стосується багатьох інших служб яких я не перераховував (наприклад, http://beanstalkapp.com/, про який було сказано в минулому сьогодні на Twitter)

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

Однак у перспективі вам, мабуть, краще використовувати розподілений SCM, найкращі кандидати - це git (потужніша, крута крива навчання, найкраще працює на * nix) та меркуріальна (трохи менш потужна, легка в навчанні, працює однаково добре на windows і * nix). За допомогою них ваша робоча копія містить весь сховище, і ви можете зробити стільки клонів (віддалених або локальних), скільки бажаєте. Ви можете почати локально, і якщо ви вирішите розмістити сховище зовні, просто клонуйте існуюче місцеве сховище у зовнішнє місце, і ви можете в будь-який час синхронізуватись в обох напрямках. А ще краще, оскільки кожен ваш клон містить всю історію проекту, SCM працює як резервна система. З підривом, якщо ваш сервер загине, а ви не створили резервну копію, ваша історія піде - з git,

http://hginit.com/ має чудовий підручник з початку роботи з mercurial.

Є досить багато хостингових компаній SVN які пропонують безкоштовний рахунок для одного або двох розробників і не вимагають, щоб ваш код був відкритим. Перевірте пов'язаний графік на суму $ 0, плата за OSS = NO. Я нараховую дев'ять постачальників, які відповідають цим критеріям зараз.

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

• Ви можете отримати доступ до свого коду з будь-якого місця без додаткових налаштувань.

• Зберігання коду поза сайтом захищає вас від збоїв на жорсткому диску, пожеж тощо.

• Низькі адміністративні витрати.