Синхронизировать SVN через FTP

Question

Моя команда работает с группой в другой компании с довольно строгими ИТ-политиками. Нам не разрешен прямой доступ к их серверу SVN. Им не разрешен доступ к нашему серверу SVN. Единственный доступный нам вариант - доступ к общему FTP-серверу. Итак, я ищу предложения для синхронизации наших репозиториев. Обратите внимание, что этот FTP-сервер является только механизмом связи, отличным от электронной почты, поэтому svn: externals не вариант.

Моя текущая мысль - это ночные (или так часто, как это необходимо) diff / patch, идущие в обоих направлениях. Что бы это ни стоило, каждый из нас работает с довольно независимыми компонентами, поэтому вероятность конфликтов довольно мала.

Есть идеи получше?

Редактировать: Я понимаю, что должен немного "сразиться с этим человеком", но прошло уже несколько недель, а FTP (предположительно SFTP) еще даже не на месте. Поэтому я ищу умные решения. Характер нашей отрасли и системы, над которой мы работаем, исключает возможность хранения кода сторонними разработчиками. Да, это глупо и бюрократично. Как это идет:)

Answer 1

Вы можете использовать git-svn с обеих сторон и синхронизировать / обмениваться репозиториями Git , используя FTP-соединение.

Answer 2

Почему вам разрешен FTP-сервер и нет доступа по HTTP или SSH?

Если вы беспокоитесь о безопасности, обычный FTP, безусловно, не предоставляет его, а SFTP в любом случае требует SSH, поэтому вы можете использовать SSH / SCP для синхронизации с репозиториями (это работает намного лучше с Git, чем с SVN, так как большинство версий контрольные задания делаю).

SVN можно использовать по HTTP без особой суеты - почему бы просто не запустить ночную проверку и не выбросить ее на HTTP-сервер, к которому все могут получить доступ, взять свои патчи там и слиться только с общим рабочим репозиторием SVN, когда вы как патчи, которые вы получаете?

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

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

Answer 3

Я был в подобной ситуации, и мы в итоге использовали базар вместо subversion, потому что он поддерживал возможность чтения / записи удаленных репозиториев, используя только FTP или SFTP (не требуется клиентская программа на другой конец).

Вы не упомянули свою ОС, но если вы используете Windows, базар поставляется с TortoiseBzr, который будет вам знаком, если вы уже используете TortoiseSVN.

Answer 4

Если вы ограничены FTP, я подумаю над вашей текущей мыслью. FTP не является «живым» протоколом передачи; вам понадобится наблюдатель на обоих концах, чтобы заметить изменение в папке удаления независимо от переданных файлов.

Если ваш платящий клиент установил условия взаимодействия, которые требуют немного творческого подхода, пусть будет так. Используйте svn diff, патч, некоторые скрипты cron и множество уведомлений по электронной почте в случае ошибки.

Любой, кто работал с правительством и крупными корпоративными структурами в прошлом, будет сочувствовать вашей позиции. На самом деле, есть много компаний из списка Fortune 100, которые по понятным причинам используют «шаблон с выпадающим списком». Это создает уровень перенаправления на атаку, который полезен для сайтов с высокой степенью таргетинга или больших объемов. Раздражает, да, но до тех пор, пока вы не пройдете милю в их туфлях, разве это не стоит отталкивать? В конце концов, разработчики на другом конце, вероятно, так же недовольны ограничениями, как и вы, но каждый хочет их преодолеть и предоставить рабочий код как можно лучше.

Дайте рекомендации по альтернативным технологиям для "будущих проектов ... на соответствующем этапе", но соблюдайте ограничения и требования текущего проекта. После того, как вы установили доверие со своим клиентом, вам легче будет давать рекомендации, которые будут приняты.

На данный момент, напишите лучший и самый надежный скрипт слияния SVN на основе FTP, который вы можете ... это будет весело!

РЕДАКТИРОВАТЬ: Кажется, вы не одиноки. Я никогда не использовал этот проект, поэтому я не могу его назвать, но в описании, по крайней мере, признается ваша проблема: svn2web . «Хук Subversion до или после фиксации, который можно использовать для копирования зафиксированных файлов либо на тот же, либо на другой сервер, через sftp или ftp.»

Answer 5

Я бы предложил немного отодвинуться. Преимущество строгих ИТ-политик заключается в том, что обычно это означает, что существует установленный процесс обновления политик. Определить процесс может быть непросто, особенно если вы также «играете по телефону» (т. Е. Вы не можете напрямую общаться с другими людьми).

Вне всякого сомнения, контроль источников является наилучшей практикой. Политика запрещения доступа к общему репозиторию контроля версий не является наилучшей практикой. Лучшим решением может быть нейтральная третья сторона, которая обеспечивает только контроль исходного кода (множество обращений к "svn hosting"). Вы могли бы даже организовать хостинг SVN на порту 80 (или 443) через Apache ... так что никаких настроек брандмауэра не потребуется.

Я бы также предложил премьер-министру добавить X минут на задачу из-за непроизводительных издержек, связанных с отсутствием общих репозиториев с исходным кодом (возможно, даже добавить еженедельное «исправление задачи с исходным репозиторием» на пару часов). Я бы, конечно, подумал о том, чтобы потратить некоторое время и усилия на отслеживание усилий, связанных с процессом (если процесс занимает всего 1 час в неделю, это все еще важный период времени для отслеживания).

Также ... просто любопытно ... вы будете работать с сервером непрерывной интеграции по этой схеме? Может быть, я настроен пессимистично, но я бы ожидал много неработающих сборок из-за проблем слияния ... и почти каждый раз это будет выглядеть как вина стороны противника. Интересно, исключает ли эта схема КИ (еще одна лучшая практика)?

Answer 6

Кажется странным, что они не смогли бы создать ветку для вас и дать вам доступ к этому. Таким образом, если есть какие-либо проблемы, им просто не нужно объединять вашу ветку.