昨年、私は転覆にはまっています。私は唯一の開発者であり、自分のプロジェクトのいくつかにも取り組んでいます。SVN を使用すると、すべてを簡単に管理できます。また、HTTPS を介してオンライン サーバーでホストされているため、どこからでも自分のコードにアクセスできます。コードを本番/開発サーバーにデプロイするのにも最適です。
私のポイントは、それが私がする必要があるすべてを行い、私を失敗させたことがないということです.
もっと良いものはありますか？生活を楽にするために使用できる別の製品の機能が不足していませんか? 私は常に最高のソフトウェアを使用することに専念しており、新しいテクノロジーへの移行に問題はありません。
私は GIT について聞いたことがあり、いくつかの調査を行いました。私はそれを試してみるつもりですが、それをいじっている間、「業界標準」と見なされている他のソース管理システムがあり、SVNよりも優れていますか?
Git、Mercurial、および Bazaar は、常にネットに接続しているわけではなく、リポジトリの中央バージョンが 1 つ存在する必要がないという考えに基づいて動作する分散制御システムです。
飛行機に乗っていてコミットできない場合など、「機内モード」と呼ばれることもある独立した作業をたくさん行っている場合は、Bazaar を見てください。Git や Mercurial よりも順応しやすいことがわかりました。
常にネットに接続して仕事をしていて、開発者があなただけなら、おそらく Subversion を使い続けることができます。
また、ホーム ディレクトリを Subversion に保持することの価値も考慮してください。
マーキュリアル
主に CVS と SVN、ハッピーとコンテンツを使用していましたが、DSVC について多くの騒ぎがあったため、分散ソース管理の調査を開始しました。DSVC を使用してから、自分の開発スタイルが変化したことに気付きました。より流動的で順応性が高くなりました。トランクまたは実験的なブランチに簡単にマージできるようにします。
ギット
Git はクールですが、ソース コード デポを常に維持し、再パックする必要があります。多くの bash スクリプトで構成されているため、Windows での実行に問題があります。しかし、非常に高速で、多くの機能を使用できます。実際には、機能の量が不利になる可能性があります。
BZR
HGを始めてから振り返っていません
個人的には Subversion を使い続けます。専門的な観点から言えば、Subversion と GIT との比較を求める (そして知っている) より多くの仕事を見てきました。また、Subversion の巨大なコミュニティは言うまでもなく、Subversion を中心に構築されたオープン ソース ツールやフリーウェア ツールも多数あります。
ソース管理は常に最新かつ最高のものに関するものではありませんが、より多くの場合、何が実証済みで真実であるかに関するものです。
変更する一番の理由は必要性です。ただし、実際に変更する必要はないようです。あなたは「Army of One」であるため、強力な機能のほとんどはあなたの状況には当てはまりません。はい、人々はこれについて私と議論しますが、彼らはこの機能またはおそらくあなたが本当に必要としない機能をプッシュするでしょう. タイミングがすべてです。将来、ニーズが変化した場合は、ソリューションを変更してください。
問題領域 (この場合はソース管理) には、より優れた、または異なるソリューションが常に存在しますが、個人的な開発、プロセス/プラクティスの改善、および作業成果物の提供のバランスを取る必要があります。ソース管理のさまざまなソリューション/アプリケーションについてさらに学び、知識を広げて、ソリューションを切り替える時期を認識しながら、今のところ機能するものに固執することができます。
Subversionから (MarkMcB から) git に切り替える 3 つの理由を次に示します。
(完全な説明と、git と Subversion の両方で 3 つのことを行う方法の直接比較については、リンクされた記事をお読みください。)
私も個人的には Subversion を使い続けたいと思ってい ます。
Subversion は優れたバージョン管理システムであり、あなたはそれに満足しています。さらに詳しく調べたい場合は、継続的インテグレーションに関する情報を入手することをお勧めします。自動ビルドを作成するのに役立つツールがたくさんあります。ビルドの自己テストを行い、各コミットの整合性をチェックするなど...
Mercurial も考慮する価値があります。分岐ははるかに使いやすく、ネットワーク接続なしで機能します。SVN から Mercurial に移行するまで、作業をブランチに分割しようと真剣に試みたことはありませんでした。
私が本当に見逃しているのは、TortoiseSVN です。よく似た (TortoiseHg) がありますが、同じではありません。
とにかく、SVN リポジトリから Mercurial リポジトリを作成するのは簡単です...試してみて、自分に合っているかどうかを確認してください。
ルール番号 1: 「実行中のシステムを変更しない」
また、多くの輝かしい新しい解決策があるため (一人で作業しているため、抱えていない問題に対して)、新しい VCS に切り替えるコストを考慮する必要があります: Mercurial/git への subversion のインポートは簡単な作業ではありません
dumpformat を使用して svn リポジトリをインポートするツール (AFAIK) はありません。そのため、dumpformat を使用しない場合は、svn からすべてのブランチ/タグをチェックアウトし、手動で/スクリプトを介して git/BZR/Mercurial に追加することに固執します。
したがって、あなたのレポの大きさはわかりませんが (私のレポは 20 MB から 24 GB の範囲です)、レポ全体をチェックアウトするには長い時間がかかり、タグがたくさんある小さなプロジェクトでさえ、多くのハードディスクを使い果たします。スペース。
追加の問題は、移行が完了するまで作業を続行できないことです。
古いヤンキーのことわざがあります。
壊れていない場合は、修正しないでください。
私はあなたと同じように、最高のツールを手に入れるために絶え間ない調査を行っています。
私はSOLO作業のためにSVNを試しましたが、誰かがMercurial（hg）を勧めてくれました。今、私はそれについて基調講演をします。Windowsのgitよりもフレンドリーです。私は今、「なぜsvnはタグのような単純なタスクを複雑にするのか」と思います。SVNはタグが何であるかを知りません。SVNの場合、タグはコピーです。Mercurialでは、タグはリビジョンのエイリアスです。それはどれほど複雑でしょうか？
パフォーマンスそれは別の問題です。Mercurialでは、リポジトリはローカルマシンにあります。したがって、ログ、差分、または履歴に対しては非常に高速です。
オンラインバージョンのリポジトリでMercurialをサポートするサーバーについては何も知りませんが。
It's definitely worth looking into "distributed" VC even if you're not actually using a distributed workflow. Being able to have private branches and control over your local commits is worth the effort of learning git. I've been mainly using git-svn (with other team members using regular SVN clients, so we had a normal, centralized workflow), and it worked pretty flawless.
SVNがすべてのニーズに対応している場合、変更の理由はわかりません。好奇心が別のソース管理の探求の原動力である場合は、gitまたは他の分散scmソリューションについて読んで、切り替えるために投資する価値があるかどうかを判断することをお勧めします（これはあなたの状況ではないと思います）。