問題タブ [dvcs]

私のチームと私は、私たちのプロジェクト (API を備えた開発プラットフォーム) を wiki で文書化することは、私たちにとってもユーザーにとっても有益であることを発見しました。いくつかの組織上の問題により、ネットワーク接続なしでマルチサイト開発を行うことを余儀なくされています。私たちは DVCS (Mercurial) に切り替え、これで大きな成功を収めました。中央サイトが MediaWiki でセットアップされているため、wiki のドキュメントが問題であることが判明しました。オフサイトの人々は、wiki にアクセスしたり編集したりすることはできません。

サーバー/データベースを必要とせず、DVCS 環境で使用できる wiki スタイルのパッケージはありますか?

更新: オープンソースでクロスプラットフォームであるべき

より従来型の VCS (CVS/SVN) のバックグラウンドを持っている人にとって、git を学んで移行する最も説得力のある理由は何ですか?

git を機能させるために必要なチームの技術的能力についてコメントしてください。私は賢い人が学習曲線を上っていくのを見てきました。誰でもこの曲線を上ることができますか? git はすべてのチームに適しているわけではありませんか?

もちろん、機能上の利点、ツールのサポート、他のシステム (CI など) の統合についても聞きたいです...

(これは明らかな質問のように思えますが、いくつかの検索にもかかわらず、これの重複は見つかりませんでした)

編集優れたリソースへのリンクも高く評価されています。

問題文

これまでは、コードベース全体に誰もがアクセスできました。ここで、人々が作業するモジュールのコードのみを取得するように強制する必要があります。他のモジュールについては、lib のようにライブラリを取得します。現在2つのモジュールがあると仮定します

thinkbot (ヘッド)

-> assemblebot (ツリー/サブディレクトリ)

-> vpl (ツリー/サブディレクトリ)

-> 含める

-> ソース -> ビン`

誰かが vpl モジュールで作業している場合、コードを含むインクルードとソース フォルダーを取得し、assemblybot モジュールから lib を取得します。したがって、彼が変更を加えて HEAD からコンパイルすると、彼からうまくいくでしょう。

皆さん、これを Git に実装するにはどうすればよいですか? 何を読むべきかについての指針 コマンド スニペットは素晴らしいでしょうか?

StarTeam では、ビュー間でファイルを共有できます。基本的に、StarTeam のビューは、他のビューからの個々のファイルを共有できます。その後、ファイルを分岐することもできます。何百ものファイルを共有する StarTeam のビューを移行する方法はありますか? 誰でもこれを経験したことがありますか？唯一の解決策が 1 つの StarTeam の「ビュー」を 1 つのリポジトリ (GIT など) に変換することであると仮定すると、GIT などで複数のリポジトリ間でファイルを共有できるようにする戦略はありますか?

ショーン

Subversion、Git、Mercurial などは、スリーウェイ マージ (私のもの、彼らのもの、および「ベース」リビジョンの組み合わせ) をサポートし、競合を解決するためのグラフィカル ツールをサポートします。

どのツールを使用しますか? Windows、Mac OS X、Linux、無料でも商用でも、何でも構いません。

会話を始めるためだけに、私が使用したり聞いたりしたいくつかを次に示します。

• KDiff3
• 差分マージ
• P4Merge
• メルド
• 比較プロを超えて。

(これがBest Diff Toolに似ていることは認識していますが、明確に 3 方向マージ ツールに焦点を当てているという点で異なります。たとえば、WinMergeはリストから外れています。)

小規模なオープンソース プロジェクト用の無料の Mercurial ホスティングを探しています。
そのようなサービスを使用したことがある場合、ホスティングを行っているのは誰ですか? また、そのサービスをお勧めしますか?

SF.net がHG リポジトリをホストするようにセットアップできることは知っていますが、それは多くの問題のように見えます (大規模な既知のサービスがあり、すぐにダウンする可能性は低いため)。

Mercurial の公式ドキュメントには無料の HG ホストのリストもありますが、実際に使いこなした人たちの意見を聞きたいです :-)

Gitを使用して維持されていたプロジェクトを継承しました。ある時点で、コードは3つの別々のシステムにデプロイされ、各システムは独自の分散型Gitリポジトリを維持していました。

3つのシステムはそれぞれ、元の基本システムを3つの異なる方向に拡張しました。3つのシステムのいずれも互いに同期されていません。一部の変更はマスターブランチにあり、その他は新しいブランチにあります。

3つの異なるソースをまとめて、次のことができるようにするにはどうすればよいですか。

1. 使用する共通ベースを見つけます。
2. 3つのシステムすべてに適用する必要があるバグ修正がどの変更であるかを調べます。と
3. 共通のブランチが1つだけになるように、3つのシステムを適切な方法で維持し、3つの異なるシステムに必要なカスタマイズを分離しますか？

私は数か月間 git を使用してきましたが、私の日常業務をより良いものに変えたほとんどの要因は、分散型 VCS の柔軟性と強制されたデフォルト ポリシーの欠如に起因する可能性があることがわかりました。

かなりの数の人々が同じように感じ、この種の柔軟性を築いてきたようです

• 異なるマシン間でホーム ディレクトリを同期しているユーザーからのかなりの数のレポートを読みました。
• IkiWikiはソース管理に基づいて構築されており、分散 Wiki として使用できます。
• git に基づいて構築された分散バグ/問題追跡システムがいくつか存在します (他の DVCS については不明)。

お気に入りの DVCS を使用して実装したクールなアイデアは何ですか?

オープン ソース プロジェクトでの git や mercurial などの分散型バージョン管理システム (DVCS) に関する私の経験から、ほとんどのセットアップ モデルはプロジェクトに集中型セットアップを使用します (GitHub を考えてください)。

企業に分散型 VCS を導入する場合、集中型セットアップ モデルはありますか?