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

私は私たちのウェブサイトプロジェクトをバージョン管理するためのより良い方法を考えています。私はフロントエンドの開発者にすぎないので、VCSに関する深い知識はありません。 ワークフローは変化しており、過去のバージョン管理の習慣は時代遅れになっています。主な問題は、各Webサイトにフロントエンドファイルの2つの配列があることです。 開発環境（少ないファイル、非圧縮のjs、イメージなど）。「不正な」ビルド環境（すべて圧縮され、人間が読み取れないもの）。 ただし、ソースファイルを含むWebサイトを販売することはできません。まあ、それは完全に正しくないと感じています。 2つのリポジトリを持つソリューションがあります。1つはビルド、1つは開発で、gulpがビルドファイルをビルドディレクトリに送信します。しかし、それを維持するのは面倒であり、小さな会社では、それはそれほど素晴らしいとは思いません。それは多くのレポを作成し、人々はいくつかのレポで、時には1つのsvnレポでさえも管理しなければならず、問題が発生します。 したがって、同じsvn内のソースファイルとprodファイルの1つのリポジトリを持つソリューションもあります。ただし、Webサイトがローカルの開発サーバーから本番サーバーに移動するときに、ソースファイルを削除する必要があります（そのため、単一のリポジトリには、その場所、開発または本番に基づいて異なるファイルがあります）。私が聞いたことから、それは良くありません バージョン管理システムに関して、不適切なフロントエンドワークフローを管理する正しい方法は何ですか？

9 web-development  version-control  development-process  svn  front-end 

私は初心者の開発者であり、プロジェクトのニーズを満たすために、GITやSubversionなどの専門的なツール（これらのツールについて十分に理解していません）をどのように使用するのか、最初から疑問に思っていました。彼らがそれを使用する場合、どのようにそのようなものを設定しますか？ 私のアプリケーションはそれほど大きくなく、まだチームで作業していません。それらは私にとって非常に役立ちますか？ このサイトにはツールの使用方法に関する質問がありますが、初心者のサポートが必要です。

9 version-control  git  svn 

仮定して： チームは一元化されたバージョン管理を使用しています。 完了までに数日かかる大きな機能に取り組んでいますが、ビルドが中断するため、それより前にコミットすることはできません。 チームメンバーは、作業中のファイルの一部を変更する可能性がある何かを毎日コミットします。 これは一元化されたバージョン管理であるため、ある時点でローカルチェックアウトを更新する必要があります：新しい機能をコミットする直前に少なくとも1回。 コミットの直前に1回だけ更新すると、チームメイトによる他の多くの変更が原因で多くの競合が発生する可能性があり、一度にすべてを解決するのは苦痛の世界になる可能性があります。 または、頻繁に更新することもできますが、毎日解決する競合がいくつかあるとしても、少しずつ簡単に解決できるはずです。 頻繁に更新することを常にお勧めしますか？

9 svn  version-control  cvcs 

バックグラウンド 私はgit過去にVCS（主に）を使用して多くの既存のプロジェクトを管理してきましたが、うまく機能します。通常、既存のプロジェクトでは、全体的な機能を最適化または変更するコードを変更するたびにチェックインします（変更するすべての行ではなく、適切な手順で私が意味することを知っています）。 問題 私があまり練習していないことの1つは、新しいプロジェクトを作成することです。私はおそらく非常に大きく成長する自分自身の新しいプロジェクトを開始する過程でんだけど、私はそこにあることを発見していますたくさん行うと、最初の数日/時間/週/期間までに変更する多くの製品が実際に最も基本的な形で機能するまで。 既存のプロジェクトの場合と同様に、プロセスの各ステップでチェックするポイントはありますか？まだ機能していないので、私は自分が加えた変更でプロジェクトを中断していません。現時点では、毎日の終わりにコンピュータを離れるとき、単にVCSをバックアップとして使用しています。 私の最初の数回のコミットは、「基本的なディレクトリ構造」や「作成されたDBテーブル」のようなものでした。新しいプロジェクトを開始するときにVCSをどのように使用すればよいですか？

9 git  svn  mercurial  version-control 

