私は、主なビジネスがソフトウェア関連ではない会社で働いています。ソース管理を使用するためのほとんどのドキュメントは、開発チームが商用またはオープン ソース プロジェクト用に作成することを念頭に置いて作成されています。社内でソフトウェアを作成する者として、商用またはオープンソース環境での作業とは異なる方法で作業が行われると言えます。さらに、コードとの同期を維持する必要があるストアド プロシージャとデータベース スクリプトがあります。
特に、社内ソフトウェアを念頭に置いてリポジトリを構成する最善の方法についての提案を求めています。ほとんどのドキュメントは、トランク、ブランチ、タグなどを提案しています。また、本番環境、テスト環境、および開発環境をリポジトリ内のそれぞれのセクションと同期させるための手順なども含まれています。
SVN リポジトリの設定は、それらをどのように整理するかという意味でのみ難しい場合があります。SVN をセットアップする前に、オンラインのSubversion マニュアルを実際に RTFM しました。このマニュアルでは、リポジトリの編成テクニックと、事前に考えておくべき落とし穴、つまり、気が変わった場合にリポジトリを作成した後にできないことについて説明しています。 . セットアップの前に、このマニュアルを一読することをお勧めします。
私たちの場合、コンサルタントとして、カスタムおよび社内のソフトウェア開発と、SVN によるドキュメント管理を行います。クライアントごとに 1 つのリポジトリを作成し、自分たち用に 1 つのリポジトリを作成することは、私たちの関心事でした。各リポジトリ内に、各プロジェクト (ソフトウェアまたはその他) のフォルダーを作成しました。これにより、セキュリティ アクセスをリポジトリごと、クライアントごと、さらにはリポジトリ内のプロジェクトごとにセグメント化することができました。さらに詳しく説明すると、ソフトウェア プロジェクトごとに、「作業」、「タグ」、および「ブランチ」フォルダーを作成しました。私たちは通常、「release_w.xyz」を標準のタグとして使用して、リリースを「タグ」に入れます。
あなたの場合、sproc、スクリプト、およびその他の関連ドキュメントの同期を保つために、プロジェクトフォルダーを作成し、その下に「作業」フォルダーを作成し、次にその「コード」の下に、その隣に「スクリプト」などを作成します。作業バージョンにリリース用のタグを付けると、すべて一緒にタグ付けすることになります。
\Repository
\ProjectX
\Working
\Code
\Scripts
\Notes
\Tags
\Branches
コード以外については、プロジェクトまたはドキュメントの種類 (マニュアル、ポリシーなど) ごとにフォルダを整理することをお勧めします。通常、ドキュメントの場合、および会社の運営方法によっては、バージョン履歴/ログだけで十分です。
優れたオープン ソース リポジトリ ビューアーであるWebSVNと共に Windows で SVN を実行します。これを使用して、クライアントにコードへの Web アクセスを提供します。これはすべて、基盤となる Subversion セキュリティによって駆動されます。内部的には、TortoiseSVNを使用してリポジトリ、コミット、更新、インポートなどを管理しています。
もう 1 つのことは、トレーニングは展開の不可欠な部分と見なす必要があるということです。バージョン管理に慣れていないユーザーは、何が起こっているのか理解するのに苦労するかもしれません。機能的な指示 (プロジェクトを作成するときにこれを行う、更新するときにこれを行うなど) を与えることは、概念を学習する際に非常に役立つことがわかりました。ユーザーがドキュメントやフォルダを自由に操作して練習できる「サンドボックス」リポジトリを作成しました。これは、確立するポリシーを試すのにも役立つ場合があります。
幸運を！
Subversion には、 Tracやその他の便利なツールに付属するAssemblaもあります。それは無料ですが、プロジェクトごとにより多くのスペースまたはユーザーが必要な場合は、アカウントの料金を支払うことができます.
プロジェクト用の 1 つのリポジトリでおそらく十分です。プロジェクトごとにレイアウトをインデックス化する典型的なアプローチが気に入っています ( O'Reilly Subversion bookのこのセクションを参照してください)。
/first-project/trunk
/first-project/branches
/first-project/tags
/another-project/trunk
/another-project/branches
/another-project/tags
/common-stuff/trunk
/common-stuff/branches
/common-stuff/tags
リポジトリは後でいつでも再編成できることに注意してください。
また、社内のものについては、Berkeley DB とは対照的に、データストアには FSFS を好みます。FSFS はより弾力性があり、チェックアウトの速度は小さなチーム/プロジェクトにとってはあまり問題ではありません。自分で比較して決めることができます。
レシピのその他の標準部分には、Tracと、LAN 上でリポジトリをホストするための最小限の Linux サーバーが含まれます。
www.unfuddle.com のようなサービスを使用して、無料の SVN または GIT リポジトリをセットアップできます。
私たちは Unfuddle を使っていますが、本当に素晴らしいです。無料版と有料版があります (必要に応じて)。
または、もちろんローカル コピーをセットアップすることもできます。そのための Google 経由のチュートリアルがたくさんあります。
この質問を投稿した後、記事を読むことを提案した同僚と話しました。
http://www.codinghorror.com/blog/archives/000968.html
要するに、プログラマーが分岐をもっと意識するように提唱しています。リポジトリを整理する正しい方法がないことを理解するのに役立ちました。私たちのチームには、テストと開発用にトランクと 2 つの長期ブランチがあります。さらに、タスクごとに個別のブランチを作成し、タスク ブランチからの変更をマージして、タスクをテストおよび本番まで進めます。
トランク/ブランチ/タグの一般的な規則を使用することに同意します。それを超えて、あなたは私の答えのようなものを探しているかもしれないと思います。バージョン管理リポジトリをどのように整理しますか？。
私の会社では、svn+ssh とキーベースの認証を使用しています。これは、Windows クライアントと Linux クライアントの両方で実行できます。これは、パスワードを入力するのではなく ssh キーを使用してログインするため、キーを取得すると非常に使いやすくなります。
セキュリティに関する注意事項を含むsvn+ssh のセットアップに関する記事を次に示します。これらのことをすべて理解し、これらの手順に従えば、良いスタートを切ることができます。
この記事では、svn アカウントの ssh ログインをさらに安全にするいくつかの方法について説明します。
そのサーバーへの他のアクセスを持たない svn アクセス専用のアカウントを作成することをお勧めします。私の推測では、毎日のビルドまたは自動化されたスクリプトを使用して、データベースに保存されている proc を更新すると思います。デイリー ビルドは、独自の特別なアカウントと独自の ssh キーを持つことができます。自動化されたツールが人間のユーザーと同じログインで実行されるのは好きではありません (そのため、どのツールが壊れているかがわかります)。
すべてのセキュリティ トリックを理解していない場合は、Google で検索すると助けが得られます。問題がある場合は、最初にセキュリティ トリックを使用せずにセットアップしてください。これにより、トラブルシューティングが少し簡単になります。
頑張って、ソース管理の利点を楽しんでください!
このスレッドで指定されているように、分散型 VCS (git、Mercurial) は、ブランチの作成が容易で、ブランチのマージが容易で、特別なサーバーをセットアップする必要がなく、ネットワークにアクセスして作業する必要がないなどの点で、集中型の VCS よりも優れたモデルです。利点。一人で作業する場合、DVCS を使用すると、必要に応じてプロジェクトに人を簡単に組み込むことができます。
とにかく、あなたの質問に直接答えると、SVN をセットアップする方法は、プロジェクトごとにリポジトリを持ち、ストアド プロシージャとスクリプトとライブラリが共有されているかどうかに応じて、各プロジェクト ツリーにスクリプトとストアド プロシージャ用のディレクトリを作成することです。または共有コードの完全なリポジトリ。
その下にトランク、タグ、ブランチがあるプロジェクトディレクトリの基本的なパターンに従うことを信じています。私は通常、このようにトップレベルをセットアップするのが好きです
Projects は個々のプロジェクトまたはモジュールのすべてを保持します Releases は複数のモジュールを含むリリース タグを保持します Users はプライベート ユーザー ブランチを保持します Admin はフック スクリプト、バックアップ スクリプトなどを保持します
リリース タグは、特定のリリースに対してすべてが異なるタグである可能性のある複数のモジュールで構成される製品がある場合に役立ちます (それらをバインドする 1 つのリングなど)。これにより、ソース エスクローや開発者がリリース 1 または 2 を構成するものを簡単に参照できるようになります。