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

分散バージョン管理システム（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 

私の組織はSVNからGitへの移行を検討しています。移動に対する1つの議論は次のとおりです。 バージョン管理はどのように行いますか？ NetBeansプラットフォームに基づいたSDKディストリビューションがあります。SVNリビジョンは単純な番号であるため、それらを使用してプラグインとSDKビルドのバージョン番号を拡張できます。Gitに移行するとき、これをどのように処理しますか？ 可能な解決策： Hudsonのビルド番号を使用する（問題：Hudsonを確認して、実際のGitバージョンと関連付ける必要があります） 夜間および安定のためにバージョンを手動でアップグレードする（問題：学習曲線、ヒューマンエラー） 他の誰かが同様の問題に遭遇してそれを解決した場合、私たちはどのように聞いてみたいです。

131 version-control  git  svn  builds  versioning 

私は政府機関で働いています。ここで使用されている技術とソフトウェアの開発方法は非常に古いものです。 大量のストレージスペースがありますが、ここでの作業のほとんどを自動化するために使用されるアプリケーションを保持および維持するための適切なスペースはありません。 この機関では、GITやSVNなどのSCMソフトウェアを使用できません。 コードの品質を維持し、後でアプリに新しい機能を追加できるようにするための最良のアプローチは何でしょうか？ コードを壊さずに行った変更を記憶するにはどうすればよいですか？ 編集：私は言及するのを忘れました、彼らはそれぞれのコンピュータのためのネットワークドライブを持っています、そしてどういうわけかこれらのネットワークドライブは定期的にバックアップを作成または保存します。ただし、作業を保存し、既存のコードを壊さずに新しい機能を追加できるようにする独自の計画を作成しない場合、SCMソリューションに勝る大きな利点はありません。 編集：多くの人々がポータブルGitを提案したので、私はより多くの情報を追加する必要があります。Visual SVNサーバーをインストールしようとしましたが、インストールする管理者権限がないため失敗しました。また、通常のGitシェルをダウンロードしようとしましたが、ファイアウォールまたはネットワーク設定により、Gitダウンロードページにアクセスできませんでした。ポータブルGitをGmailであるメールに送信してみました。Googleはパッケージ内のexeファイルを検出しましたが、それでも仕事用コンピューターにポータブルGitバージョンをダウンロードできませんでした。もう1つ言及しなければならないのは、教育機関のコンピューターに適用されるネットワークポリシーでは、USBストレージデバイスの使用が許可されていないことです。USBポートを使用して、スマートフォンを充電したり、小型スピーカーなどの一部の機器に電力を供給したりできます。また、一部の人々が言及したように、インターネットさえ許可されていないコンピューターがあります。

110 git  code-quality  svn  scm 

私は、Subversionとgitの2つのバージョン管理システムを知っています。現在のところ、Subversionは私が唯一の開発者である個人プロジェクトに使用され、gitはオープンソースプロジェクトや、他の人もプロジェクトで作業すると信じているプロジェクトに使用されます。これは主に、gitの驚くべき分岐機能とマージ機能が原因です。誰もが自分のブランチで作業できます。とても便利な。 今、私は個人プロジェクトにSubversionを使用しています。gitはほとんど意味がないと思うからです。それは少しやり過ぎのようです。私が唯一の開発者であるときに（通常はホームサーバー上で）集中化されていれば問題ありません。とにかく定期的にバックアップを取ります。私は自分のブランチを作る能力を必要としません。メインブランチは私のブランチです。はい、SVNは分岐を簡単にサポートしますが、それより強力なサポートは意味がありません。マージはそれで苦痛になるか、少なくとも私の小さな経験からです。 個人的なプロジェクトでgitを使用する正当な理由はありますか、それとも単に過剰に過ぎますか？

84 tools  version-control  git  svn 

私はエッセイを書いていますが、いくつかの経験的証拠、おそらくこれらの技術の人気が数年にわたって比較される縦断的なデータを持ちたいと思います。 Git対SVNの人気を示す統計情報はありますか？

78 git  svn 

