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

Question

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

• CollabNet Subversion Edge
• VisualSVN Server

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

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 без особого успеха (я не могу позволить себе настоящий СА, поэтому я использую самозаверяющий сертификат в VisualSVN). Я был бы счастлив использовать SVN + SSH/HTTPS, но если я использую его в своей собственной системе, тогда это не обязательно, и если я использую его извне, то мой самозаверяющий сертификат не поможет.

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

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

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

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

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

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

Answer 1

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

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

---

Я установил VisualSVN Server, когда было объявлено, и была вполне счастлива с ним на некоторое время.

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

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

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

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

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

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

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