タグ付けされた質問 「mercurial」

分散バージョン管理システム（DVCS）の利点を理解しようとしています。 Subversion Re-educationとMartin Fowlerによるこの記事は非常に有用であることがわかりました。 Mercurialおよびその他のDVCSは、変更セットとローカルコミットを使用してコードを処理する新しい方法を促進します。それは地獄と他のコラボレーションの問題をマージすることを防ぎます 私は継続的な統合を実践しているので、これに影響されることはありません。プライベートブランチで単独で作業することは、実験しない限りオプションではありません。メジャーバージョンごとにブランチを使用し、トランクからマージされたバグを修正します。 Mercurialを使用すると、副官を持つことができます これはLinuxのような非常に大規模なプロジェクトに役立つ可能性があることは理解していますが、小規模で高度に協力的なチーム（5〜7人）には価値がありません。 Mercurialはより高速で、ディスクスペースが少なくて済み、完全なローカルコピーにより、ログと差分の操作がより高速になります。 私が取り組んでいる非常に大規模なプロジェクトであっても、SVNの速度やスペースの問題に気づかなかったので、私もこれには関心がありません。 元SVNオタクからの個人的な経験や意見を求めています。特に、変更セットの概念と、測定した全体的なパフォーマンスの向上に関して。 更新（1月12日）：今、試してみる価値があると確信しています。 更新（6月12日）：Mercurialにキスし、気に入った。彼の桜の地元のコミットメントの味。試しにMercurialにキスしました。SVNサーバーがそれを気にしないことを願っています。それはとても間違っていた。とてもいい感じがしました。今夜恋しているわけじゃない。 最終更新（7月29日）：Eric Controlの次の例であるVersion Control by Exampleをレビューする特権がありました。彼は私を納得させました。Mercurialに行きます。

300 version-control  git  mercurial  dvcs  svn 

比較を見ると、機能セット間に1対1のマッピングが存在する可能性があるように思われます。しかし、よく引用される声明は、「Mercurialの方が簡単だ」というものです。この声明の根拠は何ですか？（もしあれば）

204 git  mercurial 

近年、Gitをめぐる誇大宣伝が大いに盛り上がりました。誰もがGitについて知っていますが、代替案については誰も知りません。 Mercurialのような他のものは見過ごされているようです。どちらも2005年にリリースされ、同様の機能を提供します。さらに、Mercurialは一般に使いやすく、より直感的で、長い間UIが優れていると考えられています。したがって、これは、特に分散バージョン管理が初めての人にとって、人気のある代替手段であると想定できます。しかし、かなり成功したGitとは異なり、ほとんどの人には知られていないようです。 この投稿のポイントは、この現象をよりよく理解しようとすることです。 どうしてGitはケーキのすべての部分を手に入れたのですか？彼らはどういうわけかより良いマーケティングを使用しましたか？それは、そのコミュニティがもっと... ahem ...「verbose」だからでしょうか？「Linus」の名前のせいですか？それはそのオタク的なイメージのためですか？ あなたの意見は何ですか？

124 version-control  git  mercurial 

GitとMercurialの比較1を読んだほぼすべての記事では、MercurialのコマンドラインUXの方が優れているようです（各コマンドは（sayとは異なりgit checkout）1つのアイデアに限定されています）。 しかし、ある時点でGitは突然非常に人気が高くなり、Debianポプコングラフ（下のグラフ画像を参照）でGitの提出者の数が文字通り爆発しました。 ソース：Debian 2010-01年に起こったことは、物事が突然変化したことです。GitHubは2008年よりも早く設立されたようです。

86 git  history  mercurial 

2012年です！MercurialとGitは両方ともまだ強力です。 私は両方のトレードオフを理解しています。また、誰もが何らかの好みを持っていることを理解しています。それはいいです。 両方の使用レベルに関する情報を探しています。例えば、上のstackoverflow.com、探しGitのは、あなたに12000本のヒットを取得し、Mercurialはあなたを取得3000 Googleトレンドでは、それは1.9だと言う：Gitのための1.0。 両方のツールの相対的な使用を推定するために、他にどのような経験的情報が利用できますか？

37 git  mercurial 

