2011-02-02 18 views
1

私は現在、Subversionをソース管理として使用する2人のプロジェクトに取り組んでいます。今はブランチを作成し、それらのブランチで開発を行い、その変更をトランクのコピーにマージしてから、トランクをコミットします。Svn開発ワークフロー

私たちが抱えている問題は、すべてを更新し続けるという膨大なオーバーヘッドです。我々の仕事の流れの

  1. 私は最新の更新プログラム
  2. を得るために、私のトランクのコピーにUpdateを実行し、私は
  3. 私のブランチにトランクの更新をマージ私は私の枝
  4. に取り組むIトランクに自分の変更をマージする
  5. トランクを更新して新しいアップデートがあるかどうかを確認する
  6. 私は

をコミット問題

  1. それはログ
  2. で明示的に私を書いても、マージされたリビジョンを追跡することは困難である時々私は完全にuptodate支店を持っていますが、Iコミットのためにアップデートをトランクにマージすることはできません。

もっと簡単なワークフローをお勧めしますか?時々私たちは他人のコードに影響する領域で働き、現時点では避けられないことがあるので、更新する必要があります。私はトランクに1日に少なくとも1回コミットするのが好きなので、物事があまりにも遠くから外れることはありません。

ありがとう

答えて

1

私は過去10年ほど、同じブランチやトランク上で、同じモジュールやプロジェクトで5〜10人の人が共有している日常業務に直接携わってきました。コミットする前に更新し、直ちに問題を修正してください。毎日すべてをマージしているので、あなたはすでにこのシナリオにかなり近いです。それは、継続的な統合ビルドマシンと単体テストを持つのに役立ちます。あなたの教職員が混乱している場合は、以前のリビジョンに更新して、それがクリーンアップされるまで作業することができます。

1週間またはそれ以上の間、チームの残りの部分で何かをリエンジニアリングする必要がある場合は、ブランチが必要です。これはしばしば回避できます。

4

2人の場合、単純なワークフローは単純にトランクで作業することです。時々あなたは葛藤するでしょうが、あなたはそれを解決し続けていくことができます。あなたが今やっていることよりはるかに簡単です。

ブランチは、作業ストリームを別々に保ちたい場合に適していますが、そのようには望んでいないと思われるので、ブランチを使用しないでください。

+0

+1このような小規模なチームにとっては、これが最善の戦略です。 –

関連する問題