2008-09-09 12 views
19

私は主なビジネスがソフトウェアに関連していない会社で働いています。ソース管理を使用するためのほとんどのドキュメントは、開発チームが商用またはオープンソースプロジェクトを念頭に置いて書かれています。家のソフトウェアを書く人として、私は仕事が異なって行われていると言うことができます。それは商用またはオープンソースの設定になります。さらに、コードと同期して保存する必要のあるストアドプロシージャとデータベーススクリプトがあります。社内ソフトウェアプロジェクトのSubversionリポジトリをどのように整理しますか?

特に私は、自社のソフトウェアを使ってリポジトリをどのように構築するのが最善であるかを提案したいと考えています。ほとんどのドキュメントは、トランク、ブランチ、タグなどを提案しています。生産、テスト、開発環境をリポジトリのそれぞれのセクションと同期させる手順。

答えて

3

www.unfuddle.comのようなサービスを使用して、無料のSVNまたはGITリポジトリ。

私たちはUnfuddleを使用しています。本当に素晴らしいです。無料版と有料版があります(必要に応じて)。

もちろん、ローカルコピーを設定することもできます。そのためにグーグル経由で発見されるチュートリアルがたくさんあります:http://www.google.com/search?rlz=1C1GGLS_enUS291&aq=f&sourceid=chrome&ie=UTF-8&q=set+up+svn

0

this threadに指定され、分散型のVCS(gitの、Mercurialの)として分岐作成しやすさのために、集中型のものよりも優れたモデル、ブランチマージしやすさ、不要です特別なサーバーをセットアップするには、ネットワークアクセスが必要な作業やその他の利点があります。 DVCSだけで作業すれば、必要が生じた場合にプロジェクトに人を組み込むことができます。

あなたの質問に直接答えて、SVNをセットアップする方法は、プロジェクトごとにリポジトリを持つことです。ストアドプロシージャとスクリプトとライブラリが共有されているかどうかによって、スクリプトの各プロジェクトツリーにディレクトリを作成しますストアドプロシージャ、または共有コードの完全なリポジトリを使用します。

6

転覆の場合、もあり、Tracなどの便利なツールが付属しています。プロジェクトごとにスペースやユーザーが必要な場合は、無料です。

2

私の会社では、svn + sshとキーベースの認証を使用しています。 WindowsクライアントとLinuxクライアントの両方でこれを行うことができます。これは、パスワードを入力するのではなくログインするためにsshキーを使用する際に、鍵をまっすぐにすると本当に簡単に使用できます。

Here's an article on setting up svn+sshセキュリティに関する注意事項このようなことをすべて理解してこれらの手順に従えば、良いスタートを切ることができます。

This articleには、svnアカウントのsshログインをさらに安全にする方法がいくつか記載されています。

他のアクセス権がないsvnアクセス専用のアカウントを作成することをお勧めします。私の推測では、毎日のビルドまたは自動化されたスクリプトを使用して、db内のストアドプロシージャを更新するということです。毎日のビルドでは、独自の特別なアカウントと独自のsshキーを持つことができます。人間のユーザと同じログインで自動化されたツールを実行するのは嫌いです(どのツールが壊れているかわかります)。

セキュリティに関するすべてのことを理解していない場合は、Googleを検索するといくつかの助けが得られます。問題がある場合は、最初にセキュリティ対策を講じないで設定します。これはトラブルシューティングを少し簡単にします。

幸運にも、ソースコントロールのメリットがあります。

3

あなたのプロジェクトの1つのリポジトリで十分でしょう。

/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 