私は最近、SVNまたはGITを使用したさまざまなWebアプリケーションのデプロイメントプロセスについて、多くの記事を読んでいます。 アジャイルの多くのフレーバーの方法と同様に、マスターまたはトランクにコミットしたものはすべて本番環境で使用できると想定されています。GitHubとEtsyの両方（http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/）は、これらはこれに基づいて機能すると述べています（ただし、Etsyには実際にはステージング環境があります）。 このプロセスは、すべての単体テストとCIテストが実行されていることを前提としています。ローカルおよびCIでテストを実行し、トランクにコミットします。SO、この時点であなたのコードは技術的に健全です。 あなたのコードは技術的には正しいかもしれませんが、ユーザー/機能テストは、特にフロントエンドテストに関して、より多くのバグを発掘するかもしれません。 私の質問はこれです。QAおよびビジネスオーナーは、実装した機能の変更をどこでテストしますか？トランクにコミットする前のローカルの開発マシン、またはQA /ステージングマシンで？ トランクから実行されるステージングマシンがあり、トランクにコミットされたすべてのコードが本番環境で使用できると想定している場合...ええと、どの時点で、コードはサインオフされ、技術とビジネスの両方から本番環境に移行するのに適しています。視点？ステージングマシンが1つだけで、多くの開発者がいて、そこにコードがQAされる場合、多くの開発者の変更がサインオフを待機している可能性があるため、トランクからどのように展開できますか。 他の人がこれにどのように取り組んだか聞いてみたいと思いますか？

9 git  unit-testing  svn  testing  deployment 

24時間体制で、会社のバージョン管理の戦略を考えてみます。現在はSVNを使用していますが、構造はありません-基本的にトランクしかなく、それにコミットするだけです。最近、開発マネージャーが「タグ」として機能する2番目のリポジトリーを開始しましたが、同じリポジトリーの一部ではなく、完全に別のリポジトリーであるため、「トランク」と手動でマージする必要があります。実際には、「Dev」と呼ばれるフォルダーが1つだけあります（実際には「Dev」フォルダーは日付によって異なりますが、「Dev」だけがメインのフォルダーです）。他のすべてのプロジェクト。プロジェクトごとに構成されているわけではなく、ブランチ/タグ/トランクなどの概念はありません。最初に設定した人（長い間、もちろん）SVNをセットアップする方法をまったく知らないようで、それ以来、何かを壊すことを恐れて適切に行う方法を学ぶことに誰も悩まされていません。CIは使用していません（残念ながら自動テストも行っていません）。 まず、プロジェクトごとに分離する必要がありますか？たとえば、2つのASP.NET Webサイト（Webアプリケーション、Webサイトではない）、Webサービス、すべてのテーブルスクリプトとストアドプロシージャの展開フォルダー、外部プロジェクト用の2つのコマンドラインクライアントWebサイトと、共通のビジネスオブジェクトなどを含む共有フォルダー。これらはそれぞれブランチ/タグ/トランクの設定を備えた独自のプロジェクトであるか、または次のようである必要があります。 dev/ branches/ tags/ trunk/ Site1/ Site2/ WebService/ SharedCode/ すべてのブランチがあり、すべてにDevフォルダー全体のコピーがありますか？共有コードライブラリと少なくとも1つ（通常は両方）のWebサイトにも変更を加える必要がある状況がよくあるため、このアプローチは飲み込みやすいかもしれません。 次に、開発サーバーとライブサーバーへの定期的なリリース（用語では "プッシュ"）を行います。私がこれを処理する最良の方法を読んだことから、すべての開発はtrunk /に行き、ブランチは「一時的」であり、トランクに影響を与える可能性のある新しい機能を追加するために使用され、タグはリリース用です？それで、毎月プッシュしてみましょう、そして私は真新しいモジュールに取り組んでいます。トランクを分岐し、その分岐をコードに使用して、コードの記述とテストなどを行います。モジュールが完成したら、トランクにマージして（おそらくブランチを削除して）、デプロイの準備ができたら、タグを付けます（「May2011」としましょう）。公開後にバグ修正がある場合は、May2011タグで修正され、トランクにマージされます（トランクも修正されます）。そして、May2011は修正により再び押し出されますか？これはタグ付けの意図ですか？

9 version-control  svn 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 9年前休業。 Visual Source SafeからSVNに移行してから数年しか経っていません。そして、私にとってのSVNはまだ「WOW！たくさんのことができます！SVNはとてもクールです！」 しかし、私の周りの多くの人々は、「SVN？本当に？私は...」と言い続けます。 そしてそれらの多くが私が心配しているほどたくさんあります。私のチームをGit / Mercurialまたは他の素晴らしいものに移動する必要がありますか？私はばかげているように聞こえますが、明白な答えは「あなたのために働くものにとどまる」でしょう。SVNは私のために機能します...しかし、リポジトリに新しいプロジェクトを作成するたびに、私は自分自身に尋ね続けます-これが移動する時でしたか？ それで... SVNは本当にそんなに悪いのですか？それに固執することで大きなチャンスを逃しませんか？

9 git  svn 