バージョン管理から削除する必要があるソースファイルの処理方法が悪い習慣と見なされるかどうかを知りたかったのです。 その例に基づいて説明します。 基本的にデッドコードであるプログラムのJavaクラスを退屈に整理しなければならなかったので、最近非常に怒った。もちろん、それらは削除する必要がありましたが、私はそのような冗長なものを削除する前に-奇妙なことを言うかもしれません-習慣があります： 私はSVN-> Deleteを介してそのような冗長ファイルをすぐに削除しません（選択したバージョン管理システムの削除コマンドに置き換えます）代わりにそれらのファイルにコメントを入れます（私は頭とフッターの両方を参照します）削除されます+私の名前+日付-さらに重要なこと- それらが削除された理由 次に、保存してバージョン管理にコミットします。次回プロジェクト内の何かをバージョン管理にコミット/チェックインする必要があるとき、SVN-> Deleteを押すと、最終的にバージョン管理で削除されます-もちろん、修正によって復元できます。そのため、この習慣を採用しました。 すぐに削除するのではなく、なぜこれを行うのですか？ 私の理由は、少なくともそれらの冗長ファイルが存在した最後のリビジョンに明示的なマーカーを持ちたい、なぜ削除するに値するのかということです。それらをすぐに削除すると、それらは削除されますが、削除された理由はどこにも文書化されていません。私はこのような典型的なシナリオを避けたい： 「うーん...なぜそれらのファイルが削除されたのですか？私は以前はうまく動いていました。」（「元に戻す」を押す->元に戻す人は永遠になくなるか、次の週に利用できなくなり、次の担当者は私のような退屈なファイルの内容を知る必要があります） しかし、コミットメッセージでそれらのファイルが削除された理由に注意しませんか？ もちろんやりますが、コミットメッセージが同僚によって読まれない場合があります。（私の場合は死んでいる）コードを理解しようとするときに、最初にバージョン管理ログと関連するすべてのコミットメッセージを確認するのは、典型的な状況ではありません。同僚はログをクロールする代わりに、このファイルが役に立たないことをすぐに確認できます。時間を節約でき、このファイルはおそらく復元された可能性が高いことを知っています（または、少なくとも問題が発生します）。

53 version-control  svn  evidence-based 

私はCVS-crazyとBugzilla-nutsのある場所で働いています。 各リリースには非常に多くのブランチがあるため、それらをカウントすることはできません。誰もが絶えず自動マージされています。 この仕事には流動性がありません。すべてがロックステップを感じます。簡単なことでも25ステップかかります。工場の生産ラインにいるようなものではありません。毎日自分で工場を立ち上げるようなものです。 状況の例： 単一のバグを修正するには、最初にクリーンで新しい仮想マシンを入手します。次に、Bugzillaレポートで説明されている別のブランチに基づいて、その単一のバグ修正用のブランチを作成します。マシンにブランチをインストールし、セットアップします。バグを修正します。私はそれをチェックインし、他の人がテストするためにマシンとマシンを残します。次に、バグ管理ソフトウェアにアクセスして、自分が何をしたかを説明し、すべての手順でテストケースを作成する必要があります。最終的に他の誰かがそれをリリースとマージします。 どんなに小さなバグであっても、これらすべてのことをしなければなりません。時々、人々は複数のバグの作業を結合しますが、私が言ったように、これはほとんど不可能であるほど多くのブランチがあります。 他の仕事では、バグを修正するだけです。私が持っていたすべてのジョブがそれを使用していますが、私はかろうじてさえ、SCMを使用して覚えている：他のすべての仕事で、彼らは何とかそれを守っているからです邪魔になりません。 プロセスが邪魔をして、それ自体で終わりになるポイントはありますか？それもエンジニアリングですか？

50 issue-tracking  workflows  svn 

プログラマがCVSよりもSVNを好む理由の1つは、前者がアトミックコミットを許可していることです。これは何を意味するのでしょうか ？

34 svn  versioning  cvs 

10人のアジャイル開発者のチームがあるとします。毎日、彼らはボードからタスクを選び、そのタスクに対していくつかの変更をコミットします（1日の終わりまでに）。すべての開発者は、トランクに対して直接チェックインします（Googleスタイル、すべてのコミットはリリース候補であり、機能の切り替えなどを使用します）。 SVNのような集中型CVSを使用している場合、1人がコミットするたびに、ビルドサーバーは変更を統合し、他の9人の開発者の作業に対してテストします。ビルドサーバーはほぼ1日中継続的に実行されます。 しかし、gitのようなDCVSを使用している場合、開発者はタスクを完了するまで待ってから、ローカルコミットをすべて中央リポジトリにプッシュすることができます。それらの変更は、一日の終わりまで統合されません。 このシナリオでは、SVNチームはより頻繁に継続的に統合し、gitチームよりもはるかに迅速に統合の問題を発見しています。 これは、DVCSが従来の集中型ツールよりも継続的なチームに適していないということですか？この遅延プッシュの問題をどのように回避しますか？

34 git  svn  continuous-integration  dvcs  branching 

