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

SVNトランクにコミットされる前にコードをレビューする最良の方法は何ですか？私が考えているアイデアの1つは、開発者にコードをブランチにコミットさせ、ブランチのリビジョンをトランクにマージしながらコードを確認することです。これは良い習慣ですか？そうでない場合、トランクにコミットされる前にコードをレビューするために他に何ができますか？

14 version-control  code-reviews  svn 

この長い投稿については申し訳ありませんが、価値があると思います。 私は小さな.NETショップから始めたばかりで、私が働いていた他の場所とはかなり異なった動作をします。私の以前の職務とは異なり、ここで書かれたソフトウェアは複数の顧客を対象としており、すべての顧客がソフトウェアの最新リリースを同時に入手できるわけではありません。そのため、「現在の製品バージョン」はありません。顧客が更新プログラムを入手すると、最後の更新以降にソフトウェアに追加されたすべての機能も入手しますが、これはかなり前のことです。ソフトウェアは高度に設定可能であり、機能のオンとオフを切り替えることができます。いわゆる「機能切り替え」です。ここではリリースサイクルが非常に厳しく、実際にはスケジュールどおりではありません。機能が完了すると、ソフトウェアが関連する顧客に展開されます。 チームは昨年だけVisual Source SafeからTeam Foundation Serverに移行しました。問題は、VSSのようにTFSを使用し続け、単一のコードブランチでチェックアウトロックを強制することです。バグ修正がフィールドに公開されるたびに（単一の顧客であっても）、TFSにあるものをすべてビルドし、バグが修正されたことをテストして顧客に展開します！（私自身は製薬および医療機器のソフトウェアのバックグラウンドから来ており、これは信じられないほどです！）。その結果、テストが行​​われなくても、半分焼き付けられた開発コードが本番環境に入ります。バグは常にリリースビルドに滑り込んでいますが、多くの場合、ビルドを取得したばかりの顧客は、バグが含まれている機能を使用しない場合、これらのバグを見ることはありません。突然、いくつかの大きなクライアントが参加し、さらに小さなクライアントが参加しました。 バグのあるコードや未完成のコードのデプロイを排除するためにソース管理オプションを検討するように頼まれましたが、チームリリースのやや非同期な性質を犠牲にしないでください。私は自分のキャリアでVSS、TFS、SVN、Bazaarを使用しましたが、TFSは私の経験のほとんどがあった場所です。 以前、私が働いていたほとんどのチームは、1か月間、開発者が直接Devで作業し、その後変更をTest then Prodにマージするか、または「ではなく」固定サイクル。Cruise ControlまたはTeam Buildのいずれかを使用して、自動ビルドが使用されました。私の以前の仕事では、BazaarはSVNの上に座って使用されていました。開発者は独自の小さな機能ブランチで作業し、変更をSVN（TeamCityに関連付けられていました）にプッシュしました。これは、変更を簡単に分離し、他の人のブランチと共有するのが簡単だったという点で便利でした。 これらのモデルの両方には、コードがプッシュされる中央のdevおよびprod（および場合によってはテスト）ブランチがありました（そしてラベルはリリースが行われたprodのビルドをマークするために使用されました...そしてこれらはバグ修正のためにブランチにされました）リリースし、devにマージします）。これはここでの作業方法にはあまり適していませんが、さまざまな機能がいつリリースされるかは決まっておらず、完了するとプッシュされます。 この要件により、「継続的インテグレーション」アプローチが崩れます。継続的インテグレーションで新しい機能を使用するには、dev-test-prodを介してプッシュする必要があり、devで未完成の作業をキャプチャします。 これを克服するには、dev-test-prodブランチを持たない機能の多い分岐モデルを使用する必要があります。むしろ、開発作業が完了するとロック、テスト、修正、ロックされる一連の機能ブランチとしてソースが存在する必要があります、テストしてからリリースしました。他の機能ブランチは、必要な場合や必要な場合に他のブランチから変更を取得できるため、最終的にすべての変更が他のすべてのユーザーに吸収されます。これは、前回の仕事で経験した純粋なバザールモデルに非常に当てはまります。 これは柔軟に聞こえますが、開発用トランクやprodブランチがどこにもないのは奇妙に思えます。災害を統合... これについての人々の考えは何ですか？ 2番目の最後の質問：分散ソース管理の正確な定義について多少混乱しています：一部の人々は、TFSやSVNのような中央リポジトリがないことを示唆しているようです。 TFSには完全に機能するオフラインモードがあります）、他の人は、機能分岐と親子関係のないブランチ間のマージの容易さについてだと言います（TFSにはベースレスマージもあります！）おそらくこれは2番目の質問です！

13 svn  continuous-integration  team-foundation-server 

