0

したがって、svn と git は非常に強力で用途の広いツールではないと私が言うのを聞くことはありませんが、ローカル以外の開発 (中央のネットワーク共有) ではうまく機能しません (実際には 2 人が同じファイルで作業できます)。 ) かなりの量のオーバーヘッドが発生するため、具体的には、中央ネットワーク共有でうまく機能する代替手段があるかどうか疑問に思っていました (主に使用される機能は、非難と安定したコードと開発コードの識別です)。

これはかなり幅広い質問であることは承知しており、これが Stackoverflow の範囲内に収まることを願っていますが、同様の質問がクローズされなかったため、この質問を試してみることにしました。

リアクションにはよくある誤解があるようです: 現在、私たちは Subversion を使用して変更をコミットしており、タグを使用してバージョンを区別し、タグ付けされた変更のみを本番環境にプッシュしています。さらに、ローカル コピーは何らかの形で共同開発の聖杯であると信じられているようです。同じプロジェクトで常に最大 4 人の開発者と作業する場合、すべてのコードと単一の文法のコンパイルを必要とする古代の低レベル言語を使用していなければ、同じファイルで作業するのが理想的です。間違いはアプリケーション全体を壊します。確かに、これによって不要なエラーが発生することもありますが、一般的には非常にうまく機能し、開発のスピードアップに役立ちます。実際の主な問題は、異なる人が同じ svn チェックアウトにコミットして作業すると、svn が大きく壊れる傾向があるという事実にあります。さらに、問題を引き起こしがちなことが他にもいくつかあります (そして、答えの 1 つがそれを「修正」するのに役立つかもしれませんが、svn はどちらにしても共有に座っているのが好きではないようです)、しかし実際には、それらすべてが原因であるということですSVN と GIT はすべて、個々の開発者が独自のローカル コピーで作業するという考えに基づいているため、私たちが行っている共有コード ベースでの緊密な開発スタイルにはうまく適合しません。

