2008-09-15 9 views
1

私は、Subversionがタグを移動するのに適していると思います。タグを移動する方法がわかっているのは、タグからファイルを削除してから、もう一度コピーすることだけです。リビジョンツリーブラウザはそれをうまく処理していないようです。これはまた、ディレクトリ構造をトランクの下に置き、タグを同期させておく必要があります。Subversionでタグを移動するには

使用例:数千の「マップ」があり、各マップのどのバージョンが「本番」バージョンであるかをタグ付けする必要があります。すべての地図のプロダクション版を簡単に入手できるようにする必要があります。

誰かがユースケースに対処するためのより良い方法を提案できますか? 私もプロパティを考慮しましたが、すべてのファイルの巧妙なバージョンを簡単に取得することはできません。タグへのマージはそれほど簡単ではないようです。 (元はhttp://jamesjava.blogspot.com/2007/12/subversion-moving-tags.htmlに投稿されました)

+0

プロダクションブランチを保持する(または本番用のトランクを使用する)ためには、両方のディレクトリ構造を同期させるために余分な作業が必要です。したがって、ディレクトリを本番領域とそのスクリプトにコピーした自動スクリプトがない限り頻繁に走った。 –

+0

各マップは独立したファイルであるため、一度に少数のデータのみを本番環境に送信し、すべての変更を一緒に送信するわけではありません。 (同様の設定は、WebサイトのHTMLファイルのディレクトリ構造になります。ファイルは変更され、独立して送信されます) –

答えて

2

私はあなたがこれまでSubversionが動作する方法でこれを行うことはできないと思います。私は最高の解決策は、あなたのユースケースに合っているように思えるgitのようなツールを見ることだと信じています。プロダクションシステムは、受け入れられた「地図」の中で「引き出す」ことができます。私はこれがsubversionではないことを認識していますが、gitを使用すると、svnよりも使用パターンに近い一致が得られる可能性があります。

gitのプルベースの開発モデルがあなたのシナリオに一番合っている理由を書いてみると、hereです。

thisのように移行を開始する方法に関するチュートリアルもあります。

+1

投稿され、タイトルが付いているように質問に答えなかったため、ダウン投票されました。 – danorton

+0

@ダノートン:最初の下降票で理解された。しかし、私は正直なところ、Subversionがリポジトリのリビジョン履歴を保持する方法でこれが可能であるとは思わない。私が理解しているように、目標はタグを移動できるようにすることです。しかし、svnは、gitによって格納された内部グラフを調整するのではなく、タグをリポジトリの新しいリビジョンとして追加します。あなたが用途に合った提案をしているなら、私はそれを投票してうれしいですが、まずそれを提出しなければなりません。 – Wyatt

2

プロダクションタグからファイルを削除する必要はありません。新しいファイルを既存のファイルにコピーしてチェックインすると、履歴が保存されます。

もちろん、これを行うには、制作タグをチェックアウトする必要があります。

0

現在のプロダクションバージョンで新しいタグを作成してみませんか? SubversionはCVSではないことを覚えておいてください。だから完全なディレクトリツリーのコピーを作ることはあなたに何の費用もかかりません。

1

これは転覆には適していません。

Subversionタグは、履歴内の特定のスナップショットのように、ツリーのインスタンスに名前を付けるためのもので、静的に保つ必要があります。

タグの一部として現在の日付または増分を使用できますか?特定の日付のように、本番バージョンを含むタグの下にディレクトリを置くことができます。現在の生産バージョンとして最新の日付を取得します。

今日のバージョンは

/svn/tags/production/2008/09/15/mapproject 
0

で見つけることができる一つの方法は、「安定したトランク」モデルに移行することです。

  • 作業領域として使用するトランクからブランチを作成します。
  • トランクに直接コミットすることをやめてください。皆が開発ブランチに切り替えるようにしてください。
  • 安定版を管理している人がトランクをチェックアウトしたことを確認してください。コミット権があることを確認してください。
  • マップを「解放」する場合は、「reintegrate merge」を使用して、そのファイル/ディレクトリへの変更をプルして変更をコミットします。

これは逆さに表示されるかもしれませんが、かなり実行可能です。プロダクションマシンをトランクからまっすぐに引き出すか、リリースごとにトランクから新しいタグを作成することができます。後者の場合、新しいタグを本番マシンに伝えるための何らかの方法が必要になります。いくつかの種類のメッセージング、共有設定または命名規則が機能する可能性があります。

しかし、このモデルでは、トランクの考え方はやや神聖なものでなければならないことに注意してください。

0

私はあなたのニーズをよく理解していれば、それを実行する最良の方法は、すべての地図をメイントランクの外観として持っていて、各地図(外部)にそれを再帰的にタグ付けするスクリプトを作ることです作業コピー(またはそのようにしたい場合はサーバー)。

1

あなたは間違った問題を解決しようとしていると思います。

まだリリースされていないバージョンのマップを含むトランクを持っているように聞こえます。リリースを行うと、トランクのすべての更新から更新するマップを選択する必要があります。

この場合、「リリース」というブランチを作成します。 (新しい空のディレクトリを作成し、それが速ければ必要なマップバージョンを別々のsvn cpコマンドでコピーすることを検討してください)。

今、ブランチに現在のリリースがあります。 「Release XXX」でタグ付けしてください(ここで、XXXは最新リリースの意味のあるIDです)。

地図が次のリリースで承認されると、それらをリリースブランチにsvn cpします。離散要素はソースコードではないので、マージを使いたくないと思います。

次回のリリース時に、もう一度タグ付けすることができます。

最新の承認されたマップは何であり、すべてのリリースで何があったのか分かりました。 本当にが最新のリリース番号を覚えていない場合は、タグディレクトリを調べるだけで知る必要がある時間を考え出すことができます。最新のリリースをsvn cpした後、それを離れて、次のリリースを行うときに再コピーしてください。

+0

これは、ディレクトリ構造を同期させて手動で(またはスクリプトで)必要とします。 –

関連する問題