今日、GitHubでできる限り多くの時間を費やして（実際に仕事をしているチームの唯一の人でも）、実際の企業アプリケーションにどのようになるかを実際に感じています。 私が持っている1つの質問は、バージョンを制御することです。プロジェクトを始めたとしましょう。次に、チームメンバーはいくつかのブランチを作成し、そこで開発しました。本番の準備ができたら、すべてのブランチをmasterブランチにマージしました。最後に、versionでライブを開始し1.0ます。 現在、そのバージョン1.0は公開されており、そのバージョンのソフトウェアに関していくつかの問題が報告されています。1.1プロジェクトを急いで導入した問題を修正するために、バージョンの開発を開始したいと思います。 さて、質問はこれです： ここでバージョニングをどのように制御する必要がありますか？ 新しいブランチを作成し、そこにソフトウェアv1.0のバージョン1.0を保持し、いくつかのブランチで開発する（またはしない）場合、それらをマージしmaster、バージョンを公開する必要があり1.1ますか？ そのような状況に慣習はありますか？

13 project-management  git  github  svn 

職場ではSVNを使用していますが、名前のみです。分岐もマージもしません。リポジトリの2つのコピーを保持します。1つは展開の際にコピーされ、バグ修正のために保持される「タグ」ブランチとして機能します。一方のコピーで行われた変更をもう一方のコピー（「トランク」）にコピーすることを忘れないでください。リポジトリ内の単一のフォルダー内に、プロジェクトを分割するのではなく、12個のプロジェクトがあります。要するに、SVNを使用するのはコミットできることだけです。他のすべては手動で行われます。 Mercurialを評価しています。私は過去にGitを使用しました（DVCSを使用したのはチームで1人だけです）。Mercurialをすぐに使用しています。ブランチは簡単で、マージははるかに簡単で、ローカルに心のこもった内容をコミットして中央にプッシュするだけなので、物事を行う「より良い方法」としてMercurialをチームの他のメンバーに紹介することを議論しています準備ができたら分岐します。SVNのすべての利点が得られます（そして、SVNを本当に理解していないので、今のところ多くの利点が得られません）。また、新しい機能については、バージョン管理されていないファイルがたくさんあります。失敗した。ワークフローは少し単純に思えます-「コミット」はローカルであり、「プッシュ」はSVNのコミットに似ていることを覚えておく必要があります。 これは取るべき良いアプローチですか？チームは非常に柔軟であり、仕事の質を向上させ、物事を簡単にする方法を提供することを心に留めておいてください。CIOは、SVNを使用していない可能性について述べたときに私に尋ねましたより良いものがありますか？」彼も一緒に乗っています。

13 version-control  svn  mercurial 

私は経営陣にリファクタリングへの努力を投資するよう説得するための議論を探しています。 Jiraを使用して作業を記録し、すべてのsvn-commitをjira呼び出しに関連付けます。 私のアイデアは次のことです。 実装が非常に悪いが頻繁に使用されるコードの領域を手動で見つけます。User-POVとDeveloper-POVの両方（バグ修正） JIRA-Issuesを含むsvn-commitsを取得します いくつかの基準（問題の種類、バージョン、優先順位など）に従って問題をフィルタリングします。 これらのバグに費やされた時間/努力を計算する リファクタリングの労力とリスクを推定する 数字を提示し、それを修正する努力を求めます。 これについてどう思いますか？そのような測定は有用であり、説得力があるでしょうか？長所と短所は何ですか？

13 svn  project-management  jira  measurement 

通常、プログラムを作成するときは、明確なタスクが先にありますが、迷惑なものを見つけて、進行中にクリーンアップしたいと思います。 ここには3つのオプションがあります。 後で実行します（チケットを追加するのを忘れたり、時間を費やす必要がある場合があります） 今すぐ実行し、現在の作業と一緒にコミットします（不明） 今すぐ実行し、個別にコミットします（それを見つける必要があり、間違いを犯し、意図せずにオプション2に進む可能性があります） これはおそらくかなり基本的なことですが、svn / git / otherを使用してこれを回避する方法は何ですか？

12 version-control  git  svn  workflows 

私の理解から、SVNは「簡単に分岐できます。マージが難しい」。何故ですか？マージ方法に違いはありますか？

12 git  svn  mercurial  dvcs 

SVNを使用しています。時々、コミットメッセージを書くときに何かを見逃します。しかし、いったんコミットされると、元に戻すことはできず、メッセージを編集することさえできません。なぜ彼らはそこに編集機能を入れなかったのですか？

12 version-control  svn 