以前はgitを使用していましたが、Pythonに貢献したいので、今では水銀を学ぶ必要があり、非常にイライラします。 そこで、私はいくつかの小さなパッチを作成し、それらをローカルのMercurialリポジトリでコミットとして追跡したいと考えました。どうやら水銀の分岐を処理する4つの方法があります。1と4は完全にばかげているように見え、名前付きブランチはヘビーウェイトのようで、1コミットの迅速な修正のためにそれらを使用することになっていないので、ブックマークを使用しました。 今、私のパッチは拒否され、ブックマークブランチの1つをリポジトリから削除したいと思います。OK、gitではブランチを強制削除して忘れてしまうので、ブックマークを削除すると次の問題が発生します。 TortoiseHGは、hg logコミットとdefaultブランチに2つのヘッドがあることを示しています。そして、私が正しく理解していれば、追加のプラグインなしでhgのコミットを削除することはできません。 Mercurialにはハッシュだけでなく、リビジョン番号もあります。いくつかのコミットを追加したので、それ以降にプルされたすべてのコミットには、メインの中央リポジトリとは異なるリビジョン番号が付けられています。 ブックマークをhg update引っ張ってmaster最新のコミットに自動的に移動した後、実行しますが、TortoiseHGでそれを行う方法が見つかりませんでした。 何が間違っていますか？これは正常で予想されるもので、これらの問題を無視する必要がありますか？または、ブランチでどのように作業するのですか？

32 git  mercurial  dvcs  branching 