私は現在、私の会社でsvnからgitへの切り替えの過程にあります（1年後に、人々を説得するために費やしました！）。 これまでのところ、これですべてが良くなりますが、私たちが現在ワークフローに持っている小さなものの1つで、私には適切な同等のものを見つけることができません。 現在、すべての開発者はマスターで作業しています。四半期ごとに、マスターをXxブランチにブランチします。Xxブランチは後で最新のリリースになります。これは、svnリポジトリが次のようになることを意味します。 トランク 枝 3.8 4.1 4.2 ... 実際にはタグを使用しません。 時々、発見された緊急のバグ修正があります。 私たちがそれを行う現在の方法は次のとおりです。 マスターで修正する SVNは、関連するコミットの範囲を関連するブランチにマージします（おそらく、最新のリリースなど）。 私たちは宇宙産業にいるので、支社は長命であり、顧客のアップグレードプロセスはかなり長いので、これまでのところ、そのように取り組んできました。 さて、gitでどのようにして良い同等物でしょうか？ これまでのところ、マスターから生成されたブランチのバグを修正してから、このブランチをマスターと4.3にマージしました（たとえば）。ことは、ホットフィックスブランチにはマスター履歴が含まれており、マスターと4.3の間のすべてのコミットもマージされるためですが、これは不要です。 これまでに考えたこと： 私は非常に成功したGitワークフローメソッドを見てきましたが、それらの解決策は、リリースブランチのバグを修正して、逆にマージするのではなく、マージすることです。これは私たちのケースではうまくいくかもしれませんが、実際にバグを修正する前に、バグを修正したい最も古いブランチをすでに知っている必要があるため、かなり面倒です。 もう1つの解決策は、マスターで修正してからコミットを選択することです（今日のsvnマージの場合と同様）。ここでの厄介なことは、この場合、チェリーピックが新しいコミットのように見え、関係が失われるため、マージされたものの履歴がどこで失われるかということです。 それを行うための「良い」方法は何ですか？履歴のコミットを修正するか、チェリーピックを使用して、マージされたものや他の何かを手動で追跡する必要がありますか？ gitでの制作経験がほとんどない場合、私は何かを見逃している可能性があります。

9 git  svn  branching 

SVNバージョン管理システムを作成した善良な人々は、「スキップデルタ」と呼ばれる構造を使用して、ファイルの変更履歴を内部に保存します。リビジョンは、以前のリビジョンに対するデルタとして保存されます。ただし、次のように、リビジョンNは必ずしもリビジョンN-1に対するデルタとして格納されるわけではありません。 0 <- 1 <- 2 <- 3 <- 4 <- 5 <- 6 <- 7 <- 8 <- 9 代わりに、リビジョンNはNf（N）に対するデルタとして格納されます。ここで、f（N）はNを分割する2の最大の累乗です。 0 <- 1 2 <- 3 4 <- 5 6 <- 7 0 <------ 2 4 <------ 6 0 <---------------- 4 0 <------------------------------------ 8 <- 9 （表面的にはスキップリストのように見えますが、実際にはそれほど似ていません。たとえば、スキップデルタはリストの真ん中に挿入をサポートすることに関心がありません。）詳細については、こちらを参照してください。 私の質問は次のとおりです。他のシステムはスキップデルタを使用しますか？SVNの前に既知/使用/公開されたデルタをスキップしましたか、それともSVNの作成者がそれを自分で作成しましたか？

8 data-structures  svn 

私は最大5人の（ウェブ）開発者がいる小さなチームで働いています。私たちのチームは頻繁に成長しており、複数の人が同じコードで作業しているときに問題が発生したため、VCSをセットアップすることにしました。 現在の状況 現在、中央開発サーバー（LAMP）を使用しています。したがって、すべての開発者が同じコードベースで作業し、コードがテストされてライブサーバーの準備ができている場合は、ftp経由でコードをコピーするだけです。私はこれがanno 1600ワークフローの一種であることを知っていますが、そうです。それが何であるか、そしてこの質問の理由でもあります。 開発サーバーでは、ディレクトリ構造は次のようになります。 /var/www /Project1 /Project2 /Project3 ... さらに、いくつかの小さな非Webアプリケーション-Android / iPhone / Windows 8などのアプリといくつかのC＃ツールもあり、これらもVCSに含める必要があります。 目標と問題 私たちの目標は、VCSのクリーンセットアップを取得することです。VCSは、問題追跡ソフトウェアと連携し、コードを上書きせずに同じプロジェクトで同時に作業できるようにし、バージョン管理の利点を提供します。 私たちにとっての最初の質問は、どのテクノロジーを使うべきかということだと思います。私たちの一部は、すでに転覆を経験しています。しかし、gitはある種の「標準」になり、多くの「プロgit」の議論がWebユーザーの間で存在するため、私たちはgitを使用する傾向があります。 不確実性が始まります。git-分散型VCS-を使用する場合、各開発者のコ​​ンピューターで別個の開発サーバーの使用を開始する必要があるようです。それに関する問題は次のとおりです。 ときどき別のコンピューターで作業するため、コードのプッシュを忘れると問題が発生します。 開発サーバーはライブサーバーと同じである必要があるため、仮想マシンで作業する必要があります（これは私たちの環境では強制できないため、不可能だと信じています）。 開発サーバーは通常、「トライアウト」または「プレゼンテーション」サーバーとしても機能し、開発者以外の人が何が起こっているのかを確認できました。 単一の（！）開発サーバーを使用しながらシステムから利益を得ることができるように、gitで別の可能なセットアップはありますか？たぶん、開発者ごとに異なるディレクトリがあります。または、作業中のファイルをロックし、リポジトリにコミットして、同じコードベースで作業することはできますか？それが私たちにとっての要因になった一方で、複数の開発者がアプリケーションの同じ部分で同時に作業することはまだ珍しいと言うことが重要かもしれません。

