Выбор сервера Subversion

Question

После выбора Apache Subversion для моих нужд контроля версий (и AnkhSVN / TortoiseSVN для моего основногоКлиенты Subversion). Сейчас я пытаюсь выбрать сервер SVN для обеспечения удаленного доступа к репозиториям SVN. Я посмотрел на пару из них:

• CollabNet Subversion Edge
• Сервер VisualSVN

Я установил каждую в ВМ, чтобы опробовать их, но не нашел достаточно, чтобы дифференцировать большинство из них в достаточной степени, чтобы выбрать какую-то конкретную. Теперь у меня есть несколько вещей, с которыми мне нужно определиться.

1. протокол
2. поставщик
3. SSL

1. Я прочитал, что HTTP намного медленнее , чем протокол SVN. Хотя мои проекты обычно не слишком большие (на самом деле только начальный импорт занимает много времени), я хочу получить преимущества производительности SVN, а также избежать того, чтобы мои HTTP-журналы были заполнены записями SVN (который я до сих пор не смог выделить в отдельный файл LOG) .

Мне, однако, нравится веб-интерфейс, который позволяет использовать модуль Apache или VisualSVN. На самом деле мне не нужно предоставлять свои вещи другим (или даже мне вне моей системы), так что это не критически , но, безусловно, допускает возможность расширения.

2. После выбора протокола (при условии, что у меня есть на выбор);Мне нужна помощь, чтобы решить, какого поставщика использовать. Первоначально я использовал модуль Apache из дистрибутива Tigris. С тех пор я удалил это (ну, просто отключил это), и в настоящее время использую VisualSVN (который является HTTP и таким образом медленным). Я видел, как люди одобряют Sharp и Silk, но они кажутся меньшими, инди-дистрибутивы.
Collabnet, с другой стороны, кажется более сложным, чем мне нужно. По сути, если я не могу быть убедительным в одном из них, я в основном просто пытаюсь выбирать между официальным Tigris и VisualSVN.

3. Я также попытался возиться с SSL без особого успеха (я не могу позволить себе настоящий CA, поэтому я использую самоподписанный сертификат в VisualSVN). Я был бы счастлив использовать SVN + SSH / HTTPS, но если я использую его в своей собственной системе, то в этом нет необходимости, и если я использую его извне, мой самоподписанный сертификат не поможет.

Я полагаю, что я мог бы даже использовать локальный репозиторий;Я думаю, что это будет самый быстрый. Однако я бы предпочел более формальное решение в случае расширения. (Я подумал только об использовании клиента TortiseSVN для локальной работы сервера.)

Итак, в заключение, мне нужен совет, какой сервер ( s ?) Использовать. Было бы здорово, если бы я мог заставить VisualSVN предоставлять HTTP-интерфейс для веб-использования, а также использовать протокол SVN для использования в клиентах, предпочтительно с опцией SSL на каждом. Это возможно? Будет ли это слишком много работы (я действительно хочу вернуться к работе над своими проектами, а не всей этой мета-работой).

Большое спасибо.

Редактировать

Я подумал, что должен дать небольшую информацию о моих обстоятельствах, чтобы прояснить ситуацию.

• (В настоящее время)Одиночная система, (более старая P4, Windows, 1 ГБ SDRAM)
• (В настоящее время) Одиночный разработчик (я)
• (В настоящее время) Относительно небольшие проекты (<2 МБ) </li>
• Бесчисленные проекты(> 100 отдельных приложений, игр, библиотек, веб-сайтов и т. Д.)
• Требуются внешние компоненты (особенно моя собственная библиотека, а также сторонний заголовок, Boost и т. Д.)
• ? хм, что еще ...

Answer 1

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

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

---

Я установил VisualSVNСервер , когда он был анонсирован и какое-то время был им доволен.

Однако проблемы со скоростью заставили меня переключиться на основной сервер svnserve, который поставляется как часть пакета командной строки Subversion.

Основная проблема заключается в том, что я работаю с .NET, и я решил добавить несколько внешних ссылок Subversion в мои проекты.

Прежде всего, каждый проект, который я делаю в своем классебиблиотека подписана моим ключом. Во-вторых, внешние сторонние библиотеки, такие как SQLite и NUnit , были добавлены в качестве внешних ссылок.

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

Итак, мое решение для библиотеки классов содержит около 15-20 проектов, каждый из которых имеет хотя бы одну внешнюю ссылку на ключ подписи, все мои проекты данных имеют внешние ссылки на библиотеку SQLite и модульбиблиотека тестов с 4-5 внешними ссылками.

