Где должен быть репозиторий Subversion?
Должен ли он быть на серверах разработки или на сервере Subversion?
Я полагаю, это можно расширить до любой системы контроля версий клиент-сервер.
Ответы 8
Физический репозиторий должен находиться в стабильной системе с регулярным резервным копированием.
Как правило, сервер разработки не подходит под это описание ... может быть приемлемым разместить сервер apache на сервере разработки и разместить файлы удаленно на стабильном резервном файловом сервере (хотя с этим есть ряд ошибок. подход), если у вас нет возможности получить дополнительные ресурсы сервера. Размещение его на сервере разработки может быть приемлемым, если у вас есть агрессивная система резервного копирования для защиты вашего кода ...
Просто имейте в виду, что серверы разработчиков подвержены изменениям конфигурации, сдуваются или иным образом портятся, что может привести к сбою вашего репо в критический момент.
Как бы вы обычно его поддерживали? rsync?
У вас есть несколько вариантов, включая rsync. Если ваше репо было настроено с использованием Berkley FS, вы можете запустить несколько сценариев горячего резервного копирования. Вы можете создавать резервные копии этих файлов, используя любой механизм резервного копирования. Если вы используете FSFS, вы можете сделать живую резервную копию репо напрямую.
Я храню свой на сервере разработки, на котором также работает Trac, Apache, на котором размещается автоматически обновляемая копия проекта JavaDocs, и платформа сборки CI. Проект должен иметь довольно грандиозные размеры, чтобы для него требовался выделенный сервер Subversion.
Однако имейте в виду, что очень важно хранить резервную копию вашего репозитория Subversion на другом компьютере в другом месте - ваш репозиторий является вашим самым ценным активом!
Мне нравится держать свой на отдельном сервере только потому, что, на мой взгляд, это один из самых важных серверов в организации, и хранение его на собственном сервере помогает администраторам выполнять резервное копирование и другие действия по обслуживанию. И поскольку сервер так важен, вы не хотите, чтобы другие разработчики возились с ним каким-либо образом, что могло бы случайно его скомпрометировать.
Кроме того, если у вас есть группа разработчиков и работает активный сервер непрерывной интеграции, вы можете немного увеличить процессор, и последнее, что вы хотите сделать, это иметь что-то, что мешает вам вносить изменения в код.
Ящики для разработки, по определению, будут разбиты и упадут. Он идет с территорией!
Вы действительно хотите, чтобы это произошло с вашими репозиториями исходного кода? ...
В дополнение к тому, что другие люди упоминали о регулярном уничтожении серверов разработчиков, есть еще аргумент в пользу производительности. Если кто-то занимается разработкой или тестированием на сервере разработки, вы не хотите, чтобы это замедляло работу сервера SVN для проверки или синхронизации. Кроме того, если вы решите запустить что-то вроде непрерывной интеграции на одном сервере, вы не хотите, чтобы все ваши модульные тесты тормозили регулярные операции разработки / тестирования на этом сервере.
В моей компании мы устанавливаем его на выделенную машину, которая обеспечивает избыточное хранилище. Я полагаю, что в нашей культуре мы высоко ценим источник, а также время и усилия, необходимые для создания наших исходных кодов. Мы никогда не устанавливали какой-либо тестовый компьютер, который мог быть поврежден или полностью стерто из-за того, что конфигурация стала неуправляемой.
шлепает. мы также отслеживаем дефекты в той же коробке, но по той же причине.
Мы используем чистый, чистый лист для наших репозиториев. В частности, мы используем Slicehost для нашего основного репозитория.
Мы начали с сегмента 256 Мбайт и позже обновили его до 512 Мбайт. Slicehost великолепен, потому что вы знаете, что у вас есть полностью чистый сервер для начала, и вы можете создавать то, что вам нужно, самостоятельно.
Статьи Slicehosts первоклассные.
Наш репо-сервер выглядит так:
- Убунту Харди Херон
- Subversion
- Apache
- Рубин на рельсах
- Склад
- Пассажир для обслуживания хранилища через Apache
- Ежедневное и еженедельное резервное копирование через Slicehost
Вот и все. Не много накладных расходов.
Обновлено: не пытаюсь продавать Slicehost здесь, поэтому, если это не кошерно, дайте мне знать!
Отредактируйте еще раз: Джеймс отлично замечает, что размещает проприетарный код на стороннем сервере. При выборе хоста для подобных действий, безусловно, следует проявлять особую осторожность. К сожалению, у многих компаний просто нет ресурсов для создания и управления серверами внутри компании, в чем мы и оказались до выбора хоста для нашего кода.
Размещение вашего кода с удаленными, неустановленными сторонними организациями сопряжено с рисками ОГРОМНЫЙ, которые следует сопоставить с преимуществами. Банкротство, безопасность, кража IP, сбои в работе, проблемы с подключением к сети и т. д. Могут в критический момент оставить вас на откуп сторонней компании.
Вот почему у вас автоматическое резервное копирование, Джеймс.
Как автоматическое резервное копирование помогает при краже IP-адресов третьей стороной? А автоматическое резервное копирование не изменит того факта, что у вас нет локальных серверов. Если служба хостинга прекратит работу, через какое время вы снова заработаете? Во сколько вам обойдется эта задержка?
IP = интеллектуальная собственность, например, кража вашего кода, алгоритмов или другой ценной информации, хранящейся на их серверах.
Всегда лучше держать ваши репозитории на стабильном сервере, где вы можете надежно делать резервные копии, когда это необходимо.
Не могли бы вы описать некоторые цели или ограничения, позволяющие дать более аналитический ответ на этот вопрос?