8 web-development  version-control  git  svn 

ジョエル・スポルスキーの水銀の紹介を読んでいたとき、それは私を襲った： 「そして今、彼らがしていることは次のとおりです。各新機能は大きな#ifdefブロックにあります。そのため、1つのトランクで機能できますが、デバッグされるまで新しいコードが表示されることはありません。正直なところ、それはばかげています。」 なぜこれはとにかくばかげているのですか？これは、他に何もないにしても、単純に処理するのが簡単ではないですか？それは派手なことではありませんが、トリックを行います-少なくともあなたがすでにSubversionと「結婚」している場合。 欠点は何ですか？私は議論を理解していません。

8 svn  mercurial  branching 

私は小さなユーティリティ用の一般的なリポジトリを持っています（それは当時、自分のリポジトリを保証するには小さすぎると考えられていました。「それ自体の別の問題」かもしれません）。しかし、私が働く1つのルールは、何も捨てないことです。SVNから削除するということは、実際には削除されないということです。履歴のどこかにあるだけですが、古いものをもう一度見つける必要がある場合に備えて、それはまだ危険な場合があります。 非推奨のアイテムを維持するだけでなく、それらを邪魔にならないようにするための最善の戦略は何でしょうか？

8 svn 

私は最近、TortoiseSVNを使用してこれに遭遇しましたが、CVSベースのプログラムでも同じだと思います（正しいですか？）。 純粋な好奇心から、CVSファイルシステムで大文字と小文字が区別される理由はありますか？つまり、次のURLは異なります。 svn://repo/branches/PROJECT svn://repo/branches/project これにはレガシーな理由がありますか？それはファイルベースでより興味深くなります。ディレクトリに2つのファイルが存在する場合、たとえばProjectOne.vbpとと言いprojectone.vbpます。一方は通常のWindowsファイルシステムで他方を上書きします（または、私が遭遇したように、不可解なTortoiseSVNデータベースエラーをスローします）が、リポジトリに平和的に共存できます。 上記のようなばかげた命名を使用しないことはユーザー次第であることは明らかですが、大文字と小文字を区別することに欠けている利点はありますか？

8 version-control  svn  file-systems 

Androidマーケットプレイスに有料アプリケーションを持っていますが、無料の広告サポートバージョンをリリースしたいと考えています。 私がこれを行うと思った最も簡単な方法は、広告を追加するための追加のコードを含むsubversionリポジトリーにブランチをセットアップすることでした。ただし、これをAndroidマーケットプレイスに送信しようとすると、一意のパッケージ名が必要になります。すべてのクラスファイルのパッケージを変更する必要があるため、トランクとブランチのマージが非常に面倒になるため、このソリューションはもはや機能しません。 これら2つのプロジェクトを一緒に保ち、パッチを共有しながら、異なるパッケージを使用する最良の方法は何ですか？

8 version-control  android  svn 

PHPサイトのSVNリポジトリがあり、最後のプログラマーはソース管理を適切に使用していません。その結果、私がここで作業を開始してからのコードのみがリポジトリにあります。 「バックアップ」としてファイルに保存された完全なコードベースの古いコピーがたくさんありますが、それらはソース管理されていません。ほとんどのコピーが保存された理由がわかりません。また、バージョン番号にタグを付ける合理的な方法もありません。私が行うすべてのバックアップが適切なファイルシステムのタイムスタンプを持って、バックアップが行われた日付を持っています。 関連するフレームワークとデータベースドライバーのアップグレードにより、古いコードは完全に機能しなくなります。現在のサーバー構成では機能しません。ただし、以前のプログラマーには独自のロジックがあったため、私は完全に古いコピーがないので、彼らが何をしていたのかを参照することはできません。 バージョン管理でこれを保持する必要がありますか？どうやって？古いコードを別のタグ/ブランチに分けますか？

8 version-control  svn