SVNの使用が不十分-Mercurialが答えですか？

職場ではSVNを使用していますが、名前のみです。分岐もマージもしません。リポジトリの2つのコピーを保持します。1つは展開の際にコピーされ、バグ修正のために保持される「タグ」ブランチとして機能します。一方のコピーで行われた変更をもう一方のコピー（「トランク」）にコピーすることを忘れないでください。リポジトリ内の単一のフォルダー内に、プロジェクトを分割するのではなく、12個のプロジェクトがあります。要するに、SVNを使用するのはコミットできることだけです。他のすべては手動で行われます。

Mercurialを評価しています。私は過去にGitを使用しました（DVCSを使用したのはチームで1人だけです）。Mercurialをすぐに使用しています。ブランチは簡単で、マージははるかに簡単で、ローカルに心のこもった内容をコミットして中央にプッシュするだけなので、物事を行う「より良い方法」としてMercurialをチームの他のメンバーに紹介することを議論しています準備ができたら分岐します。SVNのすべての利点が得られます（そして、SVNを本当に理解していないので、今のところ多くの利点が得られません）。また、新しい機能については、バージョン管理されていないファイルがたくさんあります。失敗した。ワークフローは少し単純に思えます-「コミット」はローカルであり、「プッシュ」はSVNのコミットに似ていることを覚えておく必要があります。

これは取るべき良いアプローチですか？チームは非常に柔軟であり、仕事の質を向上させ、物事を簡単にする方法を提供することを心に留めておいてください。CIOは、SVNを使用していない可能性について述べたときに私に尋ねましたより良いものがありますか？」彼も一緒に乗っています。

はい。

OPで「SVN」を「Perforce」に置き換えると、現在のジョブを開始したときに、手動変更コピーにいたるまで、私が見つけた状況がほとんどあります。2年後、私たちはMercurialを使用していますが、これは大きな変化であることに全員が同意しています。

サポートケースごとにブランチおよびマージする機能があり、これはQAにとって信じられないほど便利です。また、必要に応じて任意の数のスローアウェイブランチおよびリポジトリを作成し、CIサーバーでビルドおよび検証してから展開することができます。クラウドテスト環境に移行し、機能を検証します。これは、ライブデプロイを行うときに、動作することをほぼ100％確信しているという安心感という点で大きなメリットがあります（VCSの範囲外である環境/ DBの問題はありません）。

基本的に、水銀に切り替えることで得られたのは、呼吸空間です。ブランチのコストや、必然的に従うことになった恐ろしいマージセッションを心配する必要がなくなり、すべてがはるかに簡単になりました。また、FogBugzを非常に頻繁に使用しているため、Kiln（ホストされているMercurial）との連携が非常に役立ちます。

hginitサイトに関するコメントも、実際に機能するバージョン管理ワークフローの概要として注目されています（会社の特定のQAワークフローに合わせて調整すると仮定します）。

バージョンコントロールを移動する際の唯一の欠点は、変更を実際に推進する人物が必要であることです。この人物は、問題をよく読んで、ツールをその可能性を最大限に活用します。行う。

DCVSを使用するかどうかに関するチームの規模とチームの分布に関するコメントにも同意しません。本当に、それはコード配布についてです。複数の開発サイクルが並行して行われている場合、レガシーシステムでのサポートケース、多くの機能、さらには新しいシステムでさえ（DVCSを使用するとメリットがあります）。

別のツールでは問題を解決できない可能性があります。この記事を読む必要があると思いますが、最も役立つことがわかりました。

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

記事の要点はここにまとめられていると思いますが、読んでください：

最後に：本当にツールについてではない

さまざまなソース管理システムの操作と統合に費やしたすべての時間で、1つの結論に達しました。それはツールではなく、使用方法です。それはひどくハッキングされた声明ですが、ここでは特にそうです。ソースコードの変更（ビルドのラベル付け、例外による分岐など）を適切に管理するために使用すると、ラメストソース管理システム（* cough * SourceSafe * cough *）でさえ、多数の無計画なコミットでMercurialセットアップよりもはるかに優れたパフォーマンスを発揮します。プッシュ。

いいえ。テクノロジーがこの種の問題を解決することはめったにありません。

MercurialはSubversionよりも複雑です（はい、分岐とマージの方が優れており、おそらくより簡単ですが、SubversionのモデルはMercurialのモデルよりもはるかに単純です）。Subversionをそのような頭の痛い方法で使用している場合、Mercurialを使用することになります。

• a）適切またはそれ以上
• b）不適切ですが、現在のSubversionの使用よりも良い
• c）現在と同様に不十分
• d）今より悪い

c）およびd）最も可能性の高い結果のように聞こえます。a）またはb）に終わると思う理由を書き留めてください。

大規模なチームがどのように機能するかについて話すことはできませんが、小規模なチームにとって、これらの大きなSVNの問題の多くは、実際にはSVNの問題ではありません...それらは開発の問題です。最新の開発標準に従っていない場合（最も重要なことは、継続的インテグレーションを実行している場合）、バージョニングは説明しているとおりの混乱に変わります... ...

いいえ。ツールは方法論を置き換えるものではありません。

あなたがいる場合SCMとしてSubversionを使用していない、あなたはできる ものMercurialを使用していない（そしてそれはおそらく起こります）

SVNは必要なことを行うことができ、疑わしい支払いのために馬を途中で変える必要はありません。

何をするにしても、信頼の問題を克服する必要があります。誰かがワークフローを変更するように全員を説得できなければなりません。たとえ論理や事実があなたの側にあるとしても、これは最良の状況でも簡単ではありません。組織で行うのが最も難しいことの1つです。失敗したり荒れたりすると、信頼を失い、その信頼を取り戻すのは非常に困難になります。

人々が成功したことを知っていることがいくつかあります。おそらくそのうちの1つがあなたのチームのために働くでしょう：

1. チームに一連のワークショップを提供するために「コーチ」を持ち込みます。これはおそらく外部の人である必要があります（皮肉なことに、多くのチームはチームの誰かを信頼するよりも、多くの場合、部外者を信頼する方が簡単です）。自分のことを徹底的に知っていて、理解のあらゆるレベルの人々にこれらのスキルを効果的に教え、チームのワークフローに新しいVCS（*）を展開するための実用的な計画を考案できる人でなければなりません。

2. 「スカンクワークス」プロジェクトを開始して、小さなサイドプロジェクトで新しいVCSをテストして検証します。新しいものを試してみて、失敗した実験の束を積むことを気にしないカップルの「アルファ」開発者を選択してください。skunk-worksがCONCRETEの反論の余地のないワークフローの改善を実証できるようになったら、それをチームの他のメンバーに展開してみてください。

（*）「新しいVCS」とは、必ずしも水銀またはgitを意味するものではなく、SVN（適切に行われた）のこともあります。