В итоге получилось, что одно обновление на уровне решения, даже если у меня уже были все последние файлы, каталоги и все остальное, заняло около 2 минут. Каждые внешние ссылки выполнялись где-то между 10 и 20 секундами, просто чтобы убедиться, что у меня была нужная ревизия.

Когда я переключился на svnserve, эти 2 минуты были сокращены примерно до 3 секунд. Имейте в виду, это местный трафик, поэтому, конечно, он будет отличаться в Интернете. Проблема в том, что эти 2 минуты были также локальным трафиком.

Так что, хотя мне очень понравился интерфейс, предоставленный мне VisualSVN Server, включая возможность легко настраивать права доступа и пользователей,скорость, которую мне предоставил серверный модуль Apache, была абсолютно ужасна по сравнению с тем, что делает svnserve и собственный протокол Subversion.

Обратите внимание, что с тех пор я установил отдельный сервер Apache, пробежав по множеству файлов конфигурации,и настроить Subversion с Apache, отличным от сервера VisualSVN, просто для того, чтобы убедиться, что это не просто VisualSVN, и я подтвердил, что наблюдаемая мной скорость не была работой команды VisualSVN. Похоже, что протокол HTTP или модули Apache работают не так быстро.

Мой совет, если это возможно, использовать основной сервер svnserve. Чтобы узнать конфигурационные файлы для авторизации и тому подобное, может потребоваться некоторая работа, но один фактор раздражения (т.е. никакого раздражения по скорости вообще) скорее всего перевесит это.

Answer 2

Re скорость доступа: я видел сервер Apache https: SVN, нуждающийся в обновлении оборудования. Кажется, я помню, что в основном нехватка памяти замедляла многочисленные процессы Apache, которые конкурировали за ресурсы машины. Но это было 20 разработчиков, которые работали над проектом с проверенным деревом в 20 ГБ (там было много двоичных файлов, которые часто менялись). И обновление до умеренно оборудованного сервера решило проблему.

Кроме того, в этом же проекте мне пришлось узнать, что SVN на ext3 FS под Linux работает как минимум на порядок быстрее, чем на NTFS под Windows. Отметьте, что: Linux на виртуальной машине, работающей в Windows, занимал в десятую часть времени обновление, конкурирующее с Windows-боксом, на котором виртуальная машина работала . (Мы всегда хотели попробовать этот драйвер OS ext3 для Windows и посмотреть, не сделает ли это SVN быстрее на Windows, чем на его родной FS. Однако я покинул проект прежде, чем мы попытались.)

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

Вот что я хотел бы рассмотретьопределитесь с протоколом: если у вас есть работающая инфраструктура AD или LDAP, которую вы хотели бы использовать для входа в SVN, попробуйте один из вариантов протокола http / https:. Если у вас его нет, и он вам не понадобится, и вы хорошо выполняете вход в систему собственными средствами SVN, почему бы не использовать скорость, обеспечиваемую протоколом svn:?

Я никогда не видел репозитория SVN, к которому люди обращались через WebDAV. IME они всегда хотят иметь историю при доступе по сети (WebDAV не предоставляет этого, AFAIK), поэтому они использовали один из веб-интерфейсов для SVN. Я никогда не проверял, но я просто предполагаю, что такие вещи, как ViewVC и тому подобное, не заботятся о том, какой протокол они используют для доступа к репо.

Что касается дистрибутива, который вы хотите использовать - я думаю, что это в основном зависит от личных предпочтений, так как код в любом случае одинаков. Я предпочитаю загрузки, для которых мне не нужно регистрироваться, и дистрибутивы, явно ориентированные на платформу, на которую я хочу их установить. Но это, наверное, только я.

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

Answer 3

Мы поставляем наши SVN-репозитории, используя HTTP, предоставляемый Apache, работающим под CentOS 5.3, из виртуальной машины XEN.

Я бы заметил, что выполнение коммита или извлечение большого файла передает этот файл вблизко к скорости сети. Несмотря на то, что при проверке или отправке большого количества небольших файлов накладные расходы на HTTP-запросы значительно заметнее.

По сравнению с временными рамками при компиляции кода SubVersion не является узким местом внутри компании.

(Это мой опыт работы с командой из 10 разработчиков)

Answer 4

Я пользуюсь CollabNet дома и на работе. Все было хорошо - никаких претензий к производительности.