小さな個人的なプロジェクトに Mercurial を使用することにしました。
私が読んだヘルプのほとんどは、複数のユーザー間での変更のマージについて述べています。ソロなのでそんなことはありません。
複数のリポジトリを持つ必要がありますか? 私の開発用コンピューターは既に夜間に Windows Home Server にバックアップされているため、バックアップ目的だけで別の場所に 2 つ目のリポジトリを用意する価値はないようです。
毎日分岐する必要がありますか？それともリリース前後？それともいつ？
一般的に、Mercurial を使用する孤独な開発者にはどのような方法をお勧めしますか?
Mercurialを使用して、codeplexでホストされるユニットテストフレームワークであるFsCheckを開発しています。私は現在唯一の開発者ですが、時々人々が私にパッチを送ってくれます。
具体的には、ファイルシステムに「FsCheck」というフォルダが1つあります。その中に、mainと呼ばれる1つのリポジトリ、つまりフォルダがあります。通常、その隣にいくつかのフォルダがあり、特定の機能やバグ修正などに取り組んでいます。たとえば、bug-escapingexceptions、feat-statefulchecking、patch-userFooなどです。これらはhgクローンを使用して作成されます。
機能やバグ修正が終わったら、そのフォルダ内のすべてをコミットして、メインにプッシュします。おそらくメインでマージします。（hg commit、hg push、hg merge）。次に、フォルダを削除します（hgstatusとhgoutgoingを使用して、有用なものを破棄しないように注意してください）。
リリースの直前を除いて、メインで作業することはほとんどありません。リリースの直前に、最終的なクリーンアップを行います（ドキュメントなど）。リリースする前に、メインでリリース番号（hg tag v0.5.1）をタグ付けします。
Codeplexはsvnをsourcecontrolとして使用します。私はこれをリリースの保存にのみ使用します。リリースには、ローカルでチェックアウトされたSVN作業コピーを使用し、hgアーカイブを使用してMercurialリポジトリをコピーします。次に、svnを使用してコミットします。プリミティブですが、動作します（WindowsでMercurialをSVNの「スーパークライアント」として使用することは、私の意見ではまだあまりユーザーフレンドリーではありません）
以前のリリースではまだメンテナンスを行う必要はありませんでしたが、そのリリースのリビジョンからメインリポジトリのクローンを作成し（タグを付けたので簡単です）、別のリポジトリで作業します。メイントランクにマージするのは、変更をメインにプッシュしてマージするのと同じくらい簡単です。
要約すれば：
それはあなたのブランチとあなたが取り組んでいるものがファイルシステムで直感的に見えるので素晴らしいです。
あなたの質問の言い方からすると、バージョン管理の用語に関連する誤解があるかもしれません。
プロジェクトごとに1つのリポジトリが必要です。リポジトリは、単にファイルシステム上のフォルダと考えることができます。特定のフォルダーでMercurialリポジトリーを初期化すると、そのフォルダー内のすべてのファイルとそのサブフォルダーのいずれかが、バージョン管理されるリポジトリーに追加される資格があります。必ずしもすべてを追加する必要はありませんが、必要に応じていずれも追加できます。
必要に応じて、バックアップの形式として、またはコードを他のユーザーと共有する方法として、このローカルリポジトリをリモートリポジトリにプッシュできます。ただし、それが単なる個人的なプロジェクトである場合、特にバックアップソリューションがすでに用意されているため、これはおそらく必要ありません。
ブランチは通常、プロジェクトのさまざまな「バージョン」を分離しておくために使用されます。一部の人々が言及しているように、これは、コードをリファクタリングする方法を試したり、特定の問題に対する別のアプローチをテストしたりするための単独の開発者として役立ちます。それがうまくいかない場合は、どこにロールバックするかを心配する必要はありません。ブランチをトーチするだけです。それが機能した場合は、ブランチをメインリポジトリ（「トランク」）にマージして続行します。
コードの「リリース」を行う段階に到達し、古いバージョンを維持し続ける必要がある場合は、ブランチも使用することをお勧めします。たとえば、バージョン1.0をリリースし、それを使い始める人がいるとします。彼らがそれを使用している間、あなたは個人的に次のリリース、おそらく1.1に向けて作業を続け、トランクリポジトリに機能を追加します。さて、誰かがリリースされた1.0コードのバグを発見し、修正する必要がありますが、リリースされる状態ではないため、トランクで修正してそのコードを提供することはできません。ここで、1.0ブランチが役に立ちます。1.0ブランチでバグを修正し、バグ修正の変更をトランクにマージして、そこでもバグを修正することができます。次に、バグ修正を使用して1.0を再パッケージ化し、ユーザーに公開します。
それ以外は、一般的にMercurialソロの使用に関連する凝った仕事はあまりありません。いくつかの作業を行い、機能を終了したら、それをコミットして、必要に応じて将来戻ってくることができる「チェックポイント」を自分に与えます。保存するたびにコミットする必要はありません。何か重要なものを追加したと感じたときにコミットしてください。これにより、プロジェクトを振り返る必要がある場合に、プロジェクトの素晴らしい履歴が得られます。
詳細については、この本を読むことを強くお勧めします：Mercurialによる分散リビジョン管理。高度なトピックを読む必要はありませんが、少なくとも第1章から第5章と第8章を読むと、Mercurialとバージョン管理全般についての優れた入門書が得られます。
Mercurialとは別の分散バージョン管理システムを使用していますが、これが重要かどうかは疑問です。
私のソロプロジェクトでは、ブランチをかなり頻繁に使用しています。私は通常、メインの開発ブランチ（「トランク」）を持っています。これは常に動作するバージョンがあるはずです。つまり、単体テストやその他の自動テストに合格し、テストカバレッジから明示的に除外した小さなビットを除いて、すべてのコードがこれらのテストによってテストされます。これにより、トランクは常に開発に適した状態になります。
変更に取り掛かるときはいつでも、トランクブランチから新しいブランチを作成します。これにより、自由にハッキングすることができます。たとえば、このブランチで自動テストが通過することを心配する必要はありません。孤立した領域なので、何度でもコミットできます。マイクロコミットは、分散バージョン管理での私のお気に入りの機能です。ブランチでの作業が終了したら、トランクにマージします。
このスタイルの作業の利点は、作業中の変更が悪い考えであることが判明した場合、簡単に取り消すことができることです。実際、変更はマージされていないため、取り消すことはできません。
時々私は怠惰で、私が開発しているいくつかの新しいもののために新しいブランチを作成しません。仕事を終えるのに予想以上の時間が必要なときは、必ずこれは間違いであることがわかります。この途中で別の無関係な変更を行う必要がある場合は、さらに悪化します。all-work-in-its-own-branchスタイルに従うと、無関係な変更を独自のブランチで実行してトランクにマージし、必要に応じて他のブランチでトランクからの変更をマージできます。
私は毎日Mercurialを使用しています。ここを参照してください。また、Mercurialをサポートする数少ない無料ホスティングサービスの1つであるShareSourceを支援しています（クレジットページにいます）。XenがBitKeeperをドロップして以来、私はHGを使用しています。
個人的なプロジェクトの場合は、絶対にブランチを避けることをお勧めします。ブランチが何であるかについてのMercurialの考え方は、あなたが期待するものとはかなり異なります。Gitのような他のシステムは、分岐（およびマッドサイエンティストのアイデア）を少し簡単にします。ただし、Gitを使用するのは、簡単で安価なブランチが必要な場合のみです。
hgでの私の典型的な日：
(See where I left off)
# hg status
(See what I was doing with foo)
# hg diff -r tip src/foo/foo.c
(Finish one module, commit it)
# hg commit src/foo/foo.c
(Push changes)
# hg push
マージも非常に簡単で、関連するリポジトリから特定のリビジョンを取得します。ただし、ソロの場合、解決するためのマージが提示された場合は、リモートリポジトリを更新しないことで失敗した可能性があります。
リリースから1年で大人気になったソロホビープロジェクトをいくつか始めましたが、HGを使って良かったです。その構文はsubversionに近く、非常に直感的で非常に移植性があります。
確かに、はい、私はGitとSVNを使用していますが、個人的なプロジェクトには使用していません。リポジトリインデックス（リンクが投稿されています）に関するメモですが、外観を簡単に変更して各リポジトリからRSSを取得したかったので、PHPでhgwebdirを書き直しました。
要するに、個人的な使用のために、あなたはそれが非常に友好的であるとわかるでしょう。コミット、タグなどは単純です..本当に必要でない限り、ブランチは避けてください。
これは、 Mercurialを使用してWebサイトを管理する方法を説明するために私が少し前に書いたチュートリアルです。キー、hgrcなどを設定するときに興味深いと思うかもしれません。
これらは通常、ソフトウェア プロジェクトで作業する場合と同じです。単純にバージョン管理があるかどうかは議論の余地がありません;)
通常、機能の準備ができたらコミットします。バックアップがあるので、作業を安全に保存するためだけに毎日コミットする必要はありません。
分岐用: 私のソロ プロジェクトでは、主にアイデアを試すために使用します。同じ問題に対する別の解決策がある場合。このため、私は Git の stash コマンドも気に入っています。
ただし、複数のリポジトリがあります。プッシュ先のシェル アクセスを備えたホスティングがあります。そのため、どこで働いていても、どんなワークステーションを持っていても、そのレポと同期できます (仕事中: コードを書く時間があれば、自宅のデスクトップで、実家にいるときはラップトップで)。
リポジトリが存在するマシンを既にバックアップしているため、複数のリポジトリが必要な理由がわかりません。
また、機能を調査したいが、メインのコード ブランチで混乱したくない場合は、自分でブランチを作成することになるでしょう。
しかし、私が以前に提起した質問から何かを抽出するかもしれません。
以前は個人的なバージョン管理システムとして CVS、Perforce、Subversion を使用していましたが、約 2 週間前から Mercurial に移行しました :-) 職場では MS Team System を使用しています ...
私にとって最も注目すべき新機能は、異なるマシン間での簡単な転送です。職場では、mercurial リポジトリにあるものがあります (hg を Team System に対するスーパークライアントとして使用しています)。私は定期的にラップトップとの間ですべての変更をプッシュ/プルするので、両方のマシンで完全な履歴を保持しています。
自宅でも、ラップトップからレポをプッシュ/プルします。
その結果、私はどこにいても仕事をすることができ (強力なコンピューターを使用するホーム オフィス、ラップトップを使用する移動中、または職場)、変更が失われるかどうかを心配する必要はありません。わかりました、時々私は2つの変更をマージする必要がありますが、それはめったに害はありません... hgはそれを非常にうまくやっています。
さらに、Mercurial の「セットアップ コスト」は非常に低いです。チュートリアルを読んでインストールし、「hg init」と言って作業を続けます。何かが神聖な SVN サーバーに属しているかどうか、どこに置くかなどを判断する必要はもうありません。Mercurial の「フリクション」は SVN のものより少し低くなっています。
SCMは、エディターの一種の「スマートな」アンドゥバッファー拡張機能です。時間をさかのぼることができます。問題は解決したかもしれませんが、リファクタリングされているため削除しましたが、解決策が再度必要になるなどです。視覚的な差分を設定すると、前回から何が変更されたかがわかります。コミットするか、過去2日間、私は常にコードを確認し、古いソリューションが気に入らない場合はコードを変更しています。
分岐はストリームに取り組んでいます。一方向に進み始めたが、もっと考える必要があり、その間に別のことに取り組みたい場合は、それが役立ちます。
DVCSはリポジトリを単一のユニットとして処理することに注意してください。（フィルターを使用して）ファイルごとにコミットできますが、リポジトリ全体に対して変更が保存されます。これは、単一ファイルの変更がより定期的であるcvs（svn）ユーザーを混乱させます。
複数のクローンを作成するもう 1 つの優れた理由 (少なくとも複数のコンピューターがある場合) は、コードに依存関係が導入されているかどうかを簡単に確認できることです。(つまり、コードは別のマシンで実行されます。そのマシンには、プライマリ ワークステーションにあるすべての開発パッケージが含まれていない可能性があります)
これは、既存のアプリケーションの保守と機能の追加 (または大きなバグの修正) を同時に行っているかどうかによると思います。
このようにして、独自のブランチで新しい機能を作成しながら、メイン ブランチでバグを修正できます。
私は自分のアプリケーションでまさにそれを行っていますが、CVS のローカル バージョンを使用しています。また、新しい開発者がチームに追加された場合でも、準備は万端です。
これはバックアップとは別の問題であることに同意します。
がんばれ、
ランディ・ステグバウアー
単独でも、常に Git または Mercurial を使用しています。
再利用可能なコンポーネントを他のプロジェクトで利用できるようにしたい場合は、リポジトリを分離します。コミット時に自動的にプッシュされるように構成しました (Tortoise HG プラグインで行いました)。プッシュを忘れることがあり、地理的に移動するときにそのコードが必要になるためです。
だから、これが私のヒントです。
SCC を実装するさまざまな方法を概説しているこのリンクを読んで、ニーズに最も適した方法を選択することをお勧めします。