1

長年、私は簡単な方法でプログラミングを行ってきました。言語とプロジェクト別に整理されたディレクトリにソースファイルを保存し、ときどき手動バックアップを作成します。賢い場合は、新しいバージョンを試す前にコピーを作成します。 ; それはほとんどそれです。

最近、リビジョン管理の使用を開始することにしました。たくさんの記事やページを調べて、かなりの数の異なるものを試した後、私は最終的にSubversionに落ち着きました（BASEのためにプロジェクトのサイズが2倍になったとしても）。


私は今、有用な情報を見つけることができないように思われるいくつかの側面についていくつかのアドバイスが必要です。まず、RCSを使用する基本的なプロセスが正しいことを確認しています。

  1. すべてのプロジェクトをSVNリポジトリにインポートします
  2. オリジナルを削除する
  3. リポジトリからプロジェクトをチェックアウトする
  4. それに取り組みます
  5. コミットする

それでおしまい？では、新しいプロジェクトはどうですか？フォルダに新しいプロジェクトを作成してからインポートする必要がありますか？


ディレクトリ構造にも問題がありますが、最初に、セットアップをレイアウトする必要があります。私は自宅のマシンで作業している単一の開発者です。データディレクトリには、次のようなレイアウトがあります。

  X：\ Data
      \ H
        \ 3rdParty
          \ Graphics
        \コントロール
          \ ThisControl
          \ ThatControl
        \ライブラリ
        \クラス
          \ CFoo
          \ CBar
      \ VC
        \大
          \ CoolApp
            \ res
        \小さい
          \ CoolerApp
            \ res
            \ misc
        \テスト
          \ CFooTest

…等々。

IDEのインクルードパスに、頻繁に使用するヘッダーディレクトリがいくつかあります（たとえば、 3rdParty \ Graphics、Classes \ CFooなど）。以前は依存関係に問題がありましたが、RCSを使用すると、さらに悪化します。たとえば、CoolAppにはThisControlとCFooが含まれる場合があります。以前は、 CoolAppの作業中にCFooを変更して壊した場合、CoolerAppのようにCFooを使用する他のアプリも壊れてしまうため、これは理想的とは言えませんでした。

CFooらをコピーする代わりにこのようにした理由。al。CoolAppや他のディレクトリへのアクセスは、各コピーからの更新を\Hフォルダのメインコピーにマージしようとする手間が原因です。

正式なRCSを使えば、このような問題は解消されると思いました。ただし、プロジェクトを\ VC \ CoolAppなどからSVNリポジトリにインポートすると、 CFoo、* Libraries \ **などのコンポーネントは外部ディレクトリにあるため、含まれません。したがって、バージョン管理されていないため、ポイント全体が無効になります。

このような状況に対処するためのヒントを探しています。たとえば、\ HにCWidgetがあり、 \ VCにWidgetTest （ CWidgetを含むテストコンテナ）がある場合、 WidgetTestとCWidgetの両方がバージョン管理されるように構造化すると同時に、可能な限り単純化する方法を教えてください。 CWidgetを使用して最新バージョンを含めて使用する他のアプリはありますか？


また、すべてのプロジェクトを同じリポジトリディレクトリにインポートすることしかできず、Big \、Small \、Test\などの構造が失われました。それを維持するためにSubversionを取得することはできません。


最後に、元のプロジェクトディレクトリはどうなりますか？リポジトリにインポートすると削除できるという記事を少なくとも1つ見ました。もしそうなら、私はおそらくそれらを圧縮して片付けます。



ああ、私は現在、ApacheサーバーでSubversionをセットアップしており、VisualSVN、SVNServe、およびCollabNetSVNサーバーをインストールしています。私はそれぞれを動作させるようになりましたが、必要なのは1つだけだと確信しているので、どちらを使用するかについてアドバイスをお願いします。



どうもありがとうございます。

4

2 に答える 2

2

オンラインで無料のsubversionブックには、いくつかの推奨リポジトリ構成が記載されています。

