как сотрудничать исходный код в нескольких местах - PullRequest
6 голосов
/ 21 июля 2010

У нас есть образ VMWare с экземпляром gforge в нашей локальной сети. Мы хотели бы, чтобы некоторые внешние люди были частью процесса разработки. Мы хотели бы сохранить этот репозиторий в качестве основного репозитория SVN. Какие варианты доступны для обмена кодом с внешними ресурсами и слияния его с нашим локальным хранилищем.

Другие варианты могут заключаться в размещении этого полностью за пределами нашей сети (на некоторых хостинг-провайдерах), это недопустимо, поскольку позволяет сотрудникам получать доступ к коду вне нашей сети.

Ищу предложения для решения этой проблемы.

Ответы [ 5 ]

6 голосов
/ 21 июля 2010

SVN не является распределенной VCS.Если вы хотите придерживаться SVN, у вас не будет реальной альтернативы, кроме как предоставить им доступ к вашему локальному серверу каким-либо образом.

Если вы хотите, чтобы они имели возможность фиксировать в отдельном внешнем репо, который физически не подключен к вашему внутреннему серверу, и вручную объединять их изменения в центральном репозитории, вам нужно посмотреть на распределенныйVCS как Git или Mercurial .

2 голосов
/ 21 июля 2010

Subversion - это централизованная (по сравнению с распределенной) система контроля версий.Он предназначен для совместной работы, выполняя параллельные операции с одним-единственным хранилищем.Таким образом, у вас в основном есть два варианта:

  1. Придерживайтесь централизованного управления версиями и разрешайте внешний доступ к хранилищу (большинство маршрутизаторов и брандмауэров позволяют перенаправлять определенные порты, поэтому это не должно быть большой проблемой).
  2. Переключение на управление распределенной версией (Git, Mercurial, Bazaar ...).

Все остальное будет сложным обходным путем.

1 голос
/ 21 июля 2010

важное соображение для вас должно быть:

, если вы смотрите на разработчиков, работающих и фиксирующих изменения, которые они регулярно вносят в свой код - тогда SVN хорош.

если вы 'мы ищем разработчиков, которые будут работать над большими блоками самостоятельно и хотят объединить свою кодовую базу, как только они будут уверены в целостности материала, над которым они работали - иди с Git или Mercurial.

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

1 голос
/ 21 июля 2010
  • Вы можете настроить VPN и позволить им передайте непосредственно мастеру.
  • Вы можете переключиться, чтобы сделать распределенный VCS, как Git.
  • Вы могли бы настроить другой SVN для них и объединить их. Я думаю что связаны с сильной головной болью.
0 голосов
/ 20 июля 2011

Отдельный распределенный репозиторий VCS (Git, Mercurial, Bazaar) может иметь зацепки для фиксации, которые отправляют патчи привратнику (человеку с доступом к svn) для включения распределенных вкладов разработчиков.распределенная VCS также может обновлять / извлекать / объединять из репозитория svn, обеспечивая синхронизацию распределенной VCS с svn.

Этот подход будет поддерживать ваш сервер SVN и рабочий процесс и процесс резервного копирования, который работает для вас сейчас.Только новые разработчики должны изучать новую VCS (Bazaar, Git и т. Д.).

Я должен сделать это сейчас в проекте и обновлю детали.

...