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

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

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

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

Если вам нужна безопасность для передачи файлов, тогда svnserve + ssh,

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

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

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

Я бы порекомендовал:

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

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

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

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

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

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

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

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

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

В большинстве других вариантов больше усилий с меньшими затратами выгода.

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

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

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

Как пользователь SVN, я предпочитаю интеграцию на основе http с Apache.

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

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

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

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

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

Недостатки:

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

Мартин