お気に入りのバージョン管理システムは何ですか？[閉まっている]

これは、組織のニーズによって明らかに異なるため、「最良」を決定するための実際の試みというよりも議論の問題です。私は、カテゴリー（集中型vs分散型、オープンvsプロプライエタリなど）の異なるシステムを支持する議論についてもっと興味があります。

だから、最高のバージョン管理システムは何だと思いますか？

マーキュリアル

コードを分岐およびマージする高度な機能があるため、私が使用した中で最高です。DVCSパラダイム全体が非常に理にかなっています。私はGitを使用していませんが、Gitも同様に適格だと思います。

ギット

Gitは素晴らしく、特にオープンソースプロジェクトで作業している人にはお勧めです。特にGitHubでホストされている場合は、Eitを処理するよりも、Gitのプロジェクトに1回限りの小さな変更を加える方がはるかに簡単です。 SVNに関するパッチをメールで送信します。

Windowsユーザーに対する1つの大きな注意点：GitのWindowsツールは、間違いなく使用可能ですが、まったく新しいものではありません。しばらくWindowsを使用することを余儀なくされたとき、Hit-Git統合ツールを使用してMercurialのWindowsインターフェイスを試し、Gitリポジトリを使用できるようにしました。使いやすいことがわかりました。

警告：この投稿以来、私はMercurialを見つけ、SVNよりもずっと気に入っています。したがって、この投稿はPro SVNのコメントと一般的なアンチDVCSでは少し古くなっていますが、アンチgitのものはまだ関連しています

私はGitを介したSVNのファンです。

どうして？SVNは、単一の開発者または小規模なチームにとってはるかに簡単だったため、git（特にmsysgit）のおかげで口に悪い味が残りました。

小さな店でインターンをしていたときに、Windowsでgitを紹介されました。Githubで動作させるために必要な作業量にすぐに気付きました。最初に、ssh秘密キーを生成し、Githubに公開キーを貼り付け、次にプッシュするたびにページェントを表示して秘密キーを開く必要がありましたが、これは非常に面倒でした。

そして、私はリポジトリ全体をプルダウンしていることを本当に好きではありませんでした。巨大なもので作業したことがないことは認めますが、リポジトリ全体とそのリビジョンがHD上にある場合、GitでKDEのリポジトリをダウンロードすることを恐れます。

それから、コミットするための混乱するプロセスがありました。TMK、私は最初にコミットしたいすべてのファイルを「ステージング」しなければなりませんでした（多くのファイルがあり、すべてをステージングするための手動コマンドを見つけるのに時間がかかりました）、その後コミットしてからメインにプッシュしますレポ（なぜ別の操作ですか？！）。

また、非常に役立つコミットデータではありません（！）。ああ、これはツリー2167a4934d0a4a7db0deの14f74433245ae17aeeaa部分と親d7042abb4821d3faf600のコミットです。地獄はどういう意味ですか？物事をかなり迅速に把握でき、奇妙なドキュメントを参照する必要はありません。

ドキュメンテーションといえば、少なくとも私がそれを使用していたときは、すべてがLinuxのmanファイル形式であり、IEを混乱させ、役に立たないように思われました。ドキュメントでヘルプを見つけることはめったになく、単にグーグルに頼りました。

そして、コミットに関して、私が気に入らなかった一つのことは、バージョン番号の欠如でした。これはgitの設計が原因であることがわかりましたが、どのソフトウェアにもバージョン番号が必要です。「バージョンを1.8.6に変更しました」などのようにポップアップするマーカーコミットをまだ覚えていますが、ビルド番号を作成できませんでした。バージョンを1.8.6.5164（最後の部分はリビジョン番号）にすると、1.8.6だけでなく、マイナーな変更があったことを示すメモが表示されます。

ソフトウェア固有のWindowsの基本プログラムはmsysgitであり、これはひどいインターフェイスです。それは数回私に閉じ込められ、恐ろしいインターフェースを持っていて、CLI-GUI統合はせいぜい不確かでした。私の周りのコマンドラインジャンキーは、GUIをさらに嫌っていました。

次に、SVNを見てみましょう。そして、私はWindowsを使用していて、Googleアカウント、特にTortoiseSVNとGoogle Codeを持っています。

まず、リポジトリ上のすべてを実行するための完全なシェル統合（そして、Linuxユーザーにとっては、RabbitVCSも同じことを行います）。メインのGUIは必要ありません。レポジトリの取得はチェックアウトとして簡単で、SSHは不要です（GithubがプルにSSHを必要としているかどうか覚えていません）。また、リポジトリ全体と過去のすべてのコミットがHD上にありません。

