Есть ли недостатки в доступе к репозиториям Subversion через file: // для индивидуального разработчика?

Question

Если на вашем компьютере разработки установлен Subversion и вы не работаете в команде, есть ли причина, по которой вам следует использовать протокол svn вместо file ?

Answer 1

Если вы работаете самостоятельно на одной машине, то по моему опыту использование протокола file: // работает нормально. Даже когда моя команда использовала Subversion с удаленного сервера, я настраивал локальный файловый репозиторий для своих личных проектов. Если вы дойдете до точки, где вам нужно получить доступ к нему с другого компьютера, то я бы столкнулся с проблемой настройки хранилища на основе сервера. Вы также можете взглянуть на распределенную систему, такую ​​как Mercurial - мы оценивали ее в моей последней компании незадолго до того, как я ушел, - но определенно выбираем одну или другую, смешивание svn и hg не работает вообще.

Answer 2

Вы всегда можете добавить сервер Subversion позже, если он указывает на ваш файл: // хранилище, и вы сразу получите svn: // доступ.

Протокол не имеет значения, он просто позволяет передавать данные по различным видам среды, важен только контент репозитория.

А установить SVNSERVE позже довольно просто.

Тем не менее, вид используемого вами программного обеспечения Subversion имеет значение, хотя, например, один поставщик делает это так, что метаданные хранятся в «_svn» вместо «.svn», и вы можете сначала проверить совместимость.

Answer 3

Я считаю, что до тех пор, пока включено использование соответствующих инструментов SVN, у вас не должно быть проблем - как говорили другие, вы всегда можете настроить сервер позже.

Мой совет: убедитесь, что вы можете использовать ToroiseSVN и клиент Subversion Collabnet.

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

Answer 4

Здесь есть некоторые упоминания о файловых и серверных репозиториях. Пожалуйста, исправьте меня, если я ошибаюсь, но я понимаю, что Subversion - это репозиторий системных файлов или репозиторий Berkley DB. Различие между файлом и сервером на самом деле заключается в том, как осуществляется доступ к хранилищу. Т.е. к одному и тому же хранилищу можно обращаться (извлекать, фиксировать и т. Д.) Либо непосредственно в файловой системе с протоколом file: ///, либо через прокси-сервер с ssh, сервер svn и / или Apache с http.

Answer 5

Не то, что я знаю. Всегда стоит использовать контроль исходного кода, поэтому даже если file: // в некотором роде уступает, если это означает, что вы на самом деле используете subversion, а не устали от установки и просто начинаете кодировать, тогда его Хорошо по моей книге.

Answer 6

Некоторое время назад в проекте мы использовали ant для сборки. Ant извлекает последний код из репозитория SVN, выполняет сборку, а затем создает в репозитории SVN тег кода, на котором основывается сборка. Мы обнаружили, что автоматизация Ant не может работать по любому протоколу, кроме протокола svn: //.

Итак, если вы хотите использовать Ant для автоматизации любого взаимодействия с SVN, вам необходимо использовать протокол svn: //.

Answer 7

file:// схема доступа работает нормально, когда вы единственный, кто в данный момент обращается к хранилищу. Более того, не должно быть проблем с размещением репозитория на сервере и предоставлением репозиториев через https:// или svn://, если вам необходимо сотрудничать с другими.

Однако, file:// URL-адреса ужасны в Windows, и использование HTTP (S) -сервера помогает вам использовать красивые. Типичный локальный URL в Windows выглядит как file:///C:\Repositories\MyRepo. Однако я предпочитаю https://svn.example.com/MyRepo.

Answer 8

Существует три причины для выбора протокола на основе сервера вместо протокола file.

• Снижение сетевого трафика.

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

• Вы можете выставить серверный протокол через Интернет

В связи с этим возникает вопрос, использовать ли протокол svn или http. Оба могут быть использованы по сети. Svn имеет преимущество в эффективности использования прямого двоичного кода вместо кодирования base64. Http легче проносить через корпоративные брандмауэры перед лицом бюрократической преграды.

• Меньше хлопот с разрешениями в междоменных сценариях, таких как удаленный доступ.

Скорее всего, ваша домашняя рабочая станция не является частью корпоративного домена. Демон сервера Subversion функционирует как прокси. Он выполняется в аутентифицированном процессе, который имеет необходимые разрешения для выполнения операций ввода-вывода от вашего имени.

Answer 9

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

Answer 10

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