これについて話し合った後、この開発スタイルにより適した、より単純で高度でないソース管理システムを想像できるという結論に達しました (たとえば、エクスペリエンスのような完全に自動化されたリビジョン追跡システム)。ユーザーは Google ドライブのドキュメント + さらに何らかの形式の「タグ付け」ファイルを持っています)、他の人もこれについて考えたにちがいないと想定し、それがこの質問の出所です。また、当社の開発スタイルが悪いと思われる場合は、当社が現在、競合する同様の大規模な Web アプリケーション開発会社の約 3 倍から 5 倍の効率を達成できていることを指摘させてください (そして、成長しないという選択は意識的なものです) そして、はい、このセットアップは、その効率を達成するのに役立つ理由の 1 つです。オーバーヘッドの。以下のコメントの 1 つで言ったように、ローカル開発環境をセットアップするには、約 50x4=200 の異なる開発アプリケーションを実行するようにセットアップする必要があることを意味します。これは、各開発システムで 3 つの異なる IIS インスタンス (使用している「アドオン」の制限と、この「アドオン」の 3 つの異なるバージョンが必要なため)、1 つの apache/tomcat インスタンスと 1 つの apache/jetty インスタンスを意味します。 . さらに、開発者ごとにこれらの 5 つのインスタンスを 50 個のアプリケーションの異なるサブセットに分離しました。(そして、これら 5 つのインスタンスを相互に並行して実行する方法や、クロス アプリケーション リクエストをどうするかについても考えたくありません) すべてを、各アプリケーションの 3 つの異なるインスタンス (開発、ステージング、および生産）それ' 単純に正当化できません。また、社内でこれらのインスタンスのセットアップ方法を知っているのは 2 人か 3 人程度であることは言及しませんでした...これは混乱です (新しいプロジェクトについては、この混乱からすでに移行しましたが、古いすべてのプロジェクトについては、まだサポートされているプロジェクトは関係ありません)。

この質問を私たちだけに当てはまらないように、できるだけ一般的な質問にしようとしましたが、一部の人々が回答やコメントで与えている反応は、信じられないほど傲慢です. 正直なところ、私たちはこれについて考え、かなり具体的な質問をしました. また、質問が svn/git の代替手段を求めるものである場合、「svn を使用する」/「git を使用する」または「その質問で泣きそうになった」などの回答をするのは非常におこがましいです。そして、他の一部とは異なり、@ David W.の原因はありません。あなたが正直に助けようとしたことは認識していますが、それらのコメントを見て、スタックオーバーフローをやめることを真剣に考えました。</rant>

いずれにせよ、誰かがソース管理への根本的に異なるアプローチを教えてくれることを願っていますが、見た目からするとそうではありません。いつか自分で書くことになるかもしれませんが、今はその時間がないので、他の誰かがすでに書いていることを願っていました.

4

4 に答える 4

1

変更を規制するサーバーがない場合、2 人のユーザーが同じファイルを同時に変更するのを防ぐためにできることはあまりありません。file://複数の人がプロジェクトに取り組んでいる場合、Subversionでプロトコルを使用すべきではないのはそのためです。ネット共有では絶対に使用しないでください。

Subversion の場合、svnserveプロセスを使用して、共有を含むシステム上に軽量サーバーを作成できます。それは簡単で速いです。Windows サービスとしてセットアップすることも可能です。完了すると、svn://プロトコルを使用できるようになり、svnserveプロセスによって変更が規制されます。

この場合、Git は本当に役立つかもしれません。Git では通常、変更をプッシュおよびプルするマスター リポジトリがありますが、実際には Subversion と同じように Git を使用しているため、Git の全機能を利用することはできません。

Git では複数のリポジトリを使用でき、それぞれが変更を相互にプルおよびプッシュします。実際、マスター Git リポジトリはまったく必要ありません。これが、Git がセットアップを処理するための最良の方法である理由です。

あなたと同僚は全員、独自のプライベート Git リポジトリを持つことができます。チェックインとチェックアウトは自分で行います。電子メールを介して相互に同期します。サーバーはありません。Windows 共有なし。2 人が同時に同じファイルを変更しようとしても問題ありません。

私はDropboxを使用して Git リポジトリを保存しているので、自宅でも職場でもリポジトリを利用できます。

Word 'o Warning : このように Dropbox を使用する場合、一度に 2 人のユーザーがこの Dropbox Git リポジトリにプッシュすることはできません。複数の人にプルをさせることはできますが、プッシュはできません。

ただし、この Dropbox Git リポジトリは私と他のユーザーの間で共有されていません。それは私のものであり、私だけのものです。職場のコンピューターで使用し、家に帰ってから、自宅で仕事を続けています。上記で説明したように、電子メールを使用してプロジェクト内の他のユーザーとそのリポジトリを同期します。

于 2013-04-17T14:43:18.980 に答える
1

他の回答では、一般に、複数の人が 1 つのサーバーで同時に作業すると問題が発生する可能性があることが既に指摘されています。私は同意します - しかし、あなたはこれがあなたのために働くと書いているので、私はそれについて議論しません.

そうは言っても、バージョン管理の私の解決策は次のとおりです。

  • プロジェクトごとに 1 つのリポジトリを持ち、3 つのブランチ (dev、staging、prod) を持ちます。
  • 各サーバーでは、サーバーの役割 (dev/staging/prod) に対応するブランチが常にチェックアウトされます。

そうすれば、複数の人が 1 つのサーバーで作業できます。彼らは、たまたま同じシステムで作業している同僚と調整して、いつものようにコミットするだけです。作業コピーの変更のサブセットのみをコミットするのが簡単になるため、これは Git では少し簡単ですが、SVN でも同様に機能します。

コードはマージによってシステム間で交換されます。新しい機能が「dev」で行われる場合、「dev」コードは「staging」にマージされ、「staging」は「prod」にマージされます。タグは、次のステージへのマージに適したバージョンを識別するために使用できます。そのため、最新の「dev」を「ステージング」にマージするだけでなく、ブランチの古いリビジョンを指す「featureX-dev」タグを使用します。開発」。

Git を使用している場合、作業を中断して進行中の作業が必要な場合は、ローカル ブランチが役立ちます。次に、進行中の作業をローカルのスクラッチ ブランチにコミットし、作業コピー (およびメイン ブランチ) をクリーンなままにして、他の人が同じサーバーで作業できるようにします。もちろん、これには一時的にスクラッチ ブランチをチェックアウトする必要があるため、同じシステムで作業している他の人と調整する必要があります。

于 2013-04-21T08:44:54.857 に答える
0

いつでも同じプロジェクトで最大 4 人の開発者と作業する場合は、同じファイルで作業するのが理想的です。

嘘。単一の共通 (マップされたネットワーク ドライブとして非常に一般的) コード ベースの周りに 2 人の開発者がいる場合でも、同じファイルを同時に変更したり、外部の変更を上書きしたりしないことを保証することはできません (古い「ロック アンド ウェイト」モデルを使用する場合を除く)。 ）、したがって - 頭痛がひどい

実際の主な問題は、異なる人が同じ svn チェックアウトにコミットして作業すると、svn が大きく壊れる傾向があるという事実にあります。

実際の主な問題はSubversionではありません (Right Way (tm) で使用した場合、何も壊れません) - 訓練を受けていないユーザーが顕微鏡を使って釘付けをすることです。

ローカル開発環境をセットアップするには、約 50x4=200 の異なる開発アプリケーションを実行するようにセットアップする必要があることを意味します。

LDE をビルドせずに、ワークフローを Subversion を適切に使用するように変更することができます。ローカル ワークプレースの層(開発者が個人の WC でコードを編集する場所) と、サーバー開発環境を更新するためのポストコミット フックをサーバーに追加するだけです (そして、おそらく、コミット前に update+merge する場合はブランチの使用を開始します / 古い WC/ は開発者を悩ませます)。

この開発スタイルにより適した、よりシンプルで高度でないソース管理システムを想像することができます

まあ、それは WebDAV です - これに加えて何もない線形バージョン管理です。エンドユーザーの場合、同じ共有ドライブになります

于 2013-04-17T23:30:23.597 に答える
0

中央のネットワーク共有でうまく機能する代替手段があるかどうか疑問に思っていました

残念ながら、本当の代替案は「怠惰なワークフローと習慣を変える」ことです-互換性のないものを（今）組み合わせたい

「50 ～ 100 の異なるプロジェクト」とは、50 ～ 100 個のリポジトリ (中央の場所にある) と、50 ～ 100 個の開発ボックス上の作業コピー (これを作成するための作業が必要ですが、1 回限りの操作です) と 1 つ(2 つDVCS の場合 - プッシュが追加されました)開発プロセス後の開発者向けの追加アクション - コミット。

適切に定義された管理可能な開発プロセスと公正な価格により、「管理されていないアナーキー」を置き換えるための最小限のオーバーヘッドです。

于 2013-04-17T19:52:04.987 に答える