私が取り組んでいるプロジェクトを1つではなく2つのリポジトリに分割することが理にかなっているかどうかを知りたいです。 私が言えることから： フロントエンドはhtml + jsで記述されます .netのバックエンド バックエンドはフロントエンドに依存せず、フロントエンドはバックエンドに依存しません フロントエンドは、バックエンドに実装された安らかなAPIを使用します。 フロントエンドは、任意の静的httpサーバーでホストできます。 現在、リポジトリは次の構造を持っています。 ルート： フロントエンド/* バックエンド/ * 両方のプロジェクトを同じリポジトリに保持するのは間違いだと思います。両方のプロジェクトは相互に依存関係を持たないため、個々のリポジトリと、必要に応じてサブモジュールを持つ親リポジトリに属する​​必要があります。 私はそれは無意味であり、それを行うことで利益を得ることはないと言われました。 私の議論のいくつかを以下に示します。 相互に依存しない2つのモジュールがあります。 長期的に両方のプロジェクトのソース履歴があると事態が複雑になる可能性があります（探しているバグとはまったく関係のないコミットの半分がある間にフロントエンドで何かを探してみてください） 競合とマージ（これは起こらないはずですが、誰かがバックエンドにプッシュすると、他の開発者がバックエンドの変更をプルしてフロントエンドの変更をプッシュすることになります。） 1人の開発者はバックエンドでのみ作業するかもしれませんが、常にフロントエンドを引っ張る必要があります。 長い目で見れば、いつ配備するのか。何らかの方法で、フロントエンドを複数の静的サーバーにデプロイし、バックエンドサーバーを1つ持つことができます。いずれの場合も、バックエンド全体を複製するか、すべてのサーバーにフロントエンドのみをプッシュするか、バックエンドを削除するカスタムスクリプトを作成する必要があります。1つだけが必要な場合は、両方よりもフロントエンドまたはバックエンドのみをプッシュ/プルする方が簡単です。 反論（1人が両方のプロジェクトで作業する可能性があります）、サブモジュールで3番目のレポを作成し、それで開発します。履歴は個々のモジュールに分けられており、バックエンド/フロントエンドのバージョンが同期して実際に連携するタグをいつでも作成できます。フロントエンドとバックエンドの両方を1つのリポジトリにまとめても、それらが連携して機能するわけではありません。両方の履歴を1つの大きなレポにマージしているだけです。 サブモジュールとしてフロントエンド/バックエンドを使用すると、プロジェクトにフリーランサーを追加する場合に物事が簡単になります。場合によっては、コードベースへの完全なアクセス権を実際に与えたくないことがあります。「外部者」が表示/編集できるものを制限したい場合、1つの大きなモジュールがあると事態が難しくなります。 バグの紹介とバグの修正のために、フロントエンドに新しいバグを挿入しました。その後、誰かがバックエンドのバグを修正します。1つのリポジトリで、新しいバグの前にロールバックすると、バックエンドもロールバックされ、修正が困難になる可能性があります。フロントエンドのバグを修正しながらバックエンドを動作させるには、別のフォルダにバックエンドをクローンする必要があります...その後、物事を再マージしようとします... 1つのリポジトリのHEADを移動するので、2つのリポジトリを作成するのは簡単です他を変更しないでください。また、異なるバージョンのバックエンドに対するテストは簡単です。 誰かが私を説得するためにもっと議論をすることができますか、少なくともプロジェクトを2つのサブモジュールに分けるのが無意味な（より複雑な）理由を教えてください。プロジェクトは新しく、コードベースは数日前のものなので、修正するのに早すぎません。

30 project-management  version-control  git  mercurial  organization 

可能性のある重複： 私はSubversionオタクですが、なぜMercurial、Git、またはその他のDVCSを検討する必要があるのですか？ 時々、誰かが分散バージョン管理（Git、HG）は集中管理（SVNなど）よりも優れていると言うのを耳にします。SVNではマージが困難で苦痛だからです。実は、SVNでのマージに問題はなかったし、実際のSVNユーザーによるものではなく、DVCS支持者による主張だけを聞いたことがあるので、TVでの不快なコマーシャルを思い出す傾向があるあなたがすでに持っていてうまく動作するものは使用するのが信じられないほど難しいとふりをすることによって、あなたが必要のないものをあなたに売ろうとします。 そして、常に発生するユースケースはブランチを再マージすることです。これは、これらのストローマン製品の広告を思い出させます。自分が何をしているのかわかっているなら、そもそもブランチを再マージするべきではありません（また、その必要はありません）。（もちろん、根本的に間違っていて愚かなことをしているときは難しいです！） だから、ばかげたストローマンのユースケースを割り引いて、DVCSシステムでのマージよりも本質的に難しいSVNマージには何がありますか？

28 git  svn  mercurial  dvcs  merging 

私はMercurialのマントラ1に常に同意していましたが、Mercurialがリベース拡張機能にバンドルされ、gitで一般的なプラクティスであるため、本当に「悪いプラクティス」と見なされるかどうかは疑問です。使用を避けるのに十分なほど悪い。いずれにせよ、プッシュ後のリベースが危険であることは承知しています。 OTOH、私は5つのコミットを1つにパッケージ化して見栄えを良くすることを目指しています（特に本番ブランチで）が、個人的にはいくつかの機能の一部のコミットを見ることができる方が良いと思いますたとえ気の利いたものでなくても、実験は行われますが、「Xでやってみましたが、結局Yほど最適ではありません。ZをベースとしてZを行う」のようなものを見ると、勉強している人にとっては価値がありますコードベースを作成し、開発者の一連の思考に従ってください。 私の非常に意見のある（馬鹿げた、内臓、偏った）視点は、プログラマーがミスを隠すためにリベースを好むということです... ですから、私の質問は次のとおりです。実際にそのような「有機コミット」（つまり、改ざんされていない履歴）を実際に使用する価値があると思いましたか？どちらを選んでも、なぜそれがあなたのために働くのですか？（履歴を保持するために他のチームメンバーを使用するか、代わりに履歴を変更します） 1あたりGoogleのDVCS分析は、のMercurialに「歴史は聖なるです」。

26 git  mercurial  dvcs 

git / mercurial / bazzrシステムが集中システム（subversion、perforce）よりも優れている理由を検索しましたが、ビジネス上の理由は見つかりませんでした。 DVCSを非技術者に販売しようとした場合、DVCS が利益を上げるためにどのような議論を提供しますか。 私はまもなくマネージャーにgitを売り込みます。subversionリポジトリーの変換には少し時間がかかり、smartgitライセンスの購入にはいくらかの費用がかかります。 編集私はこの質問を集中型と分散型の一般的な議論にしようとしましたが、必然的にgit vs subversionに変わりました。確かに、転覆よりも優れた集中システムがあります。

26 version-control  mercurial  dvcs  svn  git 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 5年前に閉鎖されました。 ちょっとした文脈：私は大学3年生です。学生は4人のチームに分かれています。ほとんどの人はWindowsで作業しています（Linuxを使用している私のような少数の人を除く）。学校のカリキュラムの一環として、まもなく本物のクライアント向けのプロジェクトに取り掛かりますが、私と別のチームは、コードを相互に共有するのにどの方法が最適か疑問に思っています。 私は3年間パートタイムで働いており、さまざまなプロジェクトでgitとmercurialの両方を使用した経験が豊富なので、どちらのシステムを使用しても問題はありません。しかし、私のチームメートは誰もバージョン管理システムを使用したことがありません。SVNを使用しようとしたが、大きな問題があり、他の何かを試してみたいと思う別のチームもいるので、彼らは私の意見を求めました。 私の考え：Mercurial + TortoiseHgはWindowsの下でより良く統合されていると聞いたことがありますが、匿名の頭の概念が説明しても混乱させるのではないかと思っています。一方で、初心者にとってはgitブランチの方が理解しやすい（各プログラマーの作業が明確に分離されている）が、Windowsではうまく機能しないことがわかりました。

25 version-control  git  mercurial 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私はSubversionオタクだということを読んだので、なぜMercurialやGitまたはその他のDVCSを検討すべきか、検討すべきではないのか。 関連するフォローアップの質問があります。私はその質問を読み、推奨されるリンクとビデオを読んで、その利点を見ましたが、人々が話している全体的なマインドシフトは見ていません。 私たちのチームは、60のプロジェクトで構成される1つの大きなコードベースで作業する8〜10人の開発者です。Subversionを使用し、メイントランクを持っています。開発者が新しいFogbugzケースを開始すると、svnブランチが作成され、ブランチ上で作業が行われ、完了したらトランクにマージされます。場合によっては、ブランチに長時間滞在し、トランクにブランチをマージして変更を反映することがあります。 Linusがブランチを作成し、二度とブランチを作成しないことについて話すのを見たとき、それはまったく私たちではありません。おそらく週に50〜100のブランチを問題なく作成します。最大の課題はマージですが、私たちもそれをうまく得ています。ブランチのルート全体ではなく、fogbugz case＆checkinでマージする傾向があります。 リモートで作業することも、ブランチからブランチを作成することもありません。コードベースのそのセクションで作業しているのがあなただけなら、トランクへのマージはスムーズに進みます。他の誰かがコードの同じセクションを変更した場合、マージが面倒になり、手術が必要になる場合があります。競合は競合です。コードを理解できるほど賢くなければ、ほとんどの場合、どのシステムでもそれを正しく実現できるとは思いません。 ブランチを作成した後、以下の60k +ファイルのチェックアウトには時間がかかりますが、これは使用するソース管理システムの問題です。 DVCSには、私たちにとって大きな助けになるとは思えない利点がありますか？

22 git  svn  mercurial  dvcs 

この記事「成功したGit分岐モデル」は、経験豊富なDVCSユーザーの間で非常によく知られていると思います。 私はhg主に使用しますが、この議論はどのDVCSでも問題ないと主張します。 現在のワークフローは、各開発者がマスターリポジトリのクローンを作成することです。独自のローカルリポジトリにコードを記述し、テストを実行し、すべてがうまくいけばマスターにプッシュします。 そこで、JenkinsのようなCIサーバーをセットアップし、将来のプロビジョニングシステム（シェフ、パペット、アンシブルなど）でワークフローを改善したいと考えています。 実部 さて、上記のモデルはうまく機能しますが、ブランチはCIを壊す可能性があります。機能ブランチは、developmentCIとマージをスムーズにするために、オリジンと同期する必要があります（記事によると、ブランチになります）。 アリスとボブが2つの機能に取り組んでいると言います。しかし、アリスは翌日に行われます。ボブの機能には1週間かかります。Bobが完了するまでに、彼の変更は古くなっています（おそらく、Aliceは一部のクラスをリファクタリング/名前変更しています）。 1つの解決策は、毎朝、開発者がプルmaster/originして、変更があるかどうかを確認する必要があることです。Aliceがコミットした場合、Bobは自分のワークスペースにプルしてマージし、機能ブランチが最新になるようにします。 これは良い方法ですか？ これらのブランチは（ローカルクローンではなく）マスターリポジトリに存在する必要がありますか？つまり、すべての開発者がGitHub / Bitbucketのマスターリポジトリにコミット権限を与えて、新しいブランチを作成できるようにする必要がありますか？または、これはローカルで行われますか？ 最後に、記事が提示するモデルは、ブランチがと同期していない場合、CIを破壊する必要がありorigin/masterます。ナイトリービルドを実行したいので、開発者は仕事を離れる前にプルしてマージし、各機能ブランチでもCIを実行する必要がありますか？

18 git  continuous-integration  mercurial  dvcs  branching 

通常はPerforceとSmartBearのCode CollaboratorをBig Corp使用していましたが、特定のプロジェクトではMercurialを使用する予定です。 Code CollaboratorはMercurial（バージョン5を使用しています）をサポートしており、コードレビューの最適な時間（サーバーへのコミット/プッシュ中）プロセスが最適な時間であるかどうかを判断しようとしています。 ありがとう

18 code-reviews  mercurial 

私は、分散バージョン管理のタオで自分自身を再教育するのに苦労している別のSubversionユーザーです。 Subversionを使用するとき、私はプロジェクトマイナーアプローチの大ファンであり、以前の雇用主のほとんどと一緒にリポジトリブランチを構築しました。次のようなタグとトランク： branches-+ +-personal-+ | +-alice-+ | | +-shinyNewFeature | | +-AUTOMATED-+ | | +-shinyNewFeature | +-bob-+ | +-AUTOMATED-+ | +-bespokeCustomerProject +-project-+ +-shinyNewFeature +-fixStinkyBug tags-+ +-m20110401_releaseCandidate_0_1 +-m20110505_release_0_1 +-m20110602_milestone trunk 実際のソースツリー内では、次のような構造（のようなもの）を使用します。 (src)-+ +-developmentAutomation-+ | +-testAutomation | +-deploymentAutomation | +-docGeneration | +-staticAnalysis | +-systemTest | +-performanceMeasurement | +-configurationManagement | +-utilities +-libraries-+ | …

16 mercurial  organization  continuous-integration  svn  configuration-management