Подход к использованию SVN и TortoiseSVN

Question

Похоже, что наилучший подход к использованию SVN и TortoiseSVN заключается в том, чтобы каждый разработчик имел собственную копию файлов проекта?

т.е. не используйте общую область сетевого диска для хранения копии файлов проекта (с> 1 человеком, обновляющим файлы в области, а затем каждый пытается выполнить SVN коммит / обновления ..)

Могут ли люди подтвердить этот подход каждого разработчика собственной копией файлов проекта из SVN?

Я также заметил эти вопросы и ответы на форуме, которые, как мне кажется, подтверждают этот подход каждого разработчика, владеющего собственной копией файлов проекта SVN:

Как настроить общую рабочую копию в Subversion

Использование SVN отдельно или в небольших рабочих группах - подход к рабочему процессу?

Когда мы использовали общую сетевую область для файлов проекта вне SVN, мне удалось получитьнекоторые интересные ошибки / ситуации!

Например:

Ошибка фиксации не удалась (подробности следуют):

Каталог ошибок... устарела

Ошибка Файл не найден: транзакция '2134-1sc', путь ...

Ошибка Сначала необходимо обновить рабочую копию.

Ошибка фиксации не удалась (подробности приведены ниже):

Ошибка отмены фиксации: '.....'

Папка ошибок .... остается в конфликте

Ошибка sqllike [S10]: ошибка ввода-вывода диска

Answer 1

Признаюсь, это был мой подход, когда я начал кодировать в начале 2000-х годов:

• Общий файловый сервер, на котором будет размещено все, что должно быть скопировано.
• Общий сервер приложений, предоставляющий все сервисы: веб-сервер, сервер баз данных и т. Д.

Программисты будут редактировать файлы прямо на файловом сервере и тестировать их через сервер приложений (который также имеет доступ к тому жефайлы).

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

• Контроль версий не только делает это ненужным, но и не работает должным образом.SVN, в частности, выполняет задачи с интенсивной файловой системой, особеннодля некоторых операций, таких как svn update, требующих монопольного доступа к файлам и текущего формата рабочей копии, используется двоичный файл реляционной базы данных, который требует монопольной блокировки (именно это подчеркивают ваши сообщения об ошибках).

• Современные IDE и инструменты программирования часто строятся на ожидании молниеносного доступа к диску и ужасно отстают от сетевых дисков (быстрая проводная локальная сеть не может конкурировать с локальным SSD, и, по моему опыту, большинство локальных сетей работают плохо).

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

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

• Возможность абсолютно свободно играть с вашим кодом - этоповышение качества, инновации и совместные среды мешают этому.

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

Официальная книга Контроль версий с Subversion по-прежнему является хорошей отправной точкой.К сожалению, он устарел, а новые функции едва документированы.Я подозреваю, что команда svn становится недоукомплектованной, поскольку Subversion заменяется более популярными системами (а именно git).