Должно ли это быть на серверах разработки или сервере Subversion?
Я предполагаю, что это можно было бы расширить до любой системы контроля версий клиент-сервер.
Должно ли это быть на серверах разработки или сервере Subversion?
Я предполагаю, что это можно было бы расширить до любой системы контроля версий клиент-сервер.
Физический репозиторий должен находиться в стабильной системе, которая получает регулярные резервные копии.
Как правило, сервер разработки не соответствует этому описанию... может быть приемлемым поставить сервер apache на dev-сервер и удаленно размещать файлы на стабильном резервном файловом сервере (хотя есть несколько с этим подходом), если вы не можете получить дополнительные ресурсы сервера. Хостинг на сервере dev может быть прекрасным, если у вас есть агрессивная система резервного копирования для защиты вашего кода...
Просто имейте в виду, что серверы-разработчики подвержены изменениям конфигурации, сбрасываются или иным образом удаляются, что может привести к вашему репо в критический момент.
Мне нравится держать мой на своем собственном сервере только потому, что, на мой взгляд, один из самых важных серверов в организации и хранение на своем собственном сервере помогает администраторам делать резервные копии и другие операции по обслуживанию. И поскольку сервер так важен, вы не хотите, чтобы другие разработчики набрасывались на него каким-либо образом, что могло бы скомпрометировать его случайно.
Кроме того, если у вас есть куча разработчиков и активный сервер непрерывной интеграции, вы можете немного исправить процессор, и последнее, что вы хотите сделать, - это что-то, что стоит на пути выполнения ваших изменений кода
В дополнение к тому, что другие люди упоминают о том, что серверы dev регулярно выгружаются, есть и аргумент производительности. Если кто-то занимается разработкой или тестированием на сервере разработки, вы не хотите, чтобы это замедляло сервер SVN для проверок или синхронизации. Также, если вы решите запустить что-то вроде непрерывной интеграции на одном сервере, вы не хотите, чтобы все ваши модульные тесты приводили в порядок регулярные действия dev/test на этом сервере.
Я держу мой на сервере разработки, который также запускает Trac, Apache, где размещается автоматически обновленная копия проекта JavaDocs и платформа построения CI. Проект должен быть достаточно эпическим, чтобы требовать выделенный сервер Subversion.
Однако имейте в виду, что очень важно поддерживать резервное копирование репозитория Subversion на другой машине в другом месте - ваш репозиторий - ваш самый ценный актив!
Ящики для разработки по определению будут разбиты и упадут. Он поставляется с территорией!
Вы действительно хотите, чтобы это произошло с репозиториями исходного кода?...
В моей фирме мы помещаем его на выделенный компьютер, который обеспечивает избыточное хранение. Я полагаю, что в нашей культуре мы уделяем большое внимание источнику, времени и усилий, необходимых для создания наших исходных кодов. Мы никогда не ставили на какой-либо испытательный аппарат, который мог бы стать поврежденным или протертым, потому что конфигурация стала неуправляемой.
Woops. мы также сохраняем отслеживание дефектов в одной коробке, но по той же причине.
Мы используем чистый, чистый лист для наших репозиториев. В частности, мы используем Slicehost для нашего основного репозитория.
Мы начали с 256 Мб фрагмента и обновили позже до 512 МБ. Slicehost отлично работает, потому что вы знаете, что у вас есть полностью чистый сервер, и вы можете сами создавать нужные вещи.
Статьи Slicehosts являются первоклассными.
Наш сервер репо выглядит следующим образом:
И об этом. Не так много накладных расходов.
Изменить: Не пытайтесь продать Slicehost здесь, так что если это не кошерный, дайте мне знать!
Изменить еще раз: Джеймс дает отличную оценку хостинга проприетарного кода на стороннем сервере. При выборе хозяина, безусловно, следует проявлять особую осторожность. К сожалению, многие компании просто не располагают ресурсами для создания и управления серверами в доме, где мы оказались перед выбором хоста для нашего кода.
Всегда лучше хранить свои репозитории на стабильном сервере, где вы можете надежно брать резервные копии, когда это необходимо.