むかしむかし、私のプログラムの新しいバージョンで別のアーカイブを失ったとき、私は顧客からの驚きの外観と質問に出くわしました。 「その瞬間、私自身は彼らについて何も聞いていませんでしたが、これは組織内の孤立したケースからは程遠いため、結果として転覆は習得されました。 しばらくして、作業の性質（頻繁な出張とさまざまな場所での出張でソースを使用する必要性）により、 mercurialに切り替えることが決定されました。これにより、リポジトリの完全なコピーを取得し 、本格的なメインリポジトリとして使用できます（ただし、概念は条件付きであり、混乱を避けるために主要なものとして割り当てられています）、その時点でsvnが持っていた制限と問題はありませんでした（望ましいリビジョンの適切な作業コピーを取得できず、中央リポジトリに依存していません）。 Linux上のMercurialは、学習しやすく使いやすいことが実証されています。
開発と実装の後、SLEをすでに浸透させたにもかかわらず、混乱がまだ続いている隣の部門に同情するだけでした。 確かに、現時点では、これはそのようなシステムでポイントを見ていない人々により依存しています。
ソースの以前のリビジョンを常に取得でき、エラーがなかったため、その時点以降に発生した変更を簡単かつ迅速に確認できるため、ハード通貨を使用するとプログラムをより速くデバッグできることも言う価値があると思います。 理想的には、検索が高速になるようにリビジョンを小さくする必要があります。
Mercurialの実装を開始するには？
開発者が一人の場合、この質問は発生しません。 私はダウンロードしてインストールし、それを理解し、使用しました。
チームが小さい場合、一般労働者の理解がなければ、上からの命令または下からの長期教育によって自発的に強制的に行われます。 理解すれば、すべてが自然に判明します。
大規模なチームは、上記のすべてを組み合わせます。 誰もが参加する大きなトピックでは、硬貨の使用を嫌がると、開発時間が長くなり、資金が失われる可能性があることに注意してください。 したがって、転送されたソースファイルはバージョン管理を使用して保存する必要があることを顧客に納得させる必要があります。
メインリポジトリをフォローし、それにすべての変更を加える人（小さなグループ）を強調表示することから始めます。 残りはこの人/グループを通してのみこれを行うべきです。 同時に、「カストディアン」のグループは、保存されているソフトウェアのアイデアと矛盾するのに十分な能力を備えている必要があります。もちろん、コードに対するすべての変更は、オーバーレイなしでリポジトリに入力できる状態にする必要があります。 もちろん、リポジトリを見ている人は、SLEを他の人より悪くはないが、少なくとも-義務を果たすために知っているべきです。 誤解した場合に他の人を訓練することもできます。
これがなぜ必要なのかを説明するために、いくつかの例を示します。
出張で到着した後、そこに保存されているリポジトリ（メインリポジトリと見なされる）を見て、特殊文字、象形文字、その他のわいせつな言語の説明が記載されたすばらしい改訂版を見ました。 これらの変更は、このことにあまり精通しておらず、テキストの不適切なエンコードなどの些細なことを気にしない人々によって行われたことが判明しました。 しかし、同時に、そこにどのような変化があり、誰がそれを行ったのかを理解することは不可能になりました。 それらをロールバックする可能性もありませんでした（実際には機会がありますが、時間がかかり、時間がかかります）。
また、複数のリポジトリが殺害されて死亡したのが見られましたが、そこからは何も取得できませんでした。 変更を行ったユーザーがコミット構造を台無しにしました。 なぜ、そして彼自身は勉強中に時々甘やかされました。 確かに、ほとんどがコピーです。 したがって、データの整合性を保護するには、知識のある人が必要です。
mercurial`omの使用方法について、チームには伝えません。 彼らのサイトはドキュメントでいっぱいです。
Mercurialにパッチが必要なのはなぜですか？
パッチは非常に強力で物議を醸す水銀機能です。
当初、hgにはコミット（コミット）によってのみ変更を加える機能がありました。これは、リポジトリに追加した後は修正できませんでした。ただし、最後のロールバックを除きます。 しかし、1つだけです。 時間が経つにつれて、 mq拡張機能が登場し、通常のコミットと同様のパッチを作成できるようになりましたが、変更可能です。 つまり パッチは、修正可能な最後のコミット/パッチからの一連の変更です。
これは同時に長所と短所です。 これの長所は、何かを忘れたり、封印したり、エラーに気付かなかった場合、この変更で修正できることです。 パッチ[および]は、チャット/ icq / jabber /電子メールなどを介して送信できます。 プログラム全体と比較して、それは小さいです。 ここでは、いわゆる バンドル、すなわち 2つのコミット間のリポジトリの一部ですが、パッチを開いて確認/評価し、必要に応じて修正できますが、バンドルはそうではありません。
パッチの弱点は、パッチが多ければ多いほど、リポジトリ内のストレージを台無しにする可能性が高いことです。 または、キュー内の最も古いパッチを修正する場合、この編集が影響する可能性のある他のすべてのパッチを編集する必要がある場合があります。
ここから結論づけることができます。
- パッチを使用すると、リポジトリの外観が改善されます。 パッチを編集できるため、変更を修正してコミットの束を1つに絞ることができます。
- パッチはサイズが小さいため転送するのが便利で、お金と時間を節約できます。
- パッチを（コミットと同様に）大きくすることは望ましくありません。 これにより、エラーを見つけることが難しくなります。
- パッチを簡単に開いて、テキストエディタ/ビューアで変更を確認できます。
- キューに多くのパッチがあってはなりません（できれば7〜10以下で、それで作業するのは不便になります）。クリティカルマスと準備ができたら、コミットに転送する必要があります（hg qfinish）
- 他のコミットと同様に、パッチを含むソフトウェアは少なくともコンパイルする必要があり、実行することが非常に望ましいです（もちろん、これは必要ではありませんが、任意のリビジョンのソフトウェアを実行しようとする不快な瞬間を避けます）。
- 適切な知識と注意を払えば、パッチはパッチファイルで直接編集できますが、作業コピーに重ねてはいけません。
- コミットとパッチを論理的に完全にすることが望ましい。
- パッチ/コミットでは、1行の見出し（70文字以内）を作成し、変更の本質をすべて反映し、パッチで何が、なぜ行われたかを説明する十分なコメントを空の行に書いておくとよいでしょう。 これは、たとえば、1年で開発者や彼を置き換える人のためにそこで何が行われたかを把握するのに役立ち、短縮された完全なリビジョンログを見るのにも便利です。
最後に、mqがmercurialパッケージに含まれていることと、hgk拡張機能を追加することで、適切なコマンド（hgビュー）を入力できるウィンドウを表示できるようになりました。 パッチはそこにマークされているため、これらはコミットではないことがわかります。 すべての拡張子は、.hgrc構成ファイルに記述する必要があります。
今のところすべてです。 たぶん誰かが助けてくれるでしょう。