問題タブ [version-control]

dotnet プロジェクトのセットアップ方法の例はたくさんありますが、私たちの状況に合うものはありませんでした。

複数のアプリケーションと複数の依存関係を持つ 1 つのソリューションがあります。私たちは現在 SourceSafe を使用しており、Subversion に移行する予定ですが、ソースを正しい方法で編成するのが難しいと感じています。

• 解決例

  • アプリ1
  • アプリ2
  • ビジネスオブジェクト
  • データアクセス
  • カスタムコントロール

• 依存関係

  • BizObjects->DataAccess
  • App1->CustomControls
  • App1->BizObjects
  • App1->DataAccess
  • App2->CustomControls
  • App2->BizObjects

また、オペレーターが作業しているワークロードに応じて (データベースからのコピーを介して) 展開する構成管理システムもあります。バージョンでアプリケーションの「リリース」をマークし、そのリリースに複数のファイル依存関係を追加します。現在実施しているソリューションは、古い (Windows 3.1 で開発された) ソリューションを .NET ファイル/依存関係構造で動作させるための応急処置であることに注意してください。

App1 の場合、App1.exe、BizObjects.dll、DataAccess.dll、および CustomControls.dll があります。BizObjects が DataAccess を参照しているため、App2 にも同じ一連の依存関係がありますが、これは手動で定義されています。依存関係ツリーを識別するためのシステムが整っていません。

「リリース」の各依存関係は、ファイルとバージョン ID です。また、同じアプリケーションに、ワークロードごとに異なるバージョンの各ファイルを含めることができます。

1. 世界のどこで私たちは間違っていたのでしょうか? 私たちは間違っていましたか？
2. 展開要件に対応するために、svn ソース ツリーをどのように構築できますか?
   • また
3. セットアップに適した展開戦略をより適切にサポートするために、コードを再構築するにはどうすればよいでしょうか?

比較的単純な問題 (と思われる) に対して、古くて過度に設計されたソリューションがあります。誰かが私/私たちを正しい方向に導くことができますか?

編集:私はこの質問を読み、コードが通過しなければならない同じ開発/テスト/製品領域もあることに気付きました。

数人の同僚にAnkhSVNについて尋ねましたが、どちらも満足していませんでした。そのうちの 1 人は、AnkhSVN が自分の開発環境を何度か台無しにしたとまで言っていました。

AnkhSVN での経験はどうですか? IDE に統合されたソース管理ツールが本当に恋しいです。

ソース管理の初心者として学ぶのに最適なバージョン管理システムは何でしょうか？

現在、AnkhSVN を使用して Subversion を Visual Studio に統合しています。VisualSVN に切り替える必要がある理由はありますか?

AnkhSVN は (複数の意味で) 無料ですが、VisualSVN は 50 ドルかかります。したがって、VisualSVN の優れた機能が欠けていない限り、切り替える理由はありません。

あなたの職場環境は Harvest SCM を使用していますか? 私はこれを2つの異なる場所で使用しましたが、ぞっとするようなものです. ある状況では、CVS をローカルで使用できるように変換スクリプトを作成し、睡眠中に Harvest システムに変更を毎日インポートしました。プログラマーの 80% が別の何かを求めているにもかかわらず、同社は Harvest の使用に熱狂的でした。それは不必要に複雑で、遅く、重かった。私が働いている場所で Harvest が使用されていないことは、今では私の仕事の要件です。

以前にハーベストを使用したことがある人はいますか? あなたの経験は何ですか？私と同じくらい悪いですか？他の別の回避策を採用しましたか? この製品が現在も購入されているのはなぜですか?

私たちの開発ショップは現在、Visual SourceSafe を使用しています。私たちは皆、それがどのように (ひどい) 結末を迎えるかを知っているので、他のシステムを調査しています。まずはPerforceです。それを使用した経験があり、Visual Studio (2003/2005/2008) に統合した経験のある人はいますか? それは他のものと同じくらい優れていますか、それとも優れた機能を備えたかなり堅実ですか？

