2012-03-13 11 views
1

私はdelphi 7Tortoise svnでプロジェクトに取り組んでいます。プロジェクトは調査ツールの一種です。 我々は現在、myproject 1.8となる新しいバージョンの開発を開始しており、2ヶ月後にはmyproject 2.0から開始する予定です。SVN(タートル) - このような状況をどのように処理するのですか?

注::既に存在するsvnを継承しました。それはない私たちのデザイン

シナリオ: 私はc:\project\myproject\である私のc:\で1つだけのフォルダを持って、我々は、起動しているので、我々はプロジェクトを開始するdidntの、私たちはmyproject 1.5 ..but今myproject 1.5コードから取り扱いを開始私たちがmyproject 1.7で始まったときに、私たちはフォルダc:\project\myproject\NV1.6Codeを作成し、そのフォルダにコード全体をコピーし、myproject 1.7で始まった...今、私はmyproject 1.7.1myproject 1.7.2のようなサブバージョンを維持する方法がわからない`myproject 1.6.4が現在の状態です。

今私たちはmyproject 1.8から始めようとしており、サブバージョンコントロール としてそれを開始する方法がわからないので、myproject 2.0も近日公開予定です。

構造: パス:C:\projects\myproject

あなたがpicture..theで見ることができるようにNV1.6codeディレクトリは、バージョン1.6のコードを持っており、外部のすべてのディレクトリがバージョン1.7 code ..です

ありません良いアイデア? 私薄いドン、これは良いアイデアだろう

AIM:どのように私は上記の混乱が適切作るのですか? バージョン維持するために、私の場合、私は亀SVNを最大限に活用しますか

  1. myproject version 1.6 (then the subversion like 1.6.1 , 1.6.2, 1.6.3)
  2. myproject version 1.7 (then the subversion like 1.7.1 , 1.7.2, 1.7.3)
  3. myproject version 1.8 (then the subversion like 1.8.1 , 1.8.2, 1.8.3)
  4. then the future version myproject version 2.0
+0

まだ読んでいない場合は、「[Subversionを使ったPragmatic Version Control](http://pragprog.com/book/svn/pragmatic-version-control-using-subversion)」のコピーを入手することを検討してください。これはバージョンの分岐をカバーしているので、これについての良い背景を与えるでしょう。 –

+0

@JoeWhite:ok私はこれを行っていきます:) – PresleyDias

答えて

2

これを行うには、ブランチまたはタグ機能を使用する方法が2つあります。一般的に

、私はリリースポイントと開発を指定するためのタグを使って好きな比較的直線的に上続けて(1.6が1.7になり、1.8から1.7など)

しかし、何らかの理由であなたが言うならば1.6をリリースし、主な開発は1.7になりましたが、1.6への小さな変更(1.6.1、1.6.2など)を続けたいと思っていました。

両方の機能を一緒に使用することもできます。

+0

+1のアイデアは、okブランチは私の方が良いでしょうか?私はSVNの初心者以外はちょうど 'コミット'と '更新'。 – PresleyDias

+0

私は両方を使ってもうまくいくと思いますが(ブランチだけでも良い解決策です)。リリースのバージョンにはタグを付けることができますが、開発者がさまざまなバージョン間で作業できるブランチを作成することができます。 – helloworld922

+0

今、いくつかのデータを通過した後、私の最初の仕事は、/ tag/trunk/branchの3つのメインディレクトリを作成することです...その後、私はすべてのコードをトランクに入れてから、/ branches/myprojec1 .8? – PresleyDias

3

問題を解決するには、ブランチとタグ機能を使用する必要があります。しかし、各バージョンのブランチを作成すると、作業が複雑になり、変更を処理できなくなることに注意してください。注意:

  • ブランチの数を減らすようにしてください。 (通常は2または3で十分です)
  • リリースされたバージョンごとに、タグを作成します。
  • 変更をマージする適切なメカニズムがない場合、ソースコントロールにブランチがたくさんあることを避けてください。
  • 変更をマージするのに時間がかかり過ぎると、ブランチの構造に問題があります。
  • ブランチを持つことに決めた場合は、可能な限りマージを延期しないでください。すべてのブランチのすべての変更を同時にマージする試み(ビッグバンマージ)は禁止すべきです。
  • チームは明白な理由で多くのブランチを作成すべきではありません。
  • システムにブランチが作成された場合(正しいか間違っているか)、作業が終了すると、その変更は可能であれば親ブランチにマージされます。
  • チームメンバーは、ブランチング、マージ、または新しいベースラインの構築中に開発活動を止めてはなりません。
  • 実行中の作業を分割するのではなく、分岐を使用して開発チームメンバーを分割しないでください。

詳しくはthis answerをご覧ください。

関連する問題