ソース管理リポジトリでレビュー済みのソースコードを管理する最良の方法は何ですか？ソースコードはチェックインされる前にレビュープロセスを経るべきですか、それともコードがコミットされた後にコードレビューが行われるべきですか？コードがリポジトリにチェックインされた後にレビューが発生した場合、どのように追跡する必要がありますか？

12 version-control  code-reviews  svn 

私はSVNを使い始めましたが、DVCSツールと比較してSVNでのマージは非常に難しいと多くのソースが言っています。最新の質問私はSEにここに見つけることができる2012年からです。 時々、v1.5より前のSVNにはメタデータがなかったが、SVNは現在バージョン1.8.9であるという理由が言及されています。 SVNがv1.5よりもはるかに成熟していることを考えると、特にSVN 1.5を使用しなかったため、前述のメタデータの欠如に悩まされていないという事実を考えると、SVN に対するこれらの議論にはまだ多くの妥当性がありますか？ DVCSには完全に異なるアプローチがあり、それがより望ましい場合が多いことを理解していますが、何らかの理由でSVNを「必要」とする人にとって、マージはもはや「地獄」ではありませんか？

11 version-control  svn  merging 

質問 SVNを運用展開に使用しない正当な理由がありますか、それとも単に個人的な好みのケースであり、SVNに対する実際のケースはありませんか？ バックグラウンド 私の職場には、SVNでリリースにタグを付けてから、それらのリリースをさまざまなWebサーバーに直接デプロイするsvn coかsvn switch、本番環境に直接組み込むという文化があります。 ビルドおよびデプロイスクリプトまたは何らかのフォームまたは自動デプロイを使用しないと、ドキュメント化されていないため統合環境設定が失われると考えているため、個人的にこれに問題があります。しかし、それ以上に、見過ごされていること、そのheadい頭をまだ育てていないことをすることには隠れた危険があるかもしれないという直感を持っています。 私は、さまざまな環境（ステージング、プリプロダクション、プロダクション）などにコードをデプロイする責任がある運用スタッフに懸念を提起しました。 編集： ビルドとデプロイの意味： たとえば、開発者が特定の環境にweb.config設定を追加する必要がある場合。通常、Web.configはsvnに保持されないため、これらのファイルは、自動ビルドスクリプトの形式なしで手動で更新されます。そのため、それらが失われたり、OPSがリリースのweb.configにフィールドを追加するのを忘れると、問題が発生します。 XMLPokeを使用して特定の環境に適したweb.configを自動的に生成するというビルドスクリプトは、各環境に必要なすべての変更を文書化するバージョン管理可能なスクリプトがあるという点で理想的です。 現在のビルドおよびデプロイ方法 問題のプロジェクトの場合、開発者は手動でリリースをビルドしますが、他のプロジェクトではビルド手順がNANTまたはMSBuildで自動化されています。 ほとんどのプロジェクトのデータベース移行は、DBスクリプト、移行スクリプト（Migrator.NET）、またはCMSパッケージを介して行われます。 CIは通常、チェックインごとにTeam Cityによって行われます。すべてのチケットはブランチで行われ、トランクにチェックインする前に検証と正確性/品質についてピアレビューされるコードレビュープロセスがあります（うまく機能します）。 ただし、実際のコードの展開は、タグ付きリリースのチェックアウトまたはより一般的にはSVNスイッチのいずれかを介して、ほとんど常にSVNを介して行われます。これは、リポジトリをデプロイプロセスの一部として使用しているという点で奇妙に思えます。 通常、構成はあまり頻繁に変更されず、構成ファイルに含まれるのは環境固有の情報のみです。それ以外はすべてデータベースにあります。 これがうまくいくと誤解しないでください。ただし、自動化されたビルドとデプロイを試してみてください。これをRailsとCapistranoで使用し、Cygwin、Nant、SSHを使用した個人プロジェクトにも使用しました。 さらに重要なことは、自動化されたビルドとデプロイを使用するように同僚を変更するには、非常に具体的な有効な引数が必要だということです。 それとも、SVNを使用して本番環境にデプロイすることに対して実際に有効な引数はありませんか？

11 web-development  svn  deployment 

私の職場のチームは、VCSとしてSubversionを使用して新しいプロジェクトを開始しています（この質問の目的のために、これは固いものと考えることができます）。私たちはまだプロジェクトの初期段階にあり、分岐モデルについて合意しようとしています。以前のプロジェクトは非標準バージョンモデルに基づいていたため、既存のリリースのホットフィックスとパッチを管理するときに問題が発生しました。 さまざまな分岐モデルがかなり複雑であることがわかりましたが、私がかなり明確に理解しているモデルの1つはgit flowです。Subversionでこれのバリエーションを実装するのがどれほど難しい/望ましくないか知りたいです。明らかに、ブランチで協力している人々の点でいくつかの違いがあります。機能ブランチはローカルリポジトリに限定するのではなく一元化する必要がありますが、モデルの他の概念は、私が理解しているようにSubversionで再現可能でなければなりません。 このアプローチの欠点または課題は何でしょうか。私が聞いたのは、SVNではGitに比べて「マージは高価です」ということです。しかし、これが実際に何を意味するのか、それがブランチモデルのようなgitフローを使用する能力にどのように影響するのかについては、完全には明らかではありません。 このアプローチの最大の懸念は何でしょう。Subversionでより自然な同様の明確なアプローチはありますか？

