SVNの使い方が不十分です-Mercurialが答えですか？
仕事ではSVNを使用しますが、名前のみです。ブランチやマージは行いません。リポジトリの2つのコピーを保持します。1つはデプロイメントを実行するときにコピーされる「タグ」ブランチとして機能し、バグ修正と「これはできるだけ早く実行する」タイプの機能のために保持されます。 1つのコピーで行われた変更を別のコピー（「トランク」）にコピーすることを忘れないでください。プロジェクトを分割するのではなく、リポジトリ内の単一のフォルダ内に12のプロジェクトがあります。つまり、SVNを使用するのはコミットできることだけです。それ以外はすべて手動で行われます。
Mercurialを評価してきました。私は過去にGitを使用したことがあり（私はDVCSを使用した唯一のチームです）、Mercurialをすぐに入手しています。 Mercurialを他のチームに「より良い方法」として導入することは、分岐が簡単で、マージがはるかに簡単で、ローカルにコンテンツをコミットして、中央にプッシュするだけなので、議論しています。準備ができたら分岐します。私たちはSVNのすべてのメリットを享受します（そして、SVNを本当に理解している人がいないため、現時点では多くのメリットを享受していません）さらに、新しい機能のために、バージョン管理されていない大量のファイルをフロートさせる必要がないため、ロールバックする必要があります失敗した。ワークフローは少しシンプルに見えます。「コミット」はローカルであり、「プッシュ」はSVNのコミットのようなものであり、「プル」はSVNのアップデートのようなものです（チームが「最新を取得」と呼ぶ）。
これは良いアプローチですか？チームは非常に柔軟であり、私たちの仕事の質を向上させ、私たちが物事をより簡単にする方法と一緒に行くことに注意してください。CVNは、SVNを使用していない可能性があることを私が尋ねたときさえ、その可能性を秘めています。私たちが使えるもっと良いものはありますか？」だから彼もそれに乗り込んでいる。
はい。
OPで "SVN"を "Perforce"に置き換えると、現在のジョブを開始したときに、手動で変更をコピーするまで、私が気付いた状況はほとんどありません。 Mercurialを使い始めてから2年、誰もがそれが大きな変化であったことに同意します。
私たちは分岐してマージする能力を持っています サポートケースごと、これはQAに信じられないほど有用であり、必要に応じて使い捨てブランチとリポジトリをいくつでも作成できる機能です。これをCIサーバーで構築および検証してから、クラウドテスト環境にデプロイして機能を検証できます。これは、私たちがライブ展開を行うときに、ほぼ100％ それが動作します （明らかに、VCSの範囲外である環境/ DBの問題）。
基本的に、Mercurialに切り替えることで得られたのは、空間の呼吸です。ブランチのコストや、必然的に従う必要があった恐ろしいマージセッションを心配する必要がなくなり、すべてがはるかに簡単になりました。また、FogBugzを多用しているため、Kiln（ホストされているMercurial）との連携が非常に役立ちます。
hginit サイトに関するコメントも、実際に機能するバージョン管理ワークフローの概要としてスポットされています（会社の特定のQAワークフローに合わせて調整するとします）。
バージョン管理を移動する際の唯一の欠点は、変更を推進する原動力であり、主題を読み、実際にツールをその潜在能力を最大限に使用して喜んでくれる誰かを必要とすることです。行う。
DCVSを使用するかどうかに関するチームの規模とチームの分布に関するコメントにも同意しません。本当に、それはCODEの配布についてです。複数の開発サイクルが並行して発生している場合、レガシーシステムのサポートケース、または一連の機能、あるいは新しいシステム（そのサウンドによって）のいずれかである場合、DVCSを使用するとメリットがあります。
別のツールを使用しても問題が解決しない可能性があります。この記事を読むべきだと思います。これが最も役に立ちました。
http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx
記事の要点はここに要約されていると思いますが、読んでください：
最後に：実際にはツールについてではない
さまざまなソース管理システムの操作と統合に費やしてきたすべての時間の中で、1つの結論に達しました。それはツールではなく、使い方です。それはひどくハッキングされた声明ですが、ここでは特にそうです。ソースコードの変更を適切に管理するために使用する場合–ビルドのラベル付け、例外による分岐など–最小のソース管理システム（* cough * SourceSafe * cough *）でも、無計画なコミットとプッシュ。
いいえ。テクノロジーがこの種の問題を解決することはほとんどありません。
MercurialはSubversionよりも複雑です（はい、分岐とマージの方が優れており、おそらく簡単ですが、SubversionのモデルはMercurialのモデルよりはるかに単純です）。 Subversionをこのように頭の痛い方法で使用している場合、最終的にMercurialを使用する可能性があります。
- a）十分以上
- b）不十分ですが、Subversionの現在の使用量よりも優れています
- c）今ほど不十分
- d）今より悪い
c）およびd）最も可能性の高い結果のように聞こえる。最終的にa）またはb）になると思う理由を書き留めてください。
大規模なチームがどのように機能するかについて話すことはできませんが、小規模なチームにとって、これらの大きなSVNの問題の多くは実際にはSVNの問題ではありません...それらは開発の問題です。最新の開発標準に従っていない場合（最も重要なのは、継続的な統合を行うこと）、バージョン管理は、説明している混乱に変わります...新しいシステムに進む前に、問題の真の根本原因分析を実行してください。 ...
いいえ。ツールは方法論を置き換えるものではありません。
SubversionをSCMとして使用しない場合、can使用しないMercurialも（そしてそれはおそらく起こるでしょう）
SVNは必要なことを行うことができ、疑わしい見返りを得るために途中で馬を変更する必要はありません。
何をするにしても、信頼の問題を克服する必要があります。誰かがワークフローを変更するように全員を説得できる必要があります。これは、たとえあなたの側に論理と事実があるとしても、最良の状況でさえ簡単ではありません。これは、組織で行うのが最も難しいことの1つです。あなたがそれを失敗したり、荒れたりすると、あなたは信頼を失い、その信頼を取り戻すのは非常に困難になります。
人々が成功したことを知っていることがいくつかあります。おそらくそのうちの1つがあなたのチームのために働くでしょう：
チームに一連のワークショップを提供するために「コーチ」を連れてきてください。これはおそらく外部の人物である必要があります（皮肉なことに、多くのチームは、チームの誰かを信頼するよりも、外部の人間を信頼する方が簡単なことがよくあります）。彼女のことを完全に理解し、これらのスキルをすべての理解レベルの人々に効果的に教え、新しいVCS（*）をチームのワークフローに展開するための実用的な計画を考案できる人でなければなりません。
「skunk-works」プロジェクトを開始して、小規模なサイドプロジェクトで新しいVCSをテストして検証します。新しいものを試そうとするいくつかの「アルファ」開発者を選び、失敗したたくさんの実験を積み重ねることを気にしないでください。スカンクワークスがワークフローで具体的な反論の余地のない改善を実証できたら、それをチームの残りのメンバーにロールアウトして、それを支援する伝道者が2人います。
（*）「新しいVCS」とは、必ずしもMercurialやgitを意味するわけではなく、SVNでもかまいません（正しく行われます）。