主にSSHやステージングが不要なため、コミットは非常に簡単です。私のmsysgitバージョンでは利用できなかった非常に便利な全選択オプションを使用して、必要なすべてのファイルをチェックし、コミットメッセージを入力して、コミットを押します。その後、Google Codeはログイン情報（ほとんどのクライアントが保存します）を要求します。シンプル、簡単、SSHなし

バージョン番号？簡単なコードを使用すると、すべてのチェックアウトにバージョン番号とコミット番号を追加できるため、作業が非常に簡単になります。また、実際に変更を示す使用可能なバージョン番号も取得します。たとえば、1.8.6.5165は1.8.6.5164よりも新しいです。

ドキュメンテーション？まあ、言うのは難しいです。亀は文書化されていますが、私は判断できないほど長い間、公式文書を実際に参照していません。簡単な導入ガイドを読むだけで十分でした。

マージは私が比較できない何かです。私が作業中のファイルに他の誰かが変更をコミットしたときにGitで1回実行しなければなりませんでしたが、SVNでは実行しませんでした。

どちらをお勧めしますか？大規模なチームでは、主に非線形の開発サイクルでgitに利点があります。別のプロジェクトでは、4人のプログラマーが別々のブランチで開始し、非常に奇妙な方法ですべてのコードをマージして、何らかの形で最終的なマスターブランチに変更したのを見ました。Githubとmsysgitには、私が本当に気に入ったプロジェクト全体のための本当に素晴らしい視覚化ツールがありました。

単一の開発者または小規模なチームプロジェクトの場合、Gitsの機能のほとんどは使用されず、そのマイナス部分しか得られないため、SVNが最適です。シンプルさはとてもいいことです

Q4TDからの次の引用は、私にとってそれをかなり要約しています。

「試してみるまでGitが大好きでした。今、私はMercurialが大好きです。」

        — Tor Norbye、Java Posseポッドキャスト

また、hgsubversionはLinux用の非常に優れたSubversionクライアントになります（通常TortoiseSVNを使用するWindowsとは異なり、通常コマンドラインを使用します）。最大の利点.svnは、すべてのフォルダーにサブフォルダーがなく.hg、最上位にあることです。

更新：「gitがあなたにとってうまくいかなかった理由と、Mercurialがどのようにうまく機能したかについてもっとコメントしてください」というコメントでのAlexの要求に応えて：

Git が私のために機能しないとは言いませんが、Murcurialはより良いIMOで機能します。

一言で言えば、これはMercurialです。

これはGitです。

そして、私はMercurialがほとんどの開発者がそれをするために必要とするすべてをすることを主張します。

確かに、私はたまにGitしか使用していませんが、プログラミングコミュニティは、簡潔さと優雅さのために、RubyやPythonなどの言語を悪用していますが、Gitはラクダの委員会によって設計されたラクダのように感じます。

ああ、今あなたがやったことを見て？あちこちで暴言があります。一緒に移動して、何も見えません...何も見えません...

更新2：そして、私がちょうど出会った別の適切なツイート：

「ブランチは、ヒルベルト空間の部分多様体をマッピングする同相の内的ファンクターであるという基本的な考え方を理解すれば、Gitは簡単になります。」

単一の「最高の」バージョン管理システムではなく、単一の最高のVCSパラダイムがあります。

複数の異なる集中型バージョン管理システムと複数の異なる分散バージョン管理システムを使用しました。そして、誰もCVCSを自分に課すべきではないことをためらいなく言うことができます。

どの DVCSを選択しても構いません（私のお気に入りはGitです）が、DVCSを使用してください。1つは、はるかに柔軟になります。DVCSはCVCSワークフローを簡単にエミュレートできます（リポジトリをフォークすることはなく、ローカルリポジトリを独立したフォークではなく、単なるチェッシュとして扱います）が、その逆は不可能です。そして論理的ながら、このエミュレーションを行うとすべきいくつかのオーバーヘッドを運ぶ（そして実際に、それはない）、私はまだそれが簡単に使用することに、私が使用しているCVCSsのどれよりも（はるかにパフォーマンスによるローカルキャッシュに言及していない）を見つけます。

最高のバージョン管理ソフトウェアに出会ったとは言えませんが、VSSとMKSには近づかないように言うことができます。両方とも、どんな犠牲を払っても避けるべき犬です。

最高とは言いませんが、非常に興味深い機能とコンセプトを備えたものです。

Fossilは、リポジトリとしてSQLiteデータベース上に構築された分散バージョン管理、バグ追跡、Wikiプロジェクトです。

Team Foundation Server

なぜなら：