http://svnbook.red-bean.com/

このページは、さらに読むための良いリンクを提供します：

http://svnbook.red-bean.com/en/1.5/svn.tour.importing.html#svn.tour.importing.layout

SVNの非常に優れた点の1つは、CVSには当てはまらないことですが、ディレクトリ内を移動するのは非常に簡単です。ですから、バットの「最終的な」組織を考え出すようにプレッシャーを感じないでください。うまくいくことをして、もっと好きになるまで構造で遊んでください。

言及する価値のあるもう1つのことは、SVNはデータにコピーオンライト技術を使用することです。したがって、必要に応じて、ディレクトリ全体の「svncp」コピーを自由に作成してください。

于 2009-06-12T23:23:22.140 に答える
2

さて、私はあなたの質問の共有プロジェクトの部分に集中するつもりです。なぜなら、私は、複数のプロジェクトと複数の共有プロジェクトが破壊された職場から来たばかりだからです。

私が重要だと最初に提案するのは、次のアイデアで作業を開始することです。「ソリューションを構築するために必要なのは、ハードディスク上の任意の場所でプロジェクトのトランクのチェックアウトを実行することだけです」

また、変更のない作業コピーには価値がないことを忘れないでください。ディスクのどこでチェックアウトしてもかまいません。トランクを再度チェックアウトしてすぐに起動できるため、作業コピーを削除してもパニックに陥ることはありません。以前の場所では、開発環境を「作成」し、すべてを適切な場所に配置するために細心の注意が払われていることがわかりました。これはばかげており、これを行うために費やされた時間は二度と戻されません。一度実行して、適切なソース管理（svn、git、TFSなど）で実行し、昨日の新聞のようにコピーを処理できるようになったことを嬉しく思います。

作業コピーに価値があるのは、コミットされていない変更がある場合のみです。貴重な作業コピーは脆弱です。可能な限り早く変更をコミットしてください。あらゆる形式のハードドライブ障害（作業コピーの破損を含む）、偶発的な削除、機能するものから機能しないものへの変更などは、多くの作業を失う可能性があります。これは貴重なビットです。半分焼き付けたコードがプロジェクトのトランクに表示されない場合は、ブランチを作成してコミットします。

これは、ドライブの異なる場所にある同じプロジェクトの複数のバージョンをチェックアウトして、それらに取り組むことができることを意味します（たとえば、開発バージョンとライブバグ修正バージョン）。また、トランクをチェックアウトすると、その作業コピーフォルダーの下にあるすべての依存ライブラリがダウンします。

また、ヘッダー/ライブラリが配置されている場所のIDEレベルの定義が機能しないことも意味します。これは、Visual Studioが導入したひどいアイデアでしたが、個々のプロジェクト設定の相対フォルダーを使用してこのようなものを指定することもできます。IDEレベルの場所の定義を使用している場合は、ある時点でアプリを作成し、変更が表示されない理由を解明しようとしていると信じてください。次に、ライブラリの古いバグのあるバージョンに対して最後の3つのリリースを作成したばかりであることに気付くと、その沈み込みを感じるでしょう。少なくとも私はしました。

このユートピア的な状況に到達するには、各プロジェクトとライブラリ（CoolApp、CFoo、ThisControl、CWidgetなど）を個別のリリースサイクル、トランクなどを備えた個別のプロジェクトと見なすと、はるかに有利になります。これらのことを独立して考え、別々に開発してリリースする方向に進んでください。

これは多くのオーバーヘッドのように聞こえますが、共有コンポーネントを使用する他のプロジェクトを壊さずに共有コンポーネントに変更を加えたい場合は、それが必要です。

そのことを念頭に置いて、リポジトリを次のように構成することをお勧めします。

/Projects
 /CoolApp
  /trunk
  /branches
  /tags
/Libraries
 /CFoo
  /trunk
  /branches
  /tags
 /CWidget
  /trunk
  /branches
  /tags
 /ThisControl
  /trunk
  /branches
  /tags 
/Vendor
 /NUnit
  /current
  /1.6
  /1.7

リポジトリが現在そのように設定されていない場合は、svncopyを使用してリポジトリを構造化できます。トップレベルとその下のすべてでタグ/トランク/ブランチを使用できますが、私の考えでは、それを行うと、プロジェクトを概念的に分離することがより困難になります。

次に、メインプロジェクト（CoolApp）のトランクだけをチェックアウトします。もちろん、依存するプロジェクトがないため、これはそのままではビルドされません。次のステップは、他のプロジェクトを外部として追加することです。tortoisesvnを使用して作業コピーの最上位フォルダーで右クリックし、svn->propertiesに移動します。「svn：externals」という名前の新しいプロパティを追加します。次の形式でプロパティを定義します

/repository_location[@revision]    working_copy_folder

したがって、coolappの場合、次のsvn：externals定義を追加できます。

/Libraries/CFoo/trunk        CFoo
/Libraries/CWidget/trunk     CWidget
/Libraries/ThisControl/trunk ThisControl

それが終わったら、変更をコミットしてから「更新」を実行すると、外観もダウンします。

この形式の外部定義を使用して、任意の作業用コピーフォルダー構造を構築できます。新しい場所でプロジェクトを探すには、ソリューションファイルを変更する必要がありますが、これは通常、大きな問題ではありません。

このように作業を開始したら、外部がトランクを指すようにすることは一般的に非常に悪い考えであることに注意してください。これは、別のプロジェクトのためにライブラリのトランクが変更された場合、ソリューションの新しいチェックアウト（または更新）を行うと、何も変更したとは思わなかったとしても、突然完璧なソリューションが構築されないためです。ライブラリのタグの作成を開始し、代わりに外部をそれらに向けます。これは、ライブラリをそれ自体が別個のプロジェクトとして考え始めるときです。

これは別の原則の状況です。「プロジェクトへの変更には、メインプロジェクトのトランクに対応するリビジョンが必要です」新しいライブラリバージョンを指すように外部の場所を変更することは、「ねえ、ここでfoolibのバージョン2を使用しています。」前の段落の問題は、コードがあなたの「下」で変更されたためです。

ライブラリを変更するには、理想的にはそのライブラリのトランクの作業コピーをチェックアウトし、それを変更して、新しいバージョン番号でタグ付けします。次に、メインプロジェクトで、新しいタグを指すように外部を変更し、更新します。

ライブラリの場所をタグからトランクに「切り替える」ことで、このプロセスを短縮できます。そうすれば、コミットするときに、ライブラリの変更をトランクにコミットします。ただし、このように作業する場合は、外部がタグを指していることを覚えておく必要があります。ライブラリにタグを付けてプロジェクトを外部に変更する必要があります。そうしないと、新しいチェックアウトが作成されません。

nAntやnUnitなどのサードパーティツールに依存している場合は、ベンダーブランチとしてリポジトリに追加し、外部から参照します。VSを使用すると、dllを参照して参照できます。これは、GACよりも柔軟性があります。1人の開発者にとってはそれほど問題には思えないかもしれませんが、一度に1つのプロジェクトをnUnitにアップグレードしようとすると、プロジェクトのトランクをチェックアウトできることがどれほど優れているかがわかり、正しいバージョンのnUnitが一緒にあります（nUnitをアンインストールして正しいバージョンを再インストールする必要はありません）。

また、ソリューション内のすべてのプロジェクトを個別の外部として持つ必要はないことにも注意してください。分離する必要があるのは、さまざまなプロジェクト間で共有できる、または共有する必要があるものだけです。

最後に、起動して実行したら、CruiseControl.NetやHudson（私のお気に入り）などのビルドエンジンを使用することをお勧めします。これにより、問題がレーダーの下に潜り込み、背後から噛み付く前に、問題を迅速にフィードバックできます。

さて、ここでやめます。「最長回答」バッジを取得するつもりはありませんでした。

于 2009-06-13T09:51:21.320 に答える