Subversionを超えたバージョン管理システムを検討すべきですか？
https://stackoverflow.com/questions/224396
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
昨年、私は転覆に夢中になりました。私は唯一の開発者であり、自分のプロジェクトのいくつかにも取り組んでいます。 SVNを使用すると、すべてを非常に簡単に管理できます。また、HTTPSを介してオンラインサーバーでホストされているため、どこからでもコードにアクセスできます。また、本番/開発サーバーにコードを展開するのにも最適です。
私のポイントは、必要なことをすべて実行し、失敗したことはないということです。
もっと良いものはありますか？私の生活を楽にするために使用できる別の製品の機能が不足していますか？私は常に最高のソフトウェアを使用することを心がけており、新しいテクノロジーへの移行に問題はありません。
GITについて聞いたことがありますが、いくつかの研究を行っています。私はそれを試してみるつもりですが、それをいじりながら、「業界標準」と見なされる別のソース管理システムがあります。そして、彼らはSVNよりも良いことをしますか？
解決
Git、Mercurial、およびBazaarは分散制御システムであり、常にネットに接続しているわけではなく、リポジトリの中央バージョンが1つである必要はないという考えで動作します。
飛行機に乗ってコミットできないなど、「飛行機モード」と呼ばれることもある多くの独立した仕事をしている場合は、Bazaarを見てください。 GitやMercurialよりも順応しやすいことがわかりました。
あなたが常にネットに接続した仕事をしていて、あなたが唯一の開発者なら、おそらくSubversionを使い続けることができます。
また、 Subversionでホームディレクトリを保持するの値を考慮してください。
他のヒント
Mercurial
私は主にCVSとSVNを使用しましたが、満足していて、DSVCについて多くの騒ぎがあったので、分散ソース管理の研究を始めました。 DSVCを使用した後、開発スタイルの変更に気付き、より流動的で順応性のあるものになりました。トランクまたは実験ブランチに問題なくマージできるようにします。
- Mercurialは、頭を悩ますことなく、ワンマンバンドから巨大なOpenJDKまで拡張できます。
- Mercurialは高速で、GITほど高速ではないかもしれませんが、それでも非常に高速です
- Mercurial Queuesは、パッチを管理する素晴らしい方法です。グリースを塗った照明の速度で。
- 異なるOSで実行できます。Pythonに基づいているため、互換性が優れています。
- 学習曲線はGITよりも低く、いくつかのドキュメントを読んだ後、基本的な事柄を理解します（ http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ ）
- hgを使用すると（多くのDSVCを実行できます）、hg-svnおよびhgsubversionを使用して企業のSVNソース管理とインターフェイスできます。
- また、SSH経由でプッシュおよびプルを実行するHTTPサーバーをセットアップすることもできます
- また、コーディング仲間と一緒に、HTTPサーバーを起動してローカルホスト上で実行するだけで、コードスプリントを実行している間に仲間がプッシュおよびプルすることができます。
- このHTTPページからプロジェクトの現在のステータスを確認することもできます。
- 最後に、単純なコマンドの簡単な説明を参照してください（ http：// edong.net/2008v1/docs/dongwoo-Hg-PDF.pdf ）
Git
- 試してみましたが、svnのサポートは水銀よりも優れています。しかし、hgsubversionは稼働しており、git svnの競争相手になっています。
Gitはクールですが、ソースコードのデポを常に維持して再パックする必要があります。 多くのbashスクリプトで構成されているため、Windowsでの実行に問題があります。 しかし、それは非常に高速であり、多くの機能を使用できます。実際、機能の量は不利な場合があります。
BZR
- 試したことがない
HGで始めてから振り返ったhavnt
個人的にはSubversionにとどまります。専門的な観点から見ると、SubversionがGITと比較されているかどうかを尋ねる（そして知る）仕事が増えています。また、Subversionの巨大なコミュニティは言うまでもなく、Subversionを中心に構築されたオープンソースとフリーウェアのツールがたくさんあります。
ソース管理は、常に最新かつ最高のものであるとは限りませんが、多くの場合、試行された真実についてです。
変更する最良の理由は必要性です。ただし、実際に変更する必要はないようです。あなたは「一軍隊」ですそのため、ほとんどの強力な機能は状況に当てはまりません。はい、人々はこれについて私と議論しますが、彼らはこの機能またはあなたが本当に必要としない可能性が高い機能をプッシュします。タイミングがすべてです。将来、ニーズが変わってからソリューションが変わる場合。
問題空間、この場合はソース管理には常により良いまたは異なるソリューションがありますが、個人の開発、プロセス/プラクティスの改善、作業成果物の提供のバランスを取る必要があります。ソース管理用のさまざまなソリューション/アプリケーションについてさらに学習し、ソリューションを切り替える時期を認識するために知識を拡張し、今のところ有効なものに固執することができます。
3つの理由Subversionからgitに切り替える（MarkMcBから）：
- 無限、簡単、非ファイルシステムベースのローカルブランチ
- 一時的な作業を保管する
- 公開前の共同作業
（gitとSubversionの両方で3つのことを行う方法の完全な説明と直接比較については、リンクされた記事を読んでください。）
私も個人的にSubversionにとどまりますが、 もっと良いものはありますか？
Subversionは優れたバージョン管理システムであり、満足しているので、さらに調べたい場合は、継続的インテグレーションには、自動ビルドの作成、ビルドのセルフテスト、各コミットの整合性のチェックなどに役立つツールが数多くあります。 ..
Mercurialも検討する価値があります。分岐は非常に使いやすく、ネットワークに接続しなくても機能します。 SVNからMercurialに移行するまで、真剣に作業をブランチに分割しようとしませんでした。
私が真剣に見逃しているのはTortoiseSVNです。似たようなもの（TortoiseHg）がありますが、それは同じではありません。
とにかく、SVNからMercurialリポジトリを作成するのは簡単です...試してみて、自分に合っているかどうかを確認してください。
ルール番号1：＆quot;実行中のシステムを変更しないでください＆quot;
また、多くの光沢のある新しい解決策があるので（あなたが抱えていない問題に対して、あなたが一人で作業しているので）、新しいVCSに切り替えるコストを考慮する必要があります。 SubversionのMercurial / gitへのインポートは簡単なタスクではありません
dumpformatを使用してsvnリポジトリをインポートするツール（AFAIK）はありません。したがって、dumpformatを使用しない場合は、svnからすべてのブランチ/タグをチェックアウトし、git / BZR / Mercurialに手動で/スクリプト経由で追加することに固執します
レポジトリの大きさはわかりません（私のレポジトリは20 MBから24GBまで）多くのタグは多くのハードディスク容量を使い果たします。
追加の問題は、移行が完了するまで作業を続行できないことです。
最高のツールを手に入れるための絶え間ない調査の問題については、あなたと同じです。
SOLOでSVNを試したところ、誰かがMercurial（hg）を勧めてくれました。今、私はそれについて基調講演をしています。 Windowsのgitよりも使いやすいです。 「タグのような単純なタスクでsvnが複雑になるのはなぜ」と思うようになりました。 SVNはタグが何であるかを知りません。 SVNの場合、タグはコピーです。 Mercurialでは、タグはリビジョンのエイリアスです。どれほど複雑なのでしょうか？
パフォーマンスは別の問題です。 Mercurialのレポでは、ローカルマシンにあります。そのため、ログ、差分、または履歴に対して非常に高速です。
レポのオンラインバージョンのMercurialをサポートするサーバーについては何も知りませんが。
SVNがすべてのニーズに対応している場合、変更の理由はわかりません。 好奇心が異なるソース管理の探求のドライバーである場合、私はgitまたは他の分散scmソリューションについて読んで、切り替えるために投資する価値があるかどうかを理解することをお勧めします（これはあなたの状況にあると疑います）。
古いヤンキーのことわざがあります。
破損していない場合は、修正しないでください。
「分散」を検討する価値は間違いありません。実際に分散ワークフローを使用していない場合でも、VC。プライベートブランチを持ち、ローカルコミットを制御できることは、gitを学ぶ努力の価値があります。私は主にgit-svnを使用しています（他のチームメンバーは通常のSVNクライアントを使用しているため、通常の集中化されたワークフローがありました）。