1. これは、優れた堅実なVCSです。（私はそれを決して最良とは思わないでしょうが、素晴らしい追加機能があります。）
2. Visual Studioに統合されたビルトインタスクとバグトラッキングにより、集中力を維持し、1か所ですべての作業に必要なものを把握できます（バグまたはタスクに自動的にチェックインを適用して閉じることはできますが、これを行うには、他のシステム/ eclipse / etcのプラグインを入手してください。）
3. タスク/バグ追跡/プロジェクトをProject Serverに直接統合するため、プロジェクト計画やタイムシートを最新に保つ必要はほとんどありません。Project Serverでのプロジェクトの更新は、タスクとしてTFSとVisual Studioに自動的にフィルター処理され、自動的に表示されます。

私は長い歴史の中で多数のバージョン管理システムを使用しました。

• RPPT-（パンチ紙テープのロール）。靴箱の中。冗談じゃないよ。
• PVCS-（Polytronバージョン管理システム）。最初に使用した実際のVCS。
• SCCS-ずいぶん昔、私はそれについて例外的に良いことも悪いことも覚えていません。
• RCS-他の人が指摘したように、汗をかいたロバのボールを吸うだろう。
• CVS-2人以上のプログラマーと一緒に使用した場合、それは痛みでした。最高の機能：rcs2cvs。
• VSS-火曜日を除き、リポジトリ全体が破損する場合を除き、動作します。
• Perforce-私の車よりも費用がかかります。VCS自体は受け入れられますが、VCSを使用するあらゆる側面を管理しているDickheadのIT担当者は、VCSを「優先」リストに載せることはありません。
• SVN-分岐とマージはめちゃくちゃですが、一般的には以前のものよりも優れています。レビューを待っている多くの小さな未解決の変更ではあまり良くありません。
• Mercurial-私はそれでどんな小さな経験をしているのかが好きです。次のプロジェクトで試してみるかもしれません。
• Git-使用する機会がなかった。

カップルは恐怖でしたが、ほとんどは「罰金」でした。彼らは私の邪魔をしませんでした。道具が私の人生を著しく難しくしない限り、私は本当に気にしません。

本当のことは、それぞれの長所と短所を理解することです。ターゲット環境を理解します。

• 分散またはローカル
• 小チームまたは大
• ホストされたvcsサービスかどうか
• 他のツールへの簡単な統合

ジョエルはまた、重要な観察結果を出しました。ツールとその真の使用モデルを学びましょう。彼は、MercurialをSubversionのように振る舞わせようと奮闘しました。

私のオフィスで使用している新しいシステムの1つはPlastic SCM（http://www.plasticscm.com/）です。それは私たちの小さなチームにとって非常にうまく機能し、ソース管理のあらゆる側面をうまく制御できます。

SCCS。

または、過去38年間洞窟に住んでいなかった場合、CSSC。

真剣に、私の会社はSCCSに基づいた一種の擬似DVCSであるTeamWareを使用しています。

いいえ、冗談ではありません。

Sunはほんの数年前にTeamWareからMercurialに切り替えました。ここで、Javaが非常に遅いように見える理由を理解する必要があります。

MPW：まあ、私は努力にもかかわらずそれを本当にレビューすることはできません。

これは高校でプログラミングを学んでいたときに戻ったもので、本当に無料のC ++コンパイラはMacintoshプログラミングワークベンチのみでした。

MPWには多数のツールが付属しており（いずれも再編集されず、個別のダウンロードでした）、そのうちの1つはバージョン管理ユーティリティでした。テキストが1行表示された小さなウィンドウが開き、そこにプロジェクトまたはファイルをドラッグアンドドロップします。それは私がこれまで発見することができたドキュメントがなく、他のすべてが素晴らしいドキュメントを持っているように見えることを考えると珍しいので、私はそれを使用する方法を完全に解決したことはありません。

それがVCでの私の最初のブラシであり、長い間最後のブラシでした。今、私はすべてにgitを使用しています。

RCS-リビジョン管理システム

ソロコーディングがとても簡単になりました。

ClearCaseではなく、少なくともUnix / Linuxシステムの場合（おそらくWindowsではインストーラーの方が簡単です）。ClearCaseサーバーをアップグレードするよりも、新しいツールPerforceを学ぶ方が簡単でした。

私は現在職場でPerforceを使用しており、気に入っていますが、それが最良かどうかはわかりません。コマンドライン環境とPerforceサーバーのセットアップは少し厄介ですが、Visual Clientの使用はかなり簡単です。私は、ユーザーが日常のタスクのためにかなり楽な時間を過ごしていると思うのが好きです。それは単に初期設定に多少の手間がかかります。

私はVisual SourceSafeを使用し、それを嫌っていましたが、それは何よりも優れていましたが、それほどではありませんでした。過去数年間、プログラマーのジム・ヴォリスによって作成、所有、サポートされているQumasoft.comのQCVSと呼ばれるものを使用していました。シンプルなGUI、安い価格、良いサポート。

ちょうど仕事をします。