10 svn  branching  gitflow 

商用アプリケーションの新しいバージョン（バージョン4）で作業を開始しようとしています。私はSubversionを使用しています。 あなたの経験、間違い、成功に基づいて、Subversionで新しいバージョンをセットアップすることをどのようにすすめますか？ ここにいくつかの情報があります：バージョン4がリリースされてからしばらくの間、バージョン3の重要な更新をリリースし続けるつもりです。ただし、新機能の開発はすべてバージョン4でのみ行われます。 関連性がある場合：私はこの製品のソロ開発者です。 編集：私はSVNのタグとブランチを知っています。私が必要としているのは、私の状況でタグとブランチを使用するための最適な戦略だと思います。

10 version-control  svn 

Subversionで1つのブランチのみを処理する場合、気にする必要がありますか？トランクで作業を高速化することはできませんか？ これは、Subversionで開発する方法です。 トランクあり 新しい開発ブランチを作る そのブランチで新しい機能を開発します 機能が完了すると、トランクにマージされ、ブランチが削除され、トランクから新しい開発ブランチが作成されます プロダクションにリリースしたいときは、トランクからタグを作ります。バグ修正は、そのタグからのブランチで行われます。このバグ修正はトランクにマージされます。 これが、機能の完了後に新しい開発ブランチを作成する理由です。このようにして、バグ修正はすぐに新しいコードに含まれます。 以下は明確にする必要がある図です： これは、これが最も効率的な作業方法ではないという感じがあります。コミットする前にローカルでビルドします。これには5〜10分かかります。これはかなり長い待ち時間として経験されていることを理解できます。 開発ブランチの考え方は、トランクは常にリリースの準備ができているということです。しかし、これは私たちの状況ではもう当てはまりません。場合によっては、機能の準備がほぼ整っており、一部の開発者は既に次の機能のコーディングを開始します（そうでない場合、1人または2人の開発者が完了してマージするのを待っています）。 次に、機能1が完了すると、トランクにマージされますが、機能2の一部のコミットが含まれています。 では、ブランチは1つしかないので、開発ブランチを気にする必要がありますか？私はトランクベースの開発と抽象化による分岐について読んでいますが、ほとんどの記事は抽象化による分岐の部分に焦点を当てています。数回のリリースにまたがる大きな変更の印象を受けました。これは私たちが抱えている問題ではありません。 どう思いますか？トランクで作業できますか？最悪のシナリオは（私が思うに）トランクからタグを作成し、必要なコミットをチェリーピックする必要があるということです（一部のコミット/機能はまだ本番稼働の準備ができていないため）。

10 svn  branching  tagging 

私たちは小さなISVショップであり、通常、毎月新しいバージョンの製品を出荷しています。コードリポジトリとしてSubversionを、IDEとしてVisual Studio 2010を使用しています。多くの人々がMercurialやその他の分散ソース管理システムを主張していることは承知していますが、現時点では、これらのメリットをどのように享受できるかわかりませんが、私は間違っているかもしれません。 私たちの主な問題は、ブランチとメイントランクを同期させる方法です。 これが今日のやり方です。 新しいバージョンをリリース（Subversionでタグを自動的に作成） 来月リリースされるメイントランクの作業を続けます そしてこのサイクルは毎月繰り返され、完璧に機能します。この問題は、緊急のサービスリリースをリリースする必要がある場合に発生します。メイントランクから解放することはできません（2）。開発中のため、緊急に解放するのに十分な安定性がないためです。 このような場合、次のことを行います。 手順（1）で作成したタグからブランチを作成します バグ修正 テストとリリース 変更をメイントランクにプッシュします（該当する場合）。 私たちの最大の問題は、これら2つをマージすることです（ブランチとメイン）。ほとんどの場合、次の理由により、自動マージに依存できません。 メイントランクに多くの変更が加えられました 複雑なファイル（Visual Studio XMLファイルなど）のマージがうまく機能しない 別の開発者/チームが理解できない変更を加えたため、マージできない したがって、これら2つの異なるバージョン（ブランチとメイン）を同期させるためのベストプラクティスは、あなたが考えることです。職業はなんですか？

10 .net  visual-studio-2010  svn