私は、自分自身を含めて誰もソース管理を使用したことがない部署で働いています。 私はコンセプトをプッシュしようとしています。SVNの調査に少し時間を費やしました。いくつかの基本を学びました。コマンドラインおよびTortoiseから作成/更新/チェックアウト/コミットできます。私はタグ付けと分岐の方法を学び始めていますが、それでも分岐とトランクなどの間の競合については多くの混乱を覚えています。書籍/チュートリアルと試行錯誤からのすべて。 私がオンラインで読んだgitことから、知るほうが良いように思えますが、より複雑です。自分を圧倒したくありません。gitに移動する前にsvnをマスターし続ける必要がありますか、それともgitにジャンプする方が賢明でしょうか？ 両方のアプローチに賛否両論はありますか？

31 svn  git 

最近、分岐とマージとSCMについてのMSDNの記事に出くわしました：分岐とマージプライマー-Chris Birmele。 記事では、「ビッグバンマージ」はマージアンチパターンであると述べています。 Big Bang Merge —開発作業の最後までブランチのマージを延期し、すべてのブランチを同時にマージしようとします。 これは、私の会社が生産されているすべての開発ブランチで行っていることに非常に似ていることに気付きました。 私は非常に小さな会社で働いており、1人が最終審査とトランクマージの権限を持っています。5人の開発者（私を含む）がいて、それぞれに個別のタスク/バグ/プロジェクトが割り当てられ、それぞれ現在のトランク（subversion）から分岐し、分岐で開発作業を実行し、結果をテストし、ドキュメントを作成します。必要に応じて、他の開発者とピアレビューとフィードバックループを実行し、プロジェクト管理ソフトウェアでレビュー+マージのためにブランチを送信します。 トランクリポジトリの唯一の権限である私のボスは、ブランチのレビューのすべてを実際に可能な限りレビューを行う単一の時点まで延期し、一部のブランチは拡張/修正のためにスローバックされます。ブランチはすぐにトランクにマージされ、一部のブランチは競合などのためにスローバックされます。 10〜20のアクティブなブランチを最終レビューキューに入れてトランクにマージすることは珍しくありません。 また、2つのブランチが同じトランクから作成されたものの、同じコードを変更したため、最終レビューとマージの段階で競合を頻繁に解決する必要があります。通常、これを回避するには、トランクから分岐し直して変更を再適用し、競合を解決してから、レビューのために新しいブランチを送信します（poor mans rebase）。 私が持っているいくつかの直接的な質問は次のとおりです。 「ビッグバンマージ」と呼ばれる非常にアンチパターンを示していますか？ このマージプロセスの結果に見られる問題の一部はありますか？ 上司のボトルネックを増やすことなく、このマージプロセスを改善するにはどうすればよいですか？ 編集：私の上司がトランクリポジトリに対する彼のグリップを緩めるか、他の開発者がトランクにマージできるようにすることを疑います。彼の理由は定かではありませんが、私はこのトピックを取り上げるつもりはありません。なぜなら、それは以前に取り上げられており、かなり早く撃downされたからです。彼らは私たちを信じていないだけだと思いますが、とにかくすべてが追跡されているので意味がありません。 この状況に関する他の洞察は歓迎されます。

28 svn  anti-patterns  merging  scm 

私は間違った問題に焦点を合わせているのではないかと思うので、まず、私が思い描くかもしれない準最適な解決策を提示する前に、問題が何であるかを説明します。 現在の状況： 現在、私の同僚は、変更がプロジェクト全体に広がっている巨大な塊で、長い時間を経て初めてコードの変更をコミットします。かなり前のことですが、彼らはネットワーク共有に.zipアーカイブを置くだけだからです。それでも、マージは悪夢です-率直に言って、私はそれで十分でした。また、話したり説明したり、物beいをするのもうんざりです。これはやめなければならない-私なしで常に「悪者」である。 私の解決策： 問題に気づいていない、および/または問題に関心がないようであり、数日以上続く努力は期待できない...それを何時間も打って、subversionサーバーにそれをしてもらいたいしつこい。 私の質問： 私はここから離れたところにいるのでしょうか、それとも間違った問題を見ていますか？私は何かを見逃しているようで、問題を解決するツールを見ることで間違ったことを尋ねていると思います。 この問題を解決するツールを探しているべきですか、それともこれを修正するために何をすべきですか？

28 version-control  teamwork  svn 

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

28 git  svn  mercurial  dvcs  merging 

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

26 version-control  mercurial  dvcs  svn  git 

gitブランチモデルに関する多くのアドバイスを見てきましたが、最も一般的な意見は、masterブランチで直接変更を加えることは悪い考えだと思われます。 同僚の1人がmasterブランチ上で直接変更を行うことを非常に喜んでおり、いくつかの会話にもかかわらず、彼らはこれを変更する可能性は低いようです。 現時点では、マスターに直接取り組むのは悪い習慣である同僚を納得させることはできませんが、私は彼の働き方と矛盾することを理解し、いつ再訪する必要があるかを知りたいですこの問題。

25 version-control  git  svn  branching