FTP経由でSVNを同期する

Question

私のチームは、かなり厳格なITポリシーを持つ他の会社のグループと協力しています。私たちはSVNサーバーに直接アクセスすることはできません。彼らは私たちのSVNサーバーにアクセスすることは許可されていません。私たちが与えた唯一の選択肢は、共有FTPサーバーへのアクセスです。だから私は、リポジトリを同期させておくための提案を探しています。このFTPサーバーは電子メール以外の通信メカニズムしかないので、svn：externalsはオプションではありません。

私の現在の考えは、夜間（または必要に応じて頻繁に）diff/patchが双方向であると考えています。価値のあることについては、私たちはそれぞれかなり独立したコンポーネントを扱っているので、衝突の可能性はかなり低いです。

もっと良いアイデアですか？

編集：私はこれで少し「人と戦わなければならない」ことを認識していますが、それは数週間であり、FTP（おそらくSFTP）はまだ実施されていません。したがって、私は賢明なソリューションを探しています。私たちの業界の性質と私たちが取り組んでいるシステムは、コードのサードパーティストレージを排除します。はい、これは愚かで官僚的です。道順：

Answer 1

git-svnを両側で使用し、FTP接続を使用してGitリポジトリを同期/交換することができます。

Answer 2

FTPサーバーが許可されていて、HTTPまたはSSHアクセスが許可されていないのはなぜですか？

セキュリティが心配な人は、普通のFTPは確かにそれを提供しておらず、SFTPにはSSHが必要なので、SSH/SCPを使ってリポジトリと同期することができます（これはSVNよりもGit、バージョン管理タスクが行います）。

SVNはHTTP経由で利用することができます。夜間のチェックアウトを実行して、誰でもアクセスできるHTTPサーバに投げ込んでパッチを取得し、一般的なSVNリポジトリに統合するのはどうですかあなたが入手したパッチが好きですか？

そして、死んだ馬を打ち負かすのではなく、Gitはそれを切り換えるために必要な投資以上の価値があります。切り替えを検討してください。

基本的に、この設定は非官能的なものであり、実装した思慮深い官僚に立ち向かい、実行可能な解決策を見つける必要があります。あなたのグループが主要なソース管理システムとして使用する第一レベルのリポジトリではありません。

Answer 3

私はいくつかのプッシュバックをお勧めします。厳しいITポリシーに関する良いことは、通常、これはポリシーを更新するための確立されたプロセスがあることを意味します。プロセスを決定することは、特にあなたが「電話をしている」場合（つまり、他の人に直接話すことができない場合）には難しいことです。

疑いの余地を超えてソースコントロールがベストプラクティスです。共通のソース管理リポジトリへのアクセスを許可しないポリシーは、ベストプラクティスではありません。ソース管理のみを提供する中立的な第三者が最適な解決策（「svnホスティング」のヒット数が多い）かもしれません。あなたはおそらく、Apacheを介してポート80（または443）でsvnホスティングを手配することもできます。したがって、ファイアウォールの調整は必要ありません。

共有元リポジトリを持たないというオーバーヘッドのために、タスクごとにX分を追加することをPMに提案します（週単位の「ソースリポジトリタスクの修正」を2時間ほど追加することもできます）。私は確かにプロセスに関わる努力を追跡するために時間と労力を費やすことを検討しています（プロセスが1週間に1時間しか食べていないのにそれはまだ追跡するのに重要な時間です）。

他にも...あなたはこのスキームを使用して継続的な統合サーバーを稼働させますか？たぶん私は悲観的ですが、私はマージ問題のためにたくさんの壊れたビルドを期待しています...そして、それは反対のパーティーフォルトのように見えるたびにかなりです。このスキームがCI（もう一つのベストプラクティス）を排除しているのだろうか？

Answer 4

あなたがFTPに制限されている場合、私はあなたの現在の考えを2番目にします。 FTPは「ライブ」転送プロトコルではありません。転送されたファイルに関係なく、ドロップフォルダの変更に気付くには、両端にウォッチャーが必要です。

お支払いのクライアントが少しの創造性を必要とする約束の条件を設定している場合は、そうしてください。エラーが発生した場合はsvn diff、パッチ、一部のcronスクリプト、多くの電子メール通知を使用してください。

過去に政府および大企業の団体と協力したことがある人は、あなたの立場に共感します。実際には、「ドロップボックス・パターン」を使用するフォーチュン100社の多くは正当な理由があります。ターゲットを絞ったサイトや大量のサイトに有効な攻撃に対して間接的なレベルのインダイレクションを作成します。迷惑な、はい、しかし、あなたが靴の中で1マイル歩くまで、それは本当に戻っていく価値がありますか？結局のところ、反対側の開発者はおそらくあなたのように制限について不快であるかもしれませんが、誰もがそれらを克服し、できる限り作業コードを提供したいと考えています。

「将来のプロジェクト...適切な時期に」の代替技術について推奨しますが、現在のプロジェクトヘッドの制限と要件を満たしています。クライアントとの信頼関係を確立したら、採用される推奨事項を簡単に作成できます。

今のところ、最高の、最も堅牢なFTPベースのSVNマージスクリプトを書くことができます...楽しいでしょう！

編集：あなたは一人ではないようです。私はこのプロジェクトを一度も使ったことがないので、私は信用できませんが、少なくともあなたの問題はsvn2webであることが分かりました。 "sftpまたはftpを使用して、コミットされたファイルを同じサーバーまたは別のサーバーにコピーするために使用できるSubversionのコミット前または後のフック。

Answer 5

あなたのブランチを作成してそのブランチにアクセスすることができないのは奇妙なようです。そうすれば、問題があれば、ブランチをマージする必要はありません。

Answer 6

私は同様の状況でしたが、FTPやSFTP以外の方法でリモートリポジトリを読み書きすることができるため、サブバージョンの代わりにbazaarを使用しました（もう一方のクライアントプログラムは必要ありません）。

OSは言及していませんが、Windowsを使用している場合、TortoiseSVNを既に使用している場合は、TortoiseBzrが付属しています。