分散型バージョン管理 (別名、分散型リビジョン管理、分散型バージョン管理) を使用している人々と、それをどのように見つけているかについて聞きたいです。Mercurial、Darcs、Git、Bazaar の何を使用していますか? まだ使っていますか？過去にクライアント/サーバーの rcs を使用したことがある場合、それが優れている、劣っている、または単に異なると思いますか? 私が時流に乗るようになるとしたら、何を教えてもらえますか? または、そのことについては飛び降りて、ネガティブな経験をした人の話も聞きたいです。

現在、この質問の原動力となっている現在のソース管理システム (Subversion) の置き換えを検討しています。

マシンが同時にオンになっておらず、接続が非常に遅い他の国の同僚と一緒に使用したことがある人に特に興味があります.

分散バージョン管理とは何かがわからない場合は、次の記事を参照してください。

分散バージョン管理の概要

ウィキペディアのエントリ

多くの Mac アプリが「バンドル」を使用していることをご存知でしょう。アプリケーションからは 1 つのファイルのように見えますが、実際には多くのファイルが含まれるフォルダーです。

バージョン管理システムでこれを処理するには、次のことを行う必要があります。

• ディレクトリ内のすべてのファイルをチェックアウトして、アプリが必要に応じてファイルを変更できるようにします
• チェックイン時、
  • 変更されたコミットファイル
  • アプリケーションが作成した新しいファイルを追加する
  • もう存在しない削除済みファイルとしてマークします（アプリがそれらを削除したため）
  • これを 1 つのアトミックな変更として管理する

既存のバージョン管理システムでこれを処理する最善の方法についてのアイデアはありますか? この分野でより優れたバージョン管理システムはありますか?

最近、Subversion からバザーのような DVCS に切り替えることについて職場で議論しました。他の人の意見を聞きたいと思います。

私はそうすることへの抵抗を単純な類似点に結晶化することに成功しました。

バージョン管理は、よくも悪くも使用できます。

バージョン管理の「ライトサイド」は、変更を追跡するために使用する場合、何かを壊したときに古いバージョンに戻ることができる場合、および変更を公開して同僚が進行中の作業を見ることができる場合です。 .

バージョン管理の「暗い面」は、それを適切に使用せず、定期的にコミットして作業を「チェックポイント」せず、ローカル チェックアウトに多数の変更を保存し、変更を共有しない場合です。あなたがそれらを作るように他の人と。

転覆は、ライトサイドとダークサイドの両方を比較的難しくします。すべての基本は機能しますが、マージはまったく簡単ではないため、(タグ付けとリリースを超えて) Subversion でブランチを実際に使用する人はほとんどいません。Subversion 自体でのサポートはひどいもので、svnmerge のようなスクリプトで改善されていますが、それでもあまり良くありません。そのため、最近では、優れた分岐とマージのサポートが共同開発に必要であるとますます考えられているため、Subversion は一致しません。

一方で、「ダークサイド」を追うのもかなり大変です。ときどきローカルの変更をオンライン リポジトリにコミットせず、行ったことを覚えていない簡単な編集でコードを壊してしまうことで、一度噛まれるだけで済みます。そのため、定期的にコミットすることになり、人々はあなたが行っている作業を見ることができます。

したがって、最終的に Subversion は、ベスト プラクティスを実装するのは少し面倒ですが、物事を大きく間違えることを難しくする、中道の優れた VCS になります。

対照的に、DVCS を使用すると、完全にライト サイドまたはダーク サイドに移行するコストが大幅に低くなります。これらの最新の VCS システムを使用すると、分岐とマージがはるかに簡単になります。しかし、分散された側面により、自分のマシン上の一連のローカル ブランチで作業することが容易になり、作業のチェックポイントを設定するために必要な詳細なコミットが提供されます。おそらく変更を公開することなく、他の人が確認、レビュー、共同作業できるようにする必要があります。変更をローカル ブランチに保持し、公開しないという摩擦は、一般に、公開されているサーバー上のブランチで公開するよりも少なくなります。

簡単に言うと、ここで質問があります。職場の開発者に DVCS を提供した場合、彼らがそれを使用して「ライト サイド」に行き、変更を中央の場所で定期的に公開し、理解してもらうにはどうすればよいでしょうか。まだ共有したくない彼らの 1 週間のローカル ハックは、最初の機能が休暇中に他の開発者が機能を完成させるために使用できるものかもしれませんか?

DVCS のライト サイドとダーク サイドの両方に簡単にアクセスできる場合、どうすればそれらをダーク サイドから遠ざけることができますか?

ライブ Web サイトのバックアップとリビジョン管理を維持するための最適なソリューションは何ですか?

私の仕事の一環として、私はいくつかのライブ Web サイトを扱っています。ライブ フォルダーのバックアップを長期的に維持するための効率的な手段が必要です。さらに、これらのサイトを更新することは、特に何らかの理由でライブ環境で変更が発生した場合に苦痛になる可能性があります.

理想的なのは、手間のかからないソース管理です。しばらくの間、SVN を実装しました。これは、バックアップやリビジョン管理 (一時的な変更や重大な変更を簡単に元に戻す) などの半解決策として優れていました。

残念ながら、SVN はどこにでも .SVN 隠しディレクトリを配置し、特に他の開発者がフォルダー構造を変更したり、Web サイトのディレクトリをコピー/移動したりすると、問題が発生します。これは教育などの問題であるという議論を聞いたことがありますが、SVN のアプローチは私たちにとって実用的な解決策ではありません。

増分バックアップ ソリューションの方が優れているのではないかと考えています。

その他の可能性は次のとおりです。

1. 問題になるコマンドラインのみのSVK 。その上、これがどれほど適切かはわかりません。

2. Mercurial、おそらく分散コンポーネントを非表示にするためのトリガーがいくつかありますが、これはこの場合は必要なく、他の開発者にとって不必要に複雑になります。

   私は Mercurial で簡単に実験しましたが、リポジトリを分離し、ライブ フォルダの作業コピーと常に同期させる良い方法を見つけることができませんでした。おそらく、ソース管理ソリューション (リポジトリとライブ フォルダーを同じ場所にする) を別のバックアップ ソリューションと組み合わせると、これが進むべき道になる可能性があります。

   Mercurial の欠点の 1 つは、空のフォルダーをソース管理下に配置しないことです。これは、ファイルのアップロードなどのプレースホルダーの場所として空のフォルダーを使用することが多い Web サイトでは問題になります。

3. Rsync、実際には調査していません。

ライブ Web サイトのバックアップを維持するための最善の方法についてアドバイスをいただければ幸いです。理想的には、過去のバージョンをすばやく取得する簡単な方法を使用することです。

回答の返信:

• @キビー：

  • 教育というより、VSS 以外の知識がなく、他のことを学ぶ時間や労力が不足しています。

  • xcopy/7-zip のアプローチは理にかなっているように思えますが、すぐに多くのスペースを占有してしまうのではないでしょうか?

  • ソース管理に関しては、ソース管理に「これが現在のフォルダーの状態です。それを処理します。一致しない場合は、それはあなたのせいです」とだけ言ってほしいと思います。激しく失敗するよりも、新しい歴史を始めるだけです。

• @スティーブM：

  • ええ、それはそれを行うためのより良い方法ですが、大幅な文化的変化が必要になります. とは言っても、私はこのアプローチがとても好きです。

• @mk :

  • いいね、Rsync を使用して展開することは考えていませんでした。これは差分のみをアップロードしますか? 変更を行うたびにライブ ディレクトリ全体を上書きすると、サイトのダウンタイムが原因で問題が発生します。

もっと伝統的なオプションがあるかどうか、私はまだ興味があります