0

これが可能であることは知っていますし、それを行うにはさまざまな方法がありますが、複数のリビジョンからタグを作成しない正当な理由はありますか?

私が提案しているのは、SVNKit と Jakarta POI に基づいて、さまざまな svn リビジョンで Excel スプレッドシート/CSV ファイル (Java クラス ファイルとその他のものの混合) からビルド アーティファクトのリストを読み取り、TAG を作成するプログラムを作成することです。そして、この TAG が次に提案されたリリースになるものです。

私がこのアプローチを気に入っている理由は次のとおりです。

  1. 各リリースの詳細を正確に説明したドキュメント (場合によってはベースライン) があります。

  2. これにより、リリース マネージャーは何かを行うことができます (単純に head をチェックアウトしたり、分岐やマージなどの複雑なことを学習したりする必要はありません)。

  3. 開発者は、「リリース ウィンドウ」などの概念に制約されることなく、必要なときに必要なものをチェックインできます。つまり、開発者がリリース直前にチェックインすることを制限します。

次の理由から、私はこのアプローチを信用していません。

基本的な svn の原則に違反しているように感じます (何が原因かはわかりませんが)。

いわば人々がタイヤを蹴るためにこのアイデアを世に出しているのは、わずかな疑いがあるからです。皆さんはどう思いますか？

4

2 に答える 2

1

開発者は、「リリース ウィンドウ」などの概念に制約されることなく、必要なときに必要なものをチェックインできます。つまり、開発者がリリース直前にチェックインすることを制限します。

これを行う従来の SVN の方法は、トランクではなく、常にブランチで作業することです。このようにして、いつでもコミットできます。「リリース ウィンドウ」でトランクにマージされません (トランクが「凍結」されている場合)。

于 2011-02-25T09:17:58.537 に答える
1

You're not violating any svn principles by doing this. Tag is not an inbuilt subversion construct, just a convention that people use to aid with the build process. Normally people would want their tags to be based off a single revision, but again that is only convention. Do you really have a situation where the good code to ship consists of historical versions of some files but current versions of others?

If this approach works for you, then go for it. However, to avoid confusion for anyone used to the normal definition of 'tags', perhaps you could call the directory something else? "Builds" perhaps?

于 2011-02-25T09:14:04.743 に答える