Какой тип сервера Subversion лучше?

Question

Subversion имеет несколько типов серверов:

• svnserve daemon
• svnserve via xinetd
• svn over ssh
• http-сервер
• прямой доступ через файл: /// URLs

Какой из них лучше всего подходит для небольшой системы Linux (от одного до двух пользователей)?

Answer 1

http:

• очень гибкий и простой в управлении
• нет проблем с сетью (порт 80)
• Сторонняя аутентификация (например, LDAP, Active Directory)
• Unix + Win нативная поддержка
• поддержка webdav для редактирования без клиента SVN
• медленно, так как каждое действие запускает новое http-действие ок. В 5-8 раз медленнее svn: //
• особенно медленно в истории
• без шифрования передаваемых данных

https:

• так же, как http
• шифрование передаваемых данных

СВН:

• самая быстрая передача
• нет шифрования пароля в std. настройка: pw доступны для чтения администратору
• проблемы с брандмауэром, так как std.port не используется
• служба демона должна быть запущена
• без шифрования передаваемых данных

SVN + SSH

• почти так же быстро, как SVN: //
• нет Windows OS поставляется со встроенными компонентами SSH, поэтому сторонние инструменты необходимы
• служба демона не нужна
• шифрование паролей
• шифрование передачи

Answer 2

1 из этих опций определенно «худший»: доступ к файлу. Не используйте его, вместо этого используйте один из серверных методов.

Однако, использовать ли HTTP или Svnserve - дело исключительно в предпочтениях. Фактически, вы можете использовать оба одновременно, блокировка записи в репо гарантирует, что вы ничего не испортите, если будете использовать один, а затем использовать другой.

Хотя я предпочитаю просто использовать apache - http более удобен для межсетевого экрана и Интернета, проще подключиться к ldap или другим механизмам аутентификации, и вы также получаете такие функции, как webdav. Производительность может быть ниже, чем у svnserve, но она не особенно заметна (передача данных по сети составляет большую часть любых проблем с производительностью)

Если вам нужна защита для передачи файлов, тогда svnserve + ssh или apache через https - ваш выбор.

Answer 3

Выезд FLOSS Еженедельный Эпизод 28 . Грег Стейн является одним из изобретателей протокола WebDAV для SVN и обсуждает компромиссы. Мой вывод заключается в том, что SVN: быстрее, но реализация http / webdav подходит практически для всех целей.

Answer 4

Для простоты администрирования и безопасности мы используем svn + ssh для всего, что требует коммитного доступа. Мы настроили HTTP-доступ для анонимного (только для чтения) доступа к некоторому коду с открытым исходным кодом, и это намного быстрее; проблема с svn + ssh заключается в том, что он должен запускать соединение ssh и новый svnserve для каждого пользователя для каждой операции, что может стать довольно медленным через некоторое время.

Итак, я бы порекомендовал:

• http для анонимных подключений
• svn + ssh если вам нужно что-то безопасное, относительно быстрое и простое (если ваши пользователи уже настроили ssh и ваши пользователи имеют доступ к серверу)
• https если вам нужно что-то более быстрое, безопасное и вы не возражаете против дополнительных затрат на его администрирование (или если у вас еще не настроен ssh или вы не хотите иметь дело Unix-разрешения)

Answer 5

Я всегда использовал XInetD и HTTP. В HTTP также был запущен WebDAV, поэтому я мог просматривать исходные тексты в Интернете, если бы захотел (или вы можете требовать VPN, если вы хотите шифрование и тип темной сети).

Это действительно зависит от того, под какими ограничениями (если есть) вы находитесь.

Это будет только в локальной сети? Вам понадобится доступ за пределами вашей локальной сети? Если так, у вас будет VPN? У вас есть статический IP-адрес и разрешено ли перенаправлять порты?

Если у вас нет каких-либо ограничений, я бы предложил использовать xinetd (если у вас установлен xientd, если нет - daemon), а затем (если вам нужен удаленный доступ) использовать сервер на основе http, если вам нужно удаленный доступ (вы также можете зашифровать, используя HTTPS, если вы не хотите, чтобы текст и un / pw пересылались).

Большинство других вариантов - больше усилий с меньшими преимуществами.

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

Answer 6

Я отвечал за администрирование svnserve и Apache + SVN для моих команд разработчиков, и я предпочитаю решение на основе http для его гибкости. Я мало что знаю о системном администрировании, в конце концов, я программист, и мне нравилось передавать аутентификацию и авторизацию в Apache.

На обоих зубцах в командах было по 10 ~ 15 человек, и оба метода работали одинаково хорошо. Если вы планируете какое-либо расширение в будущем, вы можете рассмотреть решение на основе http. Его так же легко настроить, как и svnserve, и если вы не собираетесь выставлять сервер в Интернете, вам не нужно слишком беспокоиться о защите и администрировании Apache.

Как пользователь SVN, я предпочитаю интеграцию на основе http с Apache. Мне нравится возможность просматривать хранилище с помощью моего веб-браузера.

Answer 7

Я бы порекомендовал вариант http, так как в настоящее время я использую svn+ssh, и он, похоже, является рыжеватым пасынком доступных протоколов: поддержка инструментов сторонних производителей для svn+ssh неизменно хуже для http.

Answer 8

Если вы собираетесь использовать сервер только на локальной машине и понимаете разрешения Unix, использование file: // urls будет быстрым, простым и безопасным. Аналогично, если вы понимаете разрешения Unix и ssh и вам нужен удаленный доступ к нему, ssh будет отлично работать. Хотя я вижу, что кто-то еще называет это «худшим», я почти уверен, что это просто из-за необходимости понимать разрешения Unix.

Если вам не нравятся или не понятны разрешения Unix, вам нужно использовать svnserve или http. Я бы, вероятно, решил запустить его в xinetd лично.

Наконец, если у вас есть проблемы с брандмауэром или прокси, вам может потребоваться использовать http. Это намного сложнее, и я не думаю, что вы увидите преимущества, поэтому я бы поставил это в конце списка.

Answer 9

Мне нравится sliksvn запускается как служба в Windows, 2 минуты для установки, а затем забыть об этом. Это также идет с инструментами клиента, но также загружает черепаху.

Answer 10

Мне любопытно, почему НЕ ФСФС ?? Важная информация - я управляю системами Windows.

Я сделал много проектов с SVN, и почти все они работали с FSFS. Самый большой репозиторий был около 70 ГБ (экстремальный), наибольшее количество репозиториев было около 700.

У нас никогда не было проблем, хотя мы размещали их в Windows, NetApp и многих других системах хранения. Большую часть времени, когда я спрашивал, почему НЕ использовать только FSFS, проблема заключалась в том, что люди просто не доверяли ему.

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

• Бэкэнд не требуется (или выделенный сервер)
• Быстро и надежно
• Поддерживаются скрипты Hook
• Используются разрешения NTFS
• Легко понять, легко поддерживать, легко управлять

Недостатки:

• Не так просто получить доступ извне вашей сети (VPN)
• Разрешения только на уровне репозитория (Чтение, Чтение / Запись)
• Сценарии хуков работают под текущими учетными данными пользователя (что иногда является преимуществом, иногда недостатком)

Martin