SvnServe в Windows с аутентификацией Active Directory

Пройдите простой маршрут и просто установите сервер Visual SVN.

http://www.visualsvn.com/server/

Установите его на сервере, подключенном к вашей Active Directory. Теперь у вас есть SVN через http(s) с аутентификацией AD. Управляйте разрешениями, используя удобный инструмент MMC, который входит в комплект поставки. От 0 до развернутого примерно за 15 минут.

Имейте в виду, что доступ file:// не рекомендуется для SVN-репозиториев, а скорее для инструментов администратора. Проблема с доступом к файлу заключается в том, что у вас нет сервера в середине, чтобы убедиться, что все записи записаны правильно. Так что прекратите использовать это как можно скорее.

Svnserve (или Apache) намного лучше, но у вас будут те же проблемы с производительностью - лучше не будет, потому что ваша сеть использует протоколы http или svn вместо smb. Если ваш доступ сегодня медленный, он все равно будет медленным, если вы не сделаете что-то со своей сетью или файловой системой (или что-то еще, что делает это медленным).

Тем не менее, переход на Apache или Svnserve стоит сделать сам по себе.

Существует проблема с svnserve и библиотеками sasl, как недавно упоминалось в списке рассылки svn. Проблема в том, что протокол svn не допускает простой текст, но saslauthd допускает только аутентификацию в виде простого текста. Конечный результат - он просто не работает, и это известная проблема.

Однако не все так плохо, если вы работаете в Windows, просто установите VisualSVN Server. Это лучший пакет и предоставляет вам установку Apache, работающую в качестве службы Windows с полным управлением оснастками и аутентификацией в активном каталоге одним щелчком переключателя во время установки. Вы даже можете поместить acls в каталоги или файлы в репозитории.

Если нет, я бы по-прежнему рекомендовал Apache, так как конфигурация для него лучше задокументирована, и он поддерживает аутентификацию LDAP (которая работает с AD). Есть много постов в блоге, описывающих, как это сделать.

Производительность http вместо svn будет медленнее, но я сомневаюсь, что вы заметите это, если не будете устанавливать одновременно и извлекать / фиксировать большой каталог. Попробуйте - вы можете одновременно обслуживать репо с Apache в Svnserve. (хотя я бы проверил это утверждение, прежде чем применять его на практике).

Короче говоря, переключение вашего репозитория SVN с общего сетевого ресурса на SVNServe или Apache/WebDAV не приведет к повышению производительности ваших клиентов. Во всяком случае, клиенты увидят худшую производительность.

Конечно, вышеизложенное предполагает, что вы планируете продолжить работу с хранилищем на том же сервере, на котором он сейчас находится. Если вы переместите свои SVN-репозитории на более мощный сервер, вы можете увидеть улучшение производительности.

Вы проверили, перегружен ли текущий сервер? Он также обслуживает много клиентов / файлов не SVN? Если это так, вы, вероятно, увидите улучшение производительности, перенеся свои репозитории SVN на выделенный сервер. Если у вас есть несколько репозиториев на одном сервере, рассмотрите возможность их разделения на несколько серверов. (При необходимости вы можете разбить существующие отдельные репозитории на несколько репозиториев.)

Однако на самом деле вам нужно выяснить, почему существующая производительность низкая. Сначала проанализируйте нагрузку на текущий сервер. Производительность обычно ограничивается емкостью какого-либо системного ресурса, главным образом вашей оперативной памяти, процессора, скорости дискового ввода-вывода, пропускной способности сетевого ввода-вывода. Попробуйте ответить на эти вопросы:

• Ваш процессор привязан к 100%, или у вас много свободных циклов? Использование ЦП может варьироваться, но если оно составляет в среднем около 100% или около этого, вам могут потребоваться более / более быстрые ЦП.

• Сколько у вас свободной оперативной памяти (в% от общего объема)? Сколько пространства подкачки вы используете (опять же,% от общего числа)? Если объем свободной оперативной памяти составляет менее 10%, возможно, у вас заканчивается ОЗУ, что заставляет систему использовать замену диска. Это замедляет все, но это хуже для вас, потому что подкачка конкурирует с активностью SVN для ограниченного дискового ввода-вывода.

• Сколько данных (массовая передача) вы перемещаете на / с диска в секунду? Сколько запросов в секунду выполняет ваш диск? Как долго ваши дисковые очереди? Диски вашего сервера должны быть рассчитаны на массовую передачу данных и скорость поиска. (Если нет, вы можете сами их сравнить.) Если средняя скорость передачи и поиска равна или близка к максимальной, вам необходимо использовать более быстрые диски. Если вы используете RAID, добавьте больше дисков таким образом, чтобы повысить производительность. Если вы не используете RAID, начните использовать его.

• Сколько сетевых данных вы передаете на сервер или с сервера в секунду? Если эта скорость приближается к 80-90% от номинального максимума (например, 10 Мбит / с, 100 Мбит / с, 1 Гбит / с), вы, вероятно, выходите за пределы своего сетевого соединения. (Обратите внимание, что более дешевые сетевые адаптеры или плохие драйверы могут иметь существенно более низкие максимумы - обязательно проверьте вашу ссылку.) Попробуйте перейти на более быструю связь или посмотрите, поддерживают ли ваши драйверы сетевых адаптеров связывание (также называемое "объединение каналов" или "объединение каналов").) для повышения производительности.

Получив ответы на эти вопросы для вашей среды, попробуйте увеличить емкость любых ограниченных ресурсов. Это может означать обновление или замену сервера или, возможно, обновление сети.

Извините, нет Svnserve с аутентификацией Windows. Тем не менее, я использую Svnserve с SASL и вручную управляю учетными записями, потому что число реальных программистов, использующих SVN, здесь очень мало.

Тот факт, что вы готовы рисковать совместным использованием файлов Windows, чтобы делать SVN, показывает, что вы должны быть в отчаянном положении, поэтому я рекомендую вместо этого SSL через Apache, где вы можете получить аутентификацию Windows. Он использует SSL вместо SVN, но он достаточно близок. Вот и я:

1. Отключить общий доступ к файлам.
2. Установите CollabNet Subversion Server (бесплатно). Это включает в себя Apache, который теперь позволяет вам получать доступ к SVN.
3. устанавливать mod_auth_sspi в Apache и настроить его в httpd.conf это идет с сервером CollabNet Subversion.

Я использую HTTPS и SVN, но лично я предпочитаю вручную управлять учетными записями SASL, чтобы получить дополнительный бит скорости протокола SVN, который немного быстрее, чем HTTPS.

Это не совсем то же самое, но у меня есть репозиторий SVN на сервере Linux. Сервер не работает svnserve, но позволяет пользователям использовать svn поверх ssh. Поскольку сервер Linux является рядовым сервером AD, а пользователи тоже из AD, это довольно простое и безопасное решение.