@@ -1,8 +1,9 @@ = TracLightningのJenkinsによるバックアップについて = -TracLightning 3.1.2以降には付属の backup.bat をJenkins 定期実行するためのサンプルジョブが含まれています。 +TracLightningには、プロジェクト・リポジトリデータをバックアップするスクリプトbackup.batが含まれていますが、 +TracLightning 3.1.2以降ではバックアップをJenkinsで定期実行するためのジョブが追加されました。 -このジョブを利用することでバックアップの定時実行を簡単に実施することが可能です。 +このジョブを利用することで'''定期的なバックアップを簡単'''に取ることができます。'''Jenkinsに興味がある方で、まずは使ってみたいという人にも最適です。''' == Jenkins設定内容 == * 毎日深夜午前0時1分に実行されます。(ビルド・トリガ)]]>
@@ -1 +1,37 @@ += TracLightningのJenkinsによるバックアップについて = +TracLightning 3.1.2以降には付属の backup.bat をJenkins 定期実行するためのサンプルジョブが含まれています。 + +このジョブを利用することでバックアップの定時実行を簡単に実施することが可能です。 + +== Jenkins設定内容 == + + * 毎日深夜午前0時1分に実行されます。(ビルド・トリガ) + * ログは7回分まで保存されます(ビルドの最大保存数) + * 環境変数：TL_BACKUP_DIR に設定されている場所にバックアップを保管します。 + * TL_BACKUP_DIR の設定がない場合には TRAC_LIGHT_HOME 以下に backup フォルダーを作成しを TL_BACKUP_DIR として扱います。 + * TL_BACKUP_DIR 以下に実行日の日付のフォルダを作成し、TL_BACKUP_DIR を日付つきのものに置き換えます。 + * backup.bat を実行し TL_BACKUP_DIR バックアップを行います。 + * 過去7回を超える分のバックアップを削除します。 + * 削除はコメントアウトしてあります。 + * ビルドの最大保存数に合わせて設定すると良いと思います。 + +== バックアップ対象・内容 == +バックアップ対象及び内容の詳細はスタートメニューにあるバックアップに準拠しますが概要は以下の通りです。 + + * 全プロジェクトの svn の hotcopy + * 全プロジェクトの trac の hotcopy + * hudson ( Jenkins )のディレクトリを丸ごと + * maven のディレクトリを丸ごと + +詳細については TRAC_LIGHT_HOME 以下にある backup.bat を参照してください。 + +== 利用についての注意 == +Jobはデフォルトで無効化されています。 + +そのまま有効化しても利用可能ですが今後のバージョンアップにて変更される可能性があるため、ジョブをコピーするかジョブ名を変更して利用することをお奨めします。 + +ジョブのコピーはJenkinsの"新規ジョブ作成"から"既存ジョブのコピー"を利用して、BackupSampleのジョブをコピーし有効化してからご利用下さい。 + + +]]>
@@ -47,19 +47,27 @@
* 殆どバグは枯れていますが、若干バグが残っている場合もあります。
* 基本的には、ささいなバグフィックス後、正式版をリリースします。
== バージョンの変更時のソースの変更 ==
-バージョンを変更する際には、下記のファイルに含まれるバージョン情報を変更します。
+バージョンを変更する際は、`set-version.cmd` で以下のように実行することで必要なファイルを書き換えられるようになっています。
+
+{{{
+C> set-version.cmd 3.1.3rc1
+}}}
+
+変更になる箇所は、以下の部分です。
* trac.iss
- * AppVerNameの部分
+ * {{{AppVerName=....}}} の部分
* install/replace/trac.ini.in
- * footerの部分
+ * footer の部分
== リリース作業 ==
1. 上記のバージョンを確認します。
- 2. ISCC環境変数をInnoSetupのコンパイラに設定し、build.cmdを実行します。[[br]](trac.issとinstall/replace/trac.ini.inのバージョン情報に差異があるとエラーになります。)
- 3. 出来上がったバイナリの名前がバージョン情報が付与されているかを確認します。(例えば、TracLightning-3.1.2rc1.exe)
+ 2. ISCC 環境変数を Inno Setup のコンパイラに設定し、build.cmd を実行します。
+ * ISCC 環境変数を設定しない場合、Inno Setup をデフォルトの場所にインストールしたと仮定して {{{%ProgramFiles%\Inno Setup 5\iscc.exe}}} を使います。
+ * trac.iss と install/replace/trac.ini.in のバージョン情報に差異があるとエラーになります。
+ 3. 出来上がったバイナリの名前がバージョン情報が付与されているかを確認します。(例えば、{{{TracLightning-3.1.2rc1.exe}}})
4. sf.jpの「ダウンロード」→「管理」からバイナリをリリースします。コンポーネントは、trac-lightningもしくはtrac-lightning-dev(開発版)を利用のこと
5. hg tagでバージョンのタグをうち、pushします。(ex. hg tag 3.1.2rc1)
]]>
@@ -23,9 +23,9 @@ * svnリポジトリはhgで取り込めるか? svnのアップデートのマージをhgで取り込めるか? 検証項目 ||||hg-svn||hg-git|| ||日本語||?||?|| -||取り込み(clone)||?|| +||取り込み(clone)||?||?|| ||アップデート||?||?|| ||マージ||?||?|| * 何処のリポジトリを使うか?]]>
@@ -18,16 +18,23 @@ * 1プラグイン1リポジトリ作成 * TracLightningからはmercurialのプラグインリポジトリをsubrepoで参照 * 独自の修正を加えていないプラグインはTracLightningのリポジトリに直接subrepoを作成。独自修正が入った時点でmercurialでクローンして管理する方式に変更(できるだけforkしたリポジトリ数を減らす) 確認事項 - * gitリポジトリはhgでcloneできるか? + * gitリポジトリはhgでcloneできるか? 更新を取り込めるか?(hg-gitを検証?) * svnリポジトリはhgで取り込めるか? svnのアップデートのマージをhgで取り込めるか? +検証項目 +||||hg-svn||hg-git|| +||日本語||?||?|| +||取り込み(clone)||?|| +||アップデート||?||?|| +||マージ||?||?|| + * 何処のリポジトリを使うか? - * bitbucket(王道) - * sf.jpのShibuya.trac/TracLightning(sf.jpのアカウントが利用できる) - * kanon-lab - * ciklone?(使わせて貰えれば) - * その他 + * bitbucket(王道) + * sf.jpのShibuya.trac/TracLightning(sf.jpのアカウントが利用できる) + * kanon-lab + * ciklone?(使わせて貰えれば) + * その他 == 移行方針 == * 取り敢えず、修正していないプラグインをsubrepoへ移行する * 修正したプラグインは量が多いので段階的に移行]]>
@@ -26,8 +26,11 @@ * sf.jpのShibuya.trac/TracLightning(sf.jpのアカウントが利用できる) * kanon-lab * ciklone?(使わせて貰えれば) * その他 +== 移行方針 == + * 取り敢えず、修正していないプラグインをsubrepoへ移行する + * 修正したプラグインは量が多いので段階的に移行 == 検討事項 == * cikloneのプラグインと共通化できないか? * マージしたときに、マージしたリビジョンをログに書くなど、規約を作成。]]>
@@ -11,56 +11,23 @@
=== Trac本体 ===
* bitbucketのミラーをクローンして管理するのがベター
* https://bitbucket.org/edgewall/trac
-=== Subversionで管理されているプラグイン ===
-新しいプラグイン管理用のリポジトリを作成します。例えば、traclightning-plugins(kanon-pluginsの方がいいか...)という名前にします。
-リポジトリ構成は、
-{{{
-/
- upstream/ (オリジナルのソースを管理)
- tracxxxplugin/
- tracyyyplugin/
- ...
- current/ (修正したソースを管理。★trunk/branchより0.11/0.12/0.13の方がよいか?)
- tracxxxplugin/
- trunk/
- branches/
- tracyyyplugin/
- trunk/
- branches/
- ...
- tags/ (TracLightningをリリースする際にリリースバージョンでタグを打つ)
- TL3.1.3
- TL3.2.0
-}}}
-とします。各プラグインの管理は、次のようにします。
-
- * upstreamにはプラグインのオリジナルをインポートします。
- * trunk(branches)でupstreamを修正したコードを管理します。
- * upstreamの変更は、 svn merge -rM:N http://... で行う。
-
-==== TODO ====
- * 何処のリポジトリを使うか?(sf.jp? kanon.ultimania.org?)
-
-=== Mercurialで管理されているプラグイン ===
-'''案1'''
-この方法は、hgで管理されているリポジトリ毎にミラーを作る方法です。
- * リポジトリのミラー(クローン)を作成します。ミラーしたリポジトリにtraclightning(or kanon)というブランチを作成し、プラグインの修正はそのブランチで管理します。
- * リポジトリはマスターと定期的に同期します。
- * 適当なタイミングで作成したブランチにマージします。
-'''案2'''
-適当なリビジョンでsvnにインポートし、svnにインポートしたupstreamをアップデートしながら管理。
-=== Gitで管理されているプラグイン ===
-'''案1'''
-この方法は、gitで管理されているリポジトリ毎にミラーを作る方法です。
- * リポジトリのミラー(クローン)を作成します。ミラーしたリポジトリにtraclightning(or kanon)というブランチを作成し、プラグインの修正はそのブランチで管理します。
- * リポジトリはマスターと定期的に同期します。
- * 適当なタイミングで作成したブランチにマージします。
-'''案2'''
-適当なリビジョンでsvnにインポートし、svnにインポートしたupstreamをアップデートしながら管理。
-=== その他のプラグイン ===
-tgzのバージョンやbzrのリビジョンなどを記録しておき、上記のsvnで管理。適当なタイミングでupstreamを更新し、trunk(branches)へマージ。
+=== プラグイン ===
+全部のプラグインをmercurialでクローンして管理
+ * mercurialでプラグインをクローンして管理
+ * 1プラグイン1リポジトリ作成
+ * TracLightningからはmercurialのプラグインリポジトリをsubrepoで参照
+ * 独自の修正を加えていないプラグインはTracLightningのリポジトリに直接subrepoを作成。独自修正が入った時点でmercurialでクローンして管理する方式に変更(できるだけforkしたリポジトリ数を減らす)
+確認事項
+ * gitリポジトリはhgでcloneできるか?
+ * svnリポジトリはhgで取り込めるか? svnのアップデートのマージをhgで取り込めるか?
+ * 何処のリポジトリを使うか?
+ * bitbucket(王道)
+ * sf.jpのShibuya.trac/TracLightning(sf.jpのアカウントが利用できる)
+ * kanon-lab
+ * ciklone?(使わせて貰えれば)
+ * その他
== 検討事項 ==
* cikloneのプラグインと共通化できないか?
* マージしたときに、マージしたリビジョンをログに書くなど、規約を作成。
]]>
@@ -4,11 +4,14 @@ また、TracLightningとKanonでプラグインが2重管理になっているのもなんとかしたいです。 そこで、プラグインをきちんと管理できるようにリポジトリ構成を変更したいと思います。 - == 管理案 == id:jun66j5さんのところでのプラグイン管理を習って次のようにしたいと思います。 + +=== Trac本体 === + * bitbucketのミラーをクローンして管理するのがベター + * https://bitbucket.org/edgewall/trac === Subversionで管理されているプラグイン === 新しいプラグイン管理用のリポジトリを作成します。例えば、traclightning-plugins(kanon-pluginsの方がいいか...)という名前にします。 リポジトリ構成は、]]>
@@ -39,17 +39,23 @@ ==== TODO ==== * 何処のリポジトリを使うか?(sf.jp? kanon.ultimania.org?) === Mercurialで管理されているプラグイン === +'''案1''' +この方法は、hgで管理されているリポジトリ毎にミラーを作る方法です。 * リポジトリのミラー(クローン)を作成します。ミラーしたリポジトリにtraclightning(or kanon)というブランチを作成し、プラグインの修正はそのブランチで管理します。 * リポジトリはマスターと定期的に同期します。 * 適当なタイミングで作成したブランチにマージします。 - +'''案2''' +適当なリビジョンでsvnにインポートし、svnにインポートしたupstreamをアップデートしながら管理。 === Gitで管理されているプラグイン === +'''案1''' +この方法は、gitで管理されているリポジトリ毎にミラーを作る方法です。 * リポジトリのミラー(クローン)を作成します。ミラーしたリポジトリにtraclightning(or kanon)というブランチを作成し、プラグインの修正はそのブランチで管理します。 * リポジトリはマスターと定期的に同期します。 * 適当なタイミングで作成したブランチにマージします。 - +'''案2''' +適当なリビジョンでsvnにインポートし、svnにインポートしたupstreamをアップデートしながら管理。 === その他のプラグイン === tgzのバージョンやbzrのリビジョンなどを記録しておき、上記のsvnで管理。適当なタイミングでupstreamを更新し、trunk(branches)へマージ。 == 検討事項 ==]]>
@@ -49,5 +49,9 @@ * リポジトリはマスターと定期的に同期します。 * 適当なタイミングで作成したブランチにマージします。 === その他のプラグイン === -(執筆中) +tgzのバージョンやbzrのリビジョンなどを記録しておき、上記のsvnで管理。適当なタイミングでupstreamを更新し、trunk(branches)へマージ。 + +== 検討事項 == + * cikloneのプラグインと共通化できないか? + * マージしたときに、マージしたリビジョンをログに書くなど、規約を作成。]]>