は覚えておいてくださいあなたは後でいつでもリポジトリを再編成することができます:私はこのプロジェクトによって、レイアウトが(O'Reilly Subversion bookからthis sectionを参照)、インデックス、典型的なアプローチが好きです。

また、社内用のものとして、Berkeley DBではなく、データストア用のFSFSを使用することをお勧めします。 FSFSはより弾力性があり、チェックアウトのスピードは小規模チーム/プロジェクトにとって大きな問題ではありません。あなたはcompareで、あなた自身で決定することができます。

レシピのその他の標準部分には、Tracと、LAN上のリポジトリをホストする最小限のLinuxサーバーが含まれます。

19

SVNリポジトリを設定することは、それらをどのように編成するかという意味でのみ難しいことがあります。私たちがSVNをセットアップする前に、私は実際にリポジトリの組織技法や、あなたが考え直さなければならないいくつかの問題点について議論しているオンラインのSubversion manualを実際にRTFMしました。セットアップの前にこのマニュアルを通すことをお勧めします。

私たちはコンサルタントとして、カスタムと社内のソフトウェア開発と、SVNによるドキュメント管理を行っています。クライアントごとに1つのリポジトリを作成するのは私たちの関心事でした。各リポジトリ内で、各プロジェクト(ソフトウェアなど)ごとにフォルダを作成しました。これにより、リポジトリ内およびクライアントごと、さらにはリポジトリ内のプロジェクトごとにセキュリティアクセスを分割することができました。もっと深く、それぞれのソフトウェアプロジェクトのために、私たちは「働く」、「タグ」、「支店」フォルダを作成しました。私たちは一般的に、リリース用のタグとして 'release_w.x.y.z'を使って 'tags'にリリースを置きます。

あなたのケースでは、sprocs、スクリプト、およびその他の関連ドキュメントを同期させておくために、プロジェクトフォルダを作成し、その下に 'working'フォルダを作成し、その後、リリース用の作業用バージョンにタグを付けると、すべてのタグ付けが終了します。

非コードは、プロジェクトやドキュメントタイプ(マニュアル、ポリシーなど)で直線的なレイアウトをお勧めします。一般的には、ドキュメントと会社の運営方法に応じて、バージョン履歴/ログだけで十分です。

私たちはWindows上でSVNを、オープンソースのリポジトリビューアであるWebSVNと一緒に実行します。私たちは、クライアントにコードへのWebアクセスを提供するためにそれを使用しています。内部的には、TortoiseSVNを使用してリポジトリ、コミット、更新、インポートなどを管理します。

もう1つのことは、トレーニングが展開の不可欠な部分であるとみなされることです。バージョン管理が初めてのユーザーは、何が起こっているのかを理解するのに苦労するかもしれません。我々は、彼らが概念を学んでいる間、それらに機能的な指示を与えること(プロジェクトを作成するときにこれを行う、更新するときにこれを行うなど)が非常に有用であることを発見した。私たちは、ユーザーが文書やフォルダを使って練習するのに必要なものすべてをプレイできる「サンドボックス」リポジトリを作成しました。このポリシーは、確立するポリシーを試すのにも役立ちます。

幸運を祈る!

+2

トップレベルのフォルダの確立された標準は 'trunk、branches、tags'です。 'trunk'の代わりに' working'を使うと、SVN reposで動作する多くのツールを混乱させます。私はそれをすることを強くお勧めします。 – sleske

3

は、私が提案同僚と話をした、この質問を投稿した後、私は記事を読ん:要するに

http://www.codinghorror.com/blog/archives/000968.html

、それはプログラマが分岐より意識することを提唱しています。私のリポジトリの整理について正しい方法がないことがわかりました。私たちのチームには、テスト開発のためのトランクと2つの長期ブランチがあります。さらに、テストや生産までの作業を促進するために、タスクごとに個別のブランチを作成し、タスクブランチからの変更をマージします。

0

私はトランク、タグ、その下の枝を持つプロジェクトディレクトリで基本パターンに従うと信じています。私はこの

プロジェクトのようなトップレベルが保持している通常のセットアップと同様に、個々のプロジェクトのすべてまたはモジュール リリース ユーザーがなど

管理者は、私のフックスクリプトを保持しているプラ​​イベートユーザ枝、バックアップスクリプトを保持している複数のモジュールを含んでリリースタグを保持しています

リリースタグは、複数のモジュールで構成され、特定のリリースで異なるタグ(それらをバインドする1つのリングとそのすべて)で構成されている製品をお持ちの場合に便利です。ソースエスクローと開発でリリース1または2を構成するものを参照するのが容易になります。

2

私はトランク/ブランチ/タグの共通の規約を使用することに同意します。それ以上に、私はあなたの答えがHow do you organize your version control repository?であるかのように探しているかもしれないと思う。

関連する問題