Сейчас моя компания использует сетевой ресурс для связи с репозиторием SVN. Это очень медленно, поэтому я хотел бы переключиться на SVNSERVE.
Основная причина, по которой моя компания выбрала путь файловой системы, заключалась в том, что это упростило обеспечение безопасности с помощью нашей существующей системы аутентификации активного каталога.
Из того, что я прочитал, можно использовать SvnServe с активным каталогом, если вы используете Библиотека Sasl. Мне просто было интересно, делает ли это кто-нибудь еще и мог бы дать некоторые указания по настройке, поскольку это, похоже, нигде не задокументировано.
Спасибо
Правки
У нас есть svn на быстром сервере, но, к сожалению, он используется для других корпоративных файловых ресурсов и служб.
Мне сказали, что протокол HTTP не будет быстрее, чем file: // с SMB. Есть ли у кого-нибудь документация по этому поводу. Я полагал, что настоящая модель клиент-сервер будет работать лучше. У нас есть около 13 разработчиков и сервер сборки, которые коммитят и обновляют его весь день.
Пойдите по мертвому простому маршруту и просто установите Visual SVN server.
http://www.visualsvn.com/server/
Установите его на сервере, подключенном к вашей Active Directory. Теперь у вас есть SVN через http (s) с аутентификацией AD. Управляйте разрешениями с помощью удобного инструмента Dandy MMC, который входит в комплект поставки. С 0 до развертывания примерно за 15 минут.
Имейте в виду, что доступ к файлу: // не рекомендуется для репозиториев SVN, его больше для инструментов администратора. Проблема с доступом к файлам заключается в том, что у вас нет сервера посередине, чтобы убедиться, что все записи записываются правильно. Так что прекратите использовать его как можно скорее.
Svnserve (или Apache) намного лучше, но у вас будут те же проблемы с производительностью - это не улучшится, потому что ваша сеть использует протоколы http или svn вместо smb. Если ваш доступ сегодня медленный, он все равно будет медленным, если вы не сделаете что-то со своей сетью или файловой системой (или чем-то еще, что замедляет ее).
Однако переход на Apache или Svnserve стоит того.
Как недавно упоминалось в списке рассылки svn, существует проблема с svnserve и библиотеками sasl. Проблема в том, что протокол svn не разрешает использование обычного текста, а авторизация с использованием обычного текста разрешена только saslauthd. Конечный результат - это просто не работает, и является известная проблема.
Однако не все так плохо, если вы работаете в Windows, просто установите VisualSVN Server. Это лучшая часть упаковки, которая предоставляет вам установку Apache, работающую как службу Windows с управлением оснастками и аутентификацией в активном каталоге, всего одним щелчком переключателя во время установки. Вы даже можете поместить ACL в каталоги или файлы в репо.
Если нет, я бы по-прежнему рекомендовал Apache, поскольку его конфигурация лучше документирована, и он поддерживает аутентификацию LDAP (которая работает с AD). В блогах есть множество сообщений о том, как это сделать.
Производительность http вместо svn будет медленнее, но я сомневаюсь, что вы это заметите, если вы не установите одновременно и checkout / commit большого каталога. Попробуйте - вы можете одновременно обслуживать репозиторий, обслуживаемый Apache, с помощью Svnserve. (хотя я бы проверил это утверждение, прежде чем применять его на практике).
К сожалению, нет Svnserve с авторизацией Windows. Тем не менее, я использую Svnserve с SASL и вручную управляю учетными записями, потому что количество реальных программистов, использующих SVN, здесь очень мало.
Тот факт, что вы готовы рискнуть для совместного использования файлов Windows, чтобы использовать SVN, показывает, что вы, должно быть, находитесь в безвыходной ситуации, поэтому я рекомендую вместо этого использовать SSL поверх Apache, где вы жестяная банка получить аутентификацию Windows. Он использует SSL вместо SVN, но достаточно близко. Вот и все:
mod_auth_sspi в Apache и настройте его в httpd.conf который поставляется с сервером CollabNet Subversion.Я использую и HTTPS, и SVN, но лично предпочитаю вручную управлять учетными записями SASL, чтобы получить дополнительную скорость протокола SVN, который немного быстрее, чем HTTPS.
Короче говоря, переключение репозитория SVN с общего сетевого ресурса на SVNServe или Apache / WebDAV не улучшит производительность ваших клиентов. Во всяком случае, клиенты увидят худшую производительность.
Конечно, вышесказанное предполагает, что вы планируете продолжить работу с репозиторием на тем же сервер, на котором он сейчас находится. Если вы переместите свои репозитории SVN на более мощный сервер, вы можете увидеть улучшение производительности.
Вы проверили, не перегружен ли текущий сервер? Он также обслуживает множество клиентов / файлов, не относящихся к SVN? Если это так, вы, вероятно, увидите улучшение производительности, переместив свои репозитории SVN на выделенный сервер. Если у вас есть несколько репозиториев на одном сервере, рассмотрите возможность разделения их на несколько серверов. (Вы можете разделить существующие отдельные репозитории на несколько репозиториев, если необходимо, чтобы помочь с этим.)
На самом деле, вам нужно выяснить, почему существующая производительность низкая. Сначала проанализируйте нагрузку на текущий сервер. Производительность обычно ограничивается емкостью некоторого системного ресурса, в основном вашей оперативной памятью, процессором, скоростью дискового ввода-вывода, возможностями сетевого ввода-вывода. Попробуйте ответить на эти вопросы:
Ваш ЦП загружен на 100% или у вас много свободных циклов? Использование ЦП может варьироваться, но если оно в среднем составляет 100% или около него, вам может потребоваться больше / более быстрых ЦП.
Сколько у вас свободной оперативной памяти (в% от общего количества)? Сколько места подкачки вы используете (опять же, в% от общего количества)? Если ваша свободная оперативная память меньше 10%, возможно, у вас заканчивается оперативная память, что вынуждает систему вместо этого использовать подкачку диска. Это все замедляет, но для вас хуже, потому что свопинг конкурирует с активностью SVN за ограниченный дисковый ввод-вывод.
Сколько данных (массовая передача) вы перемещаете на / с диска в секунду? Сколько поисков в секунду выполняет ваш диск? Как долго ваши дисковые очереди? Диски вашего сервера должны быть рассчитаны на скорость массовой передачи данных и поиска. (В противном случае вы можете протестировать их самостоятельно.) Если ваши средние скорости передачи и поиска близки к максимальным или близки к максимальным, вам необходимо использовать более быстрые диски. Если вы используете RAID, добавьте больше дисков, чтобы повысить производительность. Если вы не используете RAID, начните его использовать.
Сколько сетевых данных вы передаете на / с сервера в секунду? Если эта скорость приближается к 80-90% от номинального максимума (например, 10 Мбит / с, 100 Мбит / с, 1 Гбит / с), вы, вероятно, достигли пределов своего сетевого соединения. (Обратите внимание, что более дешевые сетевые адаптеры или плохие драйверы могут иметь значительно более низкие максимумы - для уверенности проверьте свою ссылку.) Попробуйте перейти на более быструю ссылку или посмотрите, поддерживают ли ваши драйверы сетевых адаптеров связывание (также называемое «агрегацией каналов» или «объединением каналов». ) для повышения производительности.
Получив ответы на эти вопросы для вашей среды, попробуйте увеличить емкость любых ограниченных ресурсов. Это может означать обновление или замену сервера или, возможно, обновление сети.
Это не совсем то же самое, но у меня есть репозиторий svn на сервере Linux. На сервере не работает svnserve, но пользователи могут использовать svn поверх ssh. Поскольку сервер Linux является рядовым сервером AD, а пользователи тоже из AD, это довольно простое и безопасное решение.