「VCS」の版間の差分

提供：senooken JP Wiki
(Specifying repositories)
(VCS-Gitに分離。)
 
(同じ利用者による、間の21版が非表示)
54行目: 54行目:
savaneはメンテナンスされていないので、Trac一択。redmineはCGIで動作しない。
savaneはメンテナンスされていないので、Trac一択。redmineはCGIで動作しない。


== Git ==
=== Commit ===
==== マージコミット後のコミット追加 ====
マージコミット後に次の開発作業を始めることが多い。が、直後の初回のコミットを追加したい場合困る。
git rebase -iにすると、コミットが残るから。編集はできるが、その直前にコミットの追加ができない。マージコミットは扱いが特殊で直接rebaseで編集できない。
しかたないので、該当コミットでブランチを作成して、コミット。その後、既存の修正ブランチをrebaseでそのコミットの後にくっつける。これでいける。
==== コミットオプション ====
[https://git-scm.com/docs/git-commit Git - git-commit Documentation]
コミットメッセージ指定のためのオプションがある。
* -m|--message <message>: コミットを文字列で指定。複数指定可能で、その場合段落で区切ってくれる。2行目以後を書きたい場合などで使う。
* -C|--reuse-message <commit>: 指定したコミットのコミット情報を再使用する。
* -c|--reedit-message <commit>: -Cの同じだが、編集画面を表示してコミットメッセージを編集して再使用する。
* -F|--file=<file>: 指定したファイルをコミットメッセージに使う。-を指定すると標準入力を使う。
基本は-m。-mの複数指定。
==== 過去コミットのメールアドレスの変更 ====
* [https://www.git-tower.com/learn/git/faq/change-author-name-email How can I change the author (name / email) of a commit? | Learn Version Control with Git]
* [https://zenn.dev/flyingbarbarian/articles/241627cae5988a Gitのcommitの名前やメールアドレスを過去からまとめて変更する]
単一コミットのメールアドレスを指定する場合、commitに--authorを指定する。
git commit --author="John Doe <john@doe.org>"
--amendと併用することで、過去コミットも変更できる。
数が少ないなら、rebase -iで1個ずつamendする。数が多いならfilter-branch。
==== 第一コミットの変更 ====
* [https://dev.classmethod.jp/articles/git-rebase-from-root/ [Git] 最初のコミットを含めてrebase -iする方法 | DevelopersIO]
* [https://git-scm.com/docs/git-rebase Git - git-rebase Documentation]
通常、第一コミットはammend以外では変更できない。
rebase --root [branch] でブランチの第一コミットも参照して改変可能。
==== マージコミットの打ち消し ====
マージコミットは扱いがやや特殊。
git revert -m 1 マージコミット
git reset --hard HEAD~1 # マージコミット前
どちらか。
=== stash ===
==== 復元 ====
[https://qiita.com/generosity-naman/items/237338f8fe5b7e3b9a76 Git Stashの復元: 誤って削除されたスタッシュの復元方法 #Git-Stash - Qiita]
git stash drop実行時に、削除したコミットのSHA1が表示される。
そのSHA1をapplyで指定すれば、取り込める。
git stash apply [stash_hash]
==== リモート ====
[https://qiita.com/mather314/items/a1536c52a2eb0426b2b5 gitの不要なブランチを消すコマンド #Git - Qiita]
git fetch -p/--prune
リモートの削除済みブランチをローカルに同期する。
==== リモートの最新タグ ====
https:/stackoverflow.com/questions/20734181/how-to-get-list-of-latest-tags-in-remote-git
git ls-remote --tag --sort=taggerdate
date関係のsortはオブジェクトへのアクセスが必要なので、ローカルにないとダメとか。
https:/git-scm.com/docs/git-ls-remote.html
https:/stackoverflow.com/questions/10649814/get-last-git-tag-from-a-remote-repo-without-cloning
git rev-listでいけそう。
https:/gist.github.com/rponte/fdc0724dd984088606b0
==== 差分ファイル抽出 ====
情報源: [https://qiita.com/kaminaly/items/28f9cb4e680deb700833 gitで差分ファイルを抽出する #Git - Qiita]。
git archiveとgit diffを組み合わせる。
git archive --format=zip --prefix=root/ HEAD `git diff --diff-filter=d --name-only HEAD^ HEAD` -o archive.zip
ただし、この方法はファイル数がARG_MAX以下の場合だけ。ファイル数が多い場合だめ。
git diff --name-onlyで一覧を出力させて、1個ずつcp -pで階層を維持してコピーするしかないかも？
例:
mkdir -p archive
git diff --name-only new_base 44765_upgrade-base-version | xargs -i cp -p --parent "{}" archive/
==== core.autocrlf ====
<blockquote>warning: in the working copy of 'docker/README.md', LF will be replaced by CRLF the next time Git touches it</blockquote>Windowsでは改行にCR+LFを使うが、mac/LinuxはLFのみ。これの違いの処理のための設定がcore.autoclrlf
* true=コミット時にCRLFをLFに自動変換。チェックアウト時に逆。Windows向けの設定。
* false=変換しない。
* input=コミット時にCRLFをLFに自動変換のみ。mac/Linux向け。Windowsではチェックアウト時にCRLFになるが、mac/LinuxはLFになる。
わかりにくい。基本はfalseで良いと思われる。
==== gitkの文字化け対策 ====
[https://www.pistolfly.com/weblog/2010/02/gitk.html gitkのエンコーディングを設定する - Pistolfly]
gitkはシステムのデフォルトエンコーディングで表示しようとするので、文字エンコーディングを指定しておく。
git config --global gui.encoding utf-8
==== ファイル名などの文字化け対策 ====
[https://qiita.com/kumazo/items/2169e1ee7be278f82b94 Git for Windows で日本語を使いたい #Vim - Qiita]
git config --global core.quotepath false
git config --global gui.encoding utf-8
==== 改名と修正 ====
* [https://qiita.com/yukimura1227/items/fbb076db61a2e43a32e3 gitでrename&modifyしたファイルのログを追跡できるようにしたい場合 #Git - Qiita]
* [https://zenn.dev/yoichi/articles/how-git-handles-renaming Gitはファイルのリネームをどう扱うか]
改名と修正を同時にすると、改名を検知できない。
-Mオプションを指定すると、類似度で同時も検知できる。が、基本はリネーム・改名と修正は別コミットにしたほうがよさそう。
==== 差分無視 ====
[https://qiita.com/odekekepeanuts/items/8a056b87c9e481e07e57 git diffの--ignoreオプションにおけるスペース、タブ、改行の扱いを理解する #Git - Qiita]
-wでインデント違いを無視してくれる。
==== squash ====
squashすると、squash対象コミットが、対象の直前のコミットに含められる。
==== gitignore ====
[https://git-scm.com/docs/gitignore/en Git - gitignore Documentation]
===== Format =====
記述方法を整理する。
* 空行は無視。
* #始まりの行はコメント扱い。
* 終端スペースは無視。
* !接頭辞はパターン否定。つまり、除外ではなく含める。以前除外された一致を再び含める。ただし、親ディレクトリーが除外されている場合、以下のファイルは含められない。パフォーマンス上の理由。順番に注意する。
* /はディレクトリー区切りとして使用。先頭、中間、末尾で登場する。
** 先頭と中間の/は相対パスを意味する。
** それ以外、末尾の/と/なしの場合、現在以下のディレクトリーにもマッチする。
** 末尾が/で終わる場合、ディレクトリーのみに一致。/がない場合、ディレクトリーとファイルの両方に一致。
* *は/以外にマッチ。?は/以外の任意の1文字にマッチ。[a-zA-Z] の範囲記法も使用可能。fnmatch(3) FNM_PATHNAMEフラグのパス名展開に準じる。
* **は特殊な意味がある。
** **/=全ディレクトリー。**/fooは配下の全fooにマッチ。**/foo/barはfoo以下の全barにマッチ。
** /**=配下のすべてにマッチ。
** a/**/b=a/b a/x/b a/x/y/bのすべてにマッチ。
後は特に明記がないが、上から順番に評価されて、最後のマッチが優先されるので、記述の順番に注意する。
反転の!と/の扱いに特に注意が必要。
先頭スラッシュをつけないと、再帰的になる。
    $ cat .gitignore
    # ディレクトリ foo/bar 以外のすべてを除外
    /*
    !/foo
    /foo/*
    !/foo/bar
===== 空ディレクトリーの維持 =====
[https://stackoverflow.com/questions/115983/how-do-i-add-an-empty-directory-to-a-git-repository How do I add an empty directory to a Git repository? - Stack Overflow]
gitは空ディレクトリーを履歴管理できない。何かファイルが必要。
logなど維持したい空ディレクトリーに、以下の内容の.gitignoreを置く。
!.gitignore
.gitignore以外を無視する。これで.gitignoreのみがあるので管理できる。
===== 指定ファイルのみ除外 =====
*
!.gitignore
ディレクトリーを残す以外 (.gitignore1ファイル以外) に、サンプルファイルなど複数ファイルを残したい場合は、上記のように*で最初に全部除外して指定ファイルのみ含める。/は必要に応じてつける。
==== gitattributes ====
[https://git-scm.com/docs/gitattributes Git - gitattributes Documentation]
gitignoreに似ていて、パターンにマッチしたパスに対する設定を行える。
* text
* eol
* working-tree-encoding
* ident
* filter
* diff
* merge
* conflict-marker-size
* whitespace
* export-ignore: git archiveなどに含めないことをマーク。
* export-subst
* delta
* encoding
==== ファイルのインデックスのみ削除 ====
git rmは単独だと、gitの履歴とローカルファイルからも削除する。追跡対象から削除のみで、ローカルファイルとして残したい場合、--cachedを指定する。
git rm --cached
=== gitk ===
==== problem ====
ブランチ名が長いと、右クリックしにくい
=== submodule ===
https://git-scm.com/docs/git-submodule
https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E3%82%B5%E3%83%96%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB
==== foreach ====
サブモジュールの全部を一括処理する。
foreach [--recursive] <command>
<command>部分では$sm_pathでパスを参照できる。
git submodule foreach 'echo $sm_path `git rev-parse HEAD`'
Entering 'XXX'
XXX hash
submoduleの中に入ってから実行することに注意する。
便利なコマンド。
git submodule foreach 'git reset --hard'
=== Other ===
==== 他のブランチとの同一化 ====
git diff HEAD master | patch -p 1
patchの他にgit applyでもいい。
==== .netrc ====
https://social.senooken.jp/conversation/1573147#notice-2217499
Gitのパスワード入力の省略方法に~/.netrcがある。
しかし、man netrcするとわかるけど、これはもともとFTPのためのもの。なぜGitで使えるんだ？Gitの文書で言及がない。
In conversation Thursday, 21-Feb-2019 10:58:47 JST from web permalink
せのお (妹尾 賢)せのお (妹尾 賢) in reply to
理由が分かった。
1. Gitはhttpとhttpsの通信にcURLを使っている。
<nowiki>https://github.com/git/git/blob/master/INSTALL#L141</nowiki>
2. cURLが.netrcにも対応しているから。
<nowiki>https://ec.haxx.se/usingcurl-netrc.html</nowiki>
== GitHub ==
=== Account ===
Username may only contain alphanumeric characters or single hyphens, and cannot begin or end with a hyphen.
ユーザー名は、英数字と-のみが使用可能。
組織別にアカウントを分けるなら、かぶらないように末尾に-組織名のようなサフィックスがあるとよいだろう。
== Fossil ==
* [https://gigazine.net/news/20231231-why-sqlite-does-not-use-git/ SQLiteがバージョン管理システムとしてGitを採用しない理由 - GIGAZINE]
* [https://gigazine.net/news/20201229-fossil/ GitとGitHubの機能をひとつのバイナリに詰め込んだ「Fossil」レビュー - GIGAZINE]
外部依存を排除しており、CGIでも動作するという点が非常に良い。気になる。Phorgeの検討が不要になる。
[https://fossil-scm.org/home/doc/trunk/www/index.wiki Fossil: A Coherent Software Configuration Management System]
いくつか癖があるので注意する。
https://chatgpt.com/c/674e38de-a8c0-800b-8991-e0d68a2f0d86
複数のリポジトリーを取り扱うことは可能。ただし、Web UI上からリポジトリーの新規作成はできない。リポジトリーの新規作成はあくまでコマンドラインから行う必要がある。ここは集中的。
[https://okamerin.com/nc/title/508.htm git と fossil の比較 git vs fossil-scm | タイトル]
完全に個人なら悪くないが、コマンドの操作体系も異なるし、ややリスクがある。Tracのほうが無難。
=== Install ===
==== Binary ====
[https://fossil-scm.org/home/doc/trunk/www/index.wiki Fossil: A Coherent Software Configuration Management System]
ソースコードからコンパイルするか、コンパイル済みバイナリーを配置するだけ。
VER=2.25
mkdir -p ~/.local/stow/fossil-$VER ~/.local/bin
cd ~/.local/stow/fossil-$VER
curl -O [https://fossil-scm.org/home/uv/fossil-linux-x64-2.25.tar.gz https://fossil-scm.org/home/uv/fossil-linux-x64-$VER.tar.gz]
tar -xf fossil-$VER.*
ln -fns ../stow/fossil-$VER/fossil
==== Server ====
[https://fossil-scm.org/home/doc/tip/www/server/any/cgi.md Fossil: Serving via CGI]
CGIで実行するにはいくつか手順がある。
CGIディレクトリーに以下の内容のCGIスクリプトを用意する。
#!/usr/bin/fossil
repository: /home/fossil/repo.fossil
repositoryの部分は指定方法がいろいろある。単一リポジトリーのホストなら上記でいいが、複数のリポジトリーを取り扱いたければ、リポジトリー群の格納ディレクトリーをdirectory: で指定する。
また、リポジトリーが不在の場合のリダイレクト先を指定するnotfound:もある。
#!/usr/bin/fossil
directory: /home/fossil/repos
notfound: <nowiki>http://url-to-go-to-if-repo-not-found/</nowiki>
CGIスクリプトをcgi-bin/repoとした場合、展開後は [http: //mydomain.org/cgi-bin/repo/XYZ] のようなURLで [/home/fossil/repos/XYZ.fossil] にアクセス可能。
CGIで展開されると。
fossil.cgiにする。
https://chatgpt.com/c/674e38de-a8c0-800b-8991-e0d68a2f0d86
fossilのweb uiではリポジトリーの新規作成ができない。新規作成だけはコマンドラインから行う必要がある。これだけがいまいち。保留。
== Phorge ==
== Phorge ==
[https://we.phorge.it/ Home]
[https://we.phorge.it/ Home]
558行目: 248行目:
Kallitheaをインストール。
Kallitheaをインストール。
  pip install --upgrade kallithea
  pip install --upgrade kallithea
ここの--upgradeがあるとまずい模様。
pip install kallithea
なんかエラーが出る。
なんかエラーが出る。
   ERROR: Command errored out with exit status 1:
   ERROR: Command errored out with exit status 1:
653行目: 345行目:


KallitheaはCGI未対応。見送ったほうがいいかも。
KallitheaはCGI未対応。見送ったほうがいいかも。
古いデータを削除してインストールし直したら、postgresqlでセットアップ成功した。
pip install kallithea
--upgradeがあるのがまずかった模様。
インストールできたので起動。
gearbox serve -c my.ini
ただ、WSGIをFastCGIにうまくやる方法などは見つからない。phorge/fossil/kallithea/tracと試して最終的にfossilになる感じ。


== Trac ==
== Trac ==

2025年1月9日 (木) 14:10時点における最新版

List

Comparison of issue-tracking systems - Wikipedia https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems

BTS。GitHubみたいな。PHP製の以下がよさそう。

  • Tuleap
  • Phabricator/Phorge: 共用サーバー不能。
  • MantisBT
  • FusionForge
  • GLPI
  • Faveo Helpdesk
  • sourcehut - the hacker's forge: Python製。FSF推奨。
  • Fossil

VCSとの統合状況がまちまち。

phorgeがダメだったので、Mantis/Fossil/sourcehutあたりが共用サーバーで検討可能か。

https://chatgpt.com/c/674f8938-8590-800b-9a4c-f1ec04fc5869

他に以下がある。

  • Gitea
  • Cgit
  • Gitlab
  • SourceHut: Python
  • GitBucket: Java

Gitlabは共用サーバーで可能なのか？無理。cgitの他、gogsもある？

CGIで利用可能なもの。

  • Cgit: gitの出力を見れるだけ。issueはない。
  • Gitweb: cgit同様。
  • ViewGit:
  • Kallithea: 有力。Kallithea。WSGI。CGI未対応。

他に。

「Pythonは人気の言語です。しかし、その割にPythonが気軽に利用できるレンタルサーバーは少ない感じがします。何故、レンタルサーバーはPythonの利用に消極的なのですか？ - Quora」にあるように、WSGIをCGIにすることもできるがいまいちらしい。

他。

https://chatgpt.com/c/67546eda-20ac-800b-b37f-7e8954c128f5

savaneはメンテナンスされていないので、Trac一択。redmineはCGIで動作しない。

Phorge

Home

PhorgeはPhabricatorのフォーク。

About

Introduction

◉ Introduction

以下が主な機能。

  • コードレビューツール=Differential
  • リポジトリーブラウザー=Diffusion
  • バグトラッカー=Maniphest
  • ウィキ=Phiriction

GitHubの自己ホスト。

Phabricator

Phabricator - Wikipedia

PhabricatorはもともとFacebook社内のBTSシステム。PHP製。2021-06-01に開発終了。

主なユーザー。

  • AngularJS
  • Discord
  • Facebook

Install

Requirement

LAMP環境で動作する。

共用ホストでも動作するが、一部機能しない。通常コンピューターを推奨している。

  • MySQL: 5.5以上。
  • PHP 7.2以上
  • git: 2.5.0以上。
  • PHP extension: mbstring, iconv, mysql (or mysqli), curl, pcntl

ドメインはサブディレクトリーはだめで、サブドメインじゃないとダメ。

Download

以下のコマンドで取得する。 

$ cd somewhere/ # pick some install directory
somewhere/ $ git clone https://we.phorge.it/source/arcanist.git
somewhere/ $ git clone https://we.phorge.it/source/phorge.git

gitの設定。 

$ sudo git config --system --add safe.directory somewhere/arcanist
$ sudo git config --system --add safe.directory somewhere/phorge

phorge用のDBを作っておく。 

cp /var/www/html/phorge/phabricator/conf/local/local.json.example /var/www/html/phorge/phabricator/conf/local/local.json

"mysql.host": "localhost", "mysql.user": "phorge", "mysql.pass": "password", "mysql.port": 3306, "mysql.charset": "utf8", "mysql.database": "phorgedb"

後は開くだけ。

実操作。

こういうディレクトリー構成想定。 

public_html
+ phorge.gnusocial.jp 公開ディレクトリー。
+ phorge phorge関係の格納場所。
  + phorge
  + arcanist

取得。 

TAG=2024.35
mkdir phorge
cd phorge
PKG=phorge
git clone --depth 1 https://we.phorge.it/source/$PKG.git
cd $PKG; git fetch --depth 1 origin tag $TAG; git checkout $TAG; cd ..
PKG=arcanist
git clone --depth 1 https://we.phorge.it/source/$PKG.git
cd $PKG; git fetch --depth 1 origin tag $TAG; git checkout $TAG; cd ..

git config --add safe.directory arcanist
git config --add safe.directory phorge

phorge/webrootが公開ディレクトリーになるので、これをシンボリックリンクで公開ディレクトリーにリンクする。 

DOMAIN=phorge.gnusocial.jp
ln -fns phorge/phorge/webroot ../$DOMAIN

「◉ Configuration Guide」に記載のあるリダイレクト設定をする。

以下相当の設定を行う。 

<VirtualHost *>
  # Change this to the domain which points to your host.
  ServerName phorge.example.com

  # Change this to the path where you put 'phorge' when you checked it
  # out from the upstream when following the Installation Guide.
  #
  # Make sure you include "/webroot" at the end!
  DocumentRoot /path/to/phorge/webroot

  RewriteEngine on
  RewriteRule ^(.*)$          /index.php?__path__=$1  [B,L,QSA]
</VirtualHost>


<Directory "/path/to/phorge/webroot">
  Require all granted
</Directory>

具体的には、phorge/webroot/.htaccessに以下を記載して、ファイルがなければ作成する。 

cat >phorge/webroot/.htaccess <<-'EOT'
RewriteEngine on
RewriteRule ^(.*)$ /index.php?__path__=$1 [B,L,QSA]
EOT

上記設定後phorge.gnusocial.jpにアクセスすると以下のエラーになる。 

Request parameter '__path__' is not set. Your rewrite rules are not configured correctly.

上記が少し参考になる。require指令を指定していないのが問題。

うーん。この問題を解決できない。調べても解決例が出てこない。断念する。他のソフトにする。

Config

◉ Configuration Guide

以下のコマンドでユーザーを認識させる。 

phorge/ $ ./bin/storage upgrade --user <user> --password <password>

Diffusion

Hosting

◉ Diffusion User Guide: Repository Hosting

Kallithea

Kallithea

https://chatgpt.com/c/674f8938-8590-800b-9a4c-f1ec04fc5869

Python 3.6でCGIでも動作する管理ソフト。

Kallithea Documentation — Kallithea 0.7.0 documentation

紹介: GitとMercurialに対応のリポジトリ管理ツール「Kallithea」 - ファーエンドテクノロジー株式会社

Administrator guide

Installation on Unix/Linux

Installation on Unix/Linux — Kallithea 0.7.0 documentation

ディレクトリー構造

https://chatgpt.com/c/674f8938-8590-800b-9a4c-f1ec04fc5869 

/var/www/kallithea/
├── config/                  # 設定ファイルやシークレットを保存
│   └── kallithea.ini        # Kallitheaのメイン設定ファイル
├── data/                    # データベースや一時ファイル用ディレクトリ
│   ├── db.sqlite            # SQLiteの場合のデータベースファイル
│   └── sessions/            # ユーザーセッションデータ
├── logs/                    # ログファイル保存ディレクトリ
│   └── kallithea.log        # メインのアプリケーションログ
├── repos/                   # Git/Mercurialリポジトリを保存するディレクトリ
│   ├── project1.git/        # プロジェクト1のGitリポジトリ
│   └── project2.hg/         # プロジェクト2のMercurialリポジトリ
├── static/                  # 静的ファイル（JavaScript, CSS, 画像など）
│   ├── css/
│   ├── js/
│   └── img/
└── venv/                    # Python仮想環境
    ├── bin/
    ├── lib/
    └── ...

static配下が公開ディレクトリー。共用サーバーの場合。public_htmlにkallitheaとkallithea.domainでシンボリックリンクでやるとよさそう。

Installing a released version in a virtualenv

いくつか方法があるが、virtualenvが推奨されている。

coreserver v1のpythonはpython 3.6だった。 

cd public_html/
DOMAIN=kallithea.gnusocial.jp
cd $DOMAIN
python3 -m venv venv

python3 -m venv venvの実行時に以下のエラー。 

Error: Command '['/virtual/senooken/public_html/kallithea.gnusocial.jp/venv/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 2.

cimg/pythonでvenvによる仮想環境の作成がエラーになる #Python - Qiita

pipが見つからないのが原因の模様。--without-pipでインストールして、仮想環境内にpipを直接インストールする。 

python3 -m venv --without-pip venv
. venv/bin/activate
curl https://bootstrap.pypa.io/pip/$(python3 -V | grep -o '[0-9].[0-9]')/get-pip.py -o get-pip.py
python3 get-pip.py
pip install --upgrade pip

OK。以下のコマンドで基本要件を確実にする。 

pip install --upgrade pip "setuptools<67"

Kallitheaをインストール。 

pip install --upgrade kallithea

ここの--upgradeがあるとまずい模様。 

pip install kallithea

なんかエラーが出る。 

  ERROR: Command errored out with exit status 1:
   command: /virtual/senooken/public_html/kallithea.gnusocial.jp/venv/bin/python3 -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/export/tmp/pip-install-4k2ozlqh/formencode_9f25a10925bf49da975ba94c0fbba946/setup.py'"'"'; __file__='"'"'/export/tmp/pip-install-4k2ozlqh/formencode_9f25a10925bf49da975ba94c0fbba946/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base /export/tmp/pip-pip-egg-info-kjtbdngw
       cwd: /export/tmp/pip-install-4k2ozlqh/formencode_9f25a10925bf49da975ba94c0fbba946/
  Complete output (3 lines):
  /usr/lib64/python3.6/distutils/dist.py:261: UserWarning: Unknown distribution option: 'convert_2to3_doctests'
    warnings.warn(msg)
  error in FormEncode setup command: use_2to3 is invalid.
  ----------------------------------------
WARNING: Discarding https://files.pythonhosted.org/packages/2f/53/707c2b9b65ea6bedde67c21cbf7c71394f4a198620d4e9c1771214b91dcc/FormEncode-1.3.1.tar.gz#sha256=ada2f51792b1b484e5bb7b6cc14acfc1bc11fafc967cf015cd57e856053ca7f6 (from https://pypi.org/simple/formencode/). Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.
Collecting kallithea

[error in FormEncode setup command: use_2to3 is invalid.]

急にpip installで一部のライブラリのインストールが失敗するようになった件 #Python3 - Qiita

setuptoolsを58.0.0未満にすればいいらしい。 

pip install setuptools==57.4.0

この実行後pip install --upgrade kallitheaが成功。

Prepare front-end files

以下のコマンドでフロントエンドを用意。 

kallithea-cli front-end-build

事前にnpmが必要な模様。 

FileNotFoundError: [Errno 2] No such file or directory: 'npm': 'npm'

npmをインストールしたら解決。

Setup

Setup — Kallithea 0.7.0 documentation

Setting up a Kallithea instance

まず以下のコマンドでmy.iniを作成する。 

kallithea-cli config-create my.ini http_server=waitress

http_serverのところで使用するHTTPサーバー種別を指定する。waitress, gearbox, gevent, gunicorn, or uwsgi.を指定可能。

ひとまずデフォルトのこれで。

続いてDBを作成する。PostgreSQL/SQLIte/MariaDB/MySQLに対応。最初はSQLiteを使用しておいて、後で他のDBへのアクセスが推奨されている。

が、共用サーバーだと書き込みでプロセス削除されると嫌なので最初からMariaDBにする。まず以下のコマンドでドライバーを取得。 

 pip install mysqlclient

 OSError: mysql_config not found

mariadbは違う模様。以下の開発パッケージが必要らしい。 

 sudo apt-get install libmysqlclient-dev

不明。一旦スキップ。

SQLite以外を使う場合、my.iniでsqlalchemy.urlのコメントアウトを解除してDBのユーザー名とパスワードを記入しておく。 

#########################
##      DB CONFIG      ##
#########################

#sqlalchemy.url = sqlite:///%(here)s/kallithea.db?timeout=60
#sqlalchemy.url = postgresql://kallithea:password@localhost/kallithea
#sqlalchemy.url = mysql://kallithea:password@localhost/kallithea?charset=utf8mb4
sqlalchemy.url = mysql://[username]:[password]@localhost/kallithea?charset=utf8mb4
## Note: the mysql:// prefix should also be used for MariaDB

用意したら以下のコマンドで初期テーブルを作成する。 

kallithea-cli db-create -c my.ini --reuse

--reuseを指定しないと、DBやアカウントを作るところからやる。

my.ini内の情報はオプションでも指定できる。 

kallithea-cli db-create -c my.ini --user=nn --password=secret --email=nn@example.com --repos=/srv/repos

以下のエラー。 

ModuleNotFoundError: No module named 'MySQLdb'

mariadb_configをコピーするとか。共用サーバーだとこの問題の対応が難しいかもしれない。PostgreSQLでやり直す。

postgresqlを使うようにmy.iniを直して実行すると以下のエラー。 

ModuleNotFoundError: No module named 'psycopg2'

インストールしてみる。 

pip install psycopg2

動作した？以下の質問がきた。 

Are you sure to destroy old database? [y/n]y

sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) FATAL:  password authentication failed for user "senooken_kallithea"

p

パスワードを間違えた？yだと全削除になるからかな。nなら何も出なかった。

my.iniの指定がまずかった。 

#sqlalchemy.url = postgresql://kallithea:password@localhost/kallithea
sqlalchemy.url = postgresql://senooken_kallithea:WkiXF3w7d@localhost/senooken_kallithea

DBの指定も必要。

実行ログを見るといかが出ている。 

/virtual/senooken/public_html/kallithea/venv/lib64/python3.6/site-packages/psycopg2/__init__.py:144: UserWarning: The psycopg2 wheel package will be renamed from release 2.8; in order to keep installing from binary please use "pip install psycopg2-binary" instead. For details see: <http://initd.org/psycopg/docs/install.html#binary-install-from-pypi>.
  """)

インストールし直す。 

pip install psycopg2-binary

実行し直し。 

sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) connection to server at "localhost" (::1), port 5432 failed: FATAL:  password authentication failed for user "senooken_kallithea"

若干内容が変わる。ポート番号が怪しい。タイムオーバー。

https://chatgpt.com/c/67547095-c29c-800b-9530-650c7ff70756

KallitheaはCGI未対応。見送ったほうがいいかも。

古いデータを削除してインストールし直したら、postgresqlでセットアップ成功した。 

pip install kallithea

--upgradeがあるのがまずかった模様。

インストールできたので起動。 

gearbox serve -c my.ini

ただ、WSGIをFastCGIにうまくやる方法などは見つからない。phorge/fossil/kallithea/tracと試して最終的にfossilになる感じ。

Trac

https://chatgpt.com/c/67546eda-20ac-800b-b37f-7e8954c128f5

The Trac Project

Demo: Trac Demo 1.4 (トップ画面の右上 [Try out our demos!])。

CGIで動作するリポジトリー統合のあるBTS。

デフォルトでは画面からリポジトリーは追加できない。設定ファイルの変更などで行う。

About

有名プロジェクト

Host

Install

TracInstall – The Trac Project

TracFastCgi – The Trac Project

tags/trac-1.6 の INSTALL.rst – The Trac Project

Trac 1.6 を Docker で建てる

http s://chatgpt.com/c/675504b7-29c0-800b-bb09-5e8a24709488

「tags/trac-1.6 の INSTALL.rst – The Trac Project」を参考に取り組む。

Installing Trac

Directory

https://chatgpt.com/c/6763470f-c474-800b-90d1-33febab854bf

tracは複数プロジェクトを管理することができる。その場合、プロジェクト全体の共通リソースの参照などの都合があるので、プロジェクト全体の親ディレクトリーとしてtracを配置するのがよいと思われる。 以下のディレクトリー構成を踏襲する。 

/var/www/trac/
├── project/                    # プロジェクト親ディレクトリー
│   ├── project1/        # プロジェクト1
│   └── project2/         # プロジェクト2
└── venv/                    # Python仮想環境
    ├── bin/
    ├── lib/
    └── ...

/var/www/trac.example.com/
+--trac  自分でcgi-bin/trac.fcgiのシンボリックリンクにするなど。このfcgiがvenvの実態で、プログラムでprojectディレクトリー内やDBの情報で応答する。
+--cgi-bin/
|  +-- trac.fcgi
+--htdocs
   +--common
   +--site

複数のtrac環境がある場合、プロジェクト名部分がURLで分かれる模様。

  • PC: trac/project/project1/htdos/your_project_logo.png
  • URL: /trac/project1/chrome/site/your_project_logo.png

プロジェクト別のリソース類は、URL上はproject1/chrome/siteになるが、実際のファイルはproject1/htdocsになる。公開ディレクトリーになくてもOK。

trac-admin deployすると、tracのファイル類を公開ディレクトリーにコピーしてくれる。

ただし、このコマンドはstandaloneサーバーで実行するなら不要。公開ディレクトリーはプロジェクトの共通リソース (htdocs) やcgi-binの配置などで使用する。

CGIスクリプトが、プロジェクト自体のデータ類は応答してくれる。1サーバーでの複数プロジェクト管理などする場合、trac.iniのhtdocs_dirやhtdocs_locationで指定すると、こちらの公開ディレクトリーのリソースを参照できる。指定しなかったら、プロジェクト環境内のファイルの参照になる。結果は同じだが、共通にしておくと効率は良い。

しなくても問題はない。

Install

インストーラーやOSのパッケージマネージャーを使う方法もある。公式の推奨はpipの模様。 

pip3 install --user trac

レンタルサーバーのpip3を使うと以下のエラー。 

PermissionError: [Errno 13] Permission denied: '/etc'

venvを挟む。 

mkdir -p ~/public_html/trac
cd ~/public_html/trac
python3 -m venv --without-pip venv
. venv/bin/activate
curl https://bootstrap.pypa.io/pip/$(python3 -V | grep -o '[0-9].[0-9]')/get-pip.py -o get-pip.py
python3 get-pip.py
pip install --upgrade pip

pipの環境ができたのでtracをインストールする。 

pip3 install trac

trac-1.6をこれでインストールできた。

必要な依存関係をインストールする。 

trac-admin [project] initenv

プロジェクトディレクトリーとプロジェクト名の命名に悩む。

Tracはプロジェクトという単位で管理する。1個のプロジェクトに関連するリポジトリーを複数まとめることは可能。fossil同様設定ファイルなどで手動で管理する。が、サードパーティープラグインでWeb UIから追加も可能。デフォルトでも親ディレクトリーを指定することで、複数プロジェクトを想定した動作は可能。

例えば、gnusocial/GNU socialというような形。

TracAdmin – The Trac Project

initenvは後ろにプロジェクト名とdbを指定できる。 

trac-admin <project> initenv [<project name> <db>]

[project]/conf/trac.iniの以下に反映される。

  • <project name>=project.name
  • <db>=trac.database (初期値=sqlite:db/trac.db)

https://chatgpt.com/c/67561e46-db8c-800b-80e8-b3f90bab4247

mysqlを使う場合、mysql:

mysql:host=localhost;port=3306;dbname=your_database_name

TracEnvironment – The Trac Project

DB文字列の書式 

mysql://username:password@host:port/dbname

[:]区切りの部分は順不同の模様。 

trac-admin gnusocial initenv 'GNU social' 'mysql://senooken_trac:password@localhost/senooken_trac';

localhostは省略不能。

TracInstall – TogoRDF

tracのmysql対応が不十分の模様。

PyMySQLモジュールを使う

MySqlDb – The Trac Project 

 pip install PyMySQL

コマンドを実行したらいかが表示される。 

Creating a new Trac environment at /virtual/senooken/public_html/trac/gnusocial

Project environment for 'GNU social' created.

You may configure the environment by editing the file:

  /virtual/senooken/public_html/trac/gnusocial/conf/trac.ini

You can run the Trac standalone web server `tracd` and point
your browser to http://localhost:8000/gnusocial.

  tracd --port 8000 /virtual/senooken/public_html/trac/gnusocial

Navigate to "Help/Guide" to browse the documentation for Trac,
including information on further setup (such as deploying Trac
to a real web server).

The latest documentation can also be found on the project
website:

  https://trac.edgewall.org/

これでコマンドでローカルサーバーを起動できるようになっている。

Deploying Trac

Runnning the Stadaalone Server

以下のコマンドでローカルサーバーで起動。 

tracd --port 8000 </path/to/myproject>

このあと [http://localhost:8000] で開ける。tracdが把握する全環境を表示して、/myprojectで該当プロジェクトを開ける。なお、プロジェクトが1個の場合-sをつけると/myprojectのパスがトップディレクトリーになる模様。

Running Trac on a Web Server

単独サーバーではなくWeb Server経由で実行することもできる。

FastCGIでの動作なら共用サーバーでも稼働可能。

Generating the Trac cgi-bin directory

CGI用のスクリプトはtrac-admin deplyコマンドで生成する。 

trac-admin /var/trac/<project> deploy var/www
ls /var/www

cgi-bin htdocs

chmod ugo+x /var/www/cgi-bin/*

cgi-bin/は以下がある。 

trac.cgi  trac.fcgi  trac.wsgi

実手順。 

cd ~/public_html/trac
trac-admin gnusocial deploy .

ls
cgi-bin  get-pip.py  gnusocial  htdocs  venv

htdocsにはcommon siteがある。

trac-admin gnusocial deploy .でhtdocs配下にプロジェクトファイル群が共通で格納される模様。このhtdocsをdocument rootの公開ディレクトリにシンボリックリンクを作成するとよさそう。

Mapping Static Resources

tracの主な2個の静的リソースのURLパスが/chrome/commonと/chrome/site。追加で/chrome/<plugin>

deployコマンドは以下のディレクトリーを作成する。

  • common/: tracの静的リソース。
  • site/: htdocsのコピー。
  • shared: 複数のtracで共有する静的リソース。場所は[inherit].htdocs_dirで定義。
  • <plugin>/

なお、静的リソースURLパスはtrac.iniで制御している 

[trac]
htdocs_location = http://static.example.org/trac-common/

上記設定に加えて以下のシンボリックリンク作成でchromeではなくtrac-commonを使える。 

ln -s /path/to/trac/htdocs/common /var/www/static.example.org/trac-common

ここのパスがよくわからない。deployでtrac.gnusocial.jpを指定したほうがいいのかもしれない。

FastCGI

よくある質問 | サポート | レンタルサーバー CORESERVER（コアサーバー）

CORESERVERでFastCGIの実行。

/public_html/.fast-cgi-bin/ 内のphpXX.fcgiを編集。コントロールパネルのPHP設定でバージョンを指定。その後該当のphpXX.iniが対応公開ディレクトリーの処理スクリプトになる。

trac.fcgiをphp81.fcgiに改名して、その後バージョンをコントロールパネルからphp81にする。これでOK。

シンボリックリンクのほうがいいか。 

cd ~/public_html
cp php81.fcgi php81.fcgi.old
ln -fns ../trac/cgi-bin/trac.fcgi php81.fcgi

これだとダメ。

ChatGPTに記載のあった.htaccessをtrac.gnusocial.jpに配置したらそれで動作した。CORESERVERのFastCGIはPHPのみの模様。 

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /cgi-bin/trac.cgi/$1 [L]

これでtrac.gnusocial.jpを開くと開けた。

ただし、基本のURLパスが [https://trac.gnusocial.jp/cgi-bin/trac.cgi/timeline] のようにcgiのパスがつくようになる。

なんか違う気がする。

元々の.fast-cgi-bin/php81.fcgiにtrac.fcgiのシンボリックリンクを配置した後。trac.gnusocial.jpにindex.phpを配置したら動作した？パスにindex.phpが入るようになったが。

https://chatgpt.com/c/6758c79e-f2e4-800b-88e2-7eab678f03f2

CGIだとCGI用のパスが入るのはしかたない模様。

https://chatgpt.com/c/6758c79e-f2e4-800b-88e2-7eab678f03f2

リダイレクトして隠す。 

RewriteEngine On
RewriteRule ^app$ /cgi-bin/script.cgi [L]

上記設定により、example.com/app というURLで cgi-bin/script.cgi が動作します。

以下の.htaccessで/gnusocialにアクセスでFastCGIで動作する。 

<FilesMatch gnusocial$>
        SetHandler fcgid-script
</FilesMatch>

が、これだとgnusocial/chromeなどのリソースを配置できない。惜しい。別でやる方法があるのか？

TracFastCgi – The Trac Project

fcgiのスクリプト内でディレクトリーを環境変数で設定できる。 

os.environ['TRAC_ENV_PARENT_DIR'] = "/path/to/project/parent/dir"

TRAC_ENV_PARENT_DIRかTRAC_ENVのどちらかがあればいい。複数プロジェクトを想定するなら、PARENT_DIRでOK。

「TracInstall – The Trac Project」にあるように、他にtrac.htdocs_locationで設定する。これがいいか。

https://chatgpt.com/c/6761f851-df0c-800b-86e9-1624b458d66d

FastCGIやCGIだと実際のアクセスパスは/cgi-bin/fast.cgiやfast.cgiなどのように、バイナリーのパスになる。これは回避不能。

としたら、画像類のパスはその下の階層にはできない。 

/var/www/html/
    ├── images/
    │   ├── logo.png
    │   ├── background.jpg
    ├── css/
    │   └── style.css
    ├── js/
    │   └── script.js
    └── cgi-bin/
        └── app.fcgi

こんな感じで、fast.cgiと同じか横になる。今回の場合、public_html/gnusocialとpublic_html/gnusocial-htdocsのような感じにする。これでOK。

TRAC_ENV_PARENT_DIR環境変数を設定すると、1個のFastCGIで複数プロジェクトを配置するだけで自動認識してくれる。

が、パス設定が少々ややこしくなる。

http://yourserver/trac/project1 のtracがfasccgiのファイルになる。

Permission system

TracPermissions – The Trac Project

デフォルトで未ログインユーザーはanonymousという名前のユーザー扱い。

SimpleMultiProject

TracMultipleProjects – The Trac Project

https://chatgpt.com/c/675504b7-29c0-800b-bb09-5e8a24709488

SimpleMultiProjectPlugin – Trac Hacks - Plugins Macros etc.

Tracはもともと単一プロジェクトの管理用だが、外部プラグインで複数プロジェクトの管理も可能。

一番開発が盛んで安定していそうなのが、SimpleMultiProjectPlugin 

pip install TracSimpleMultiProject

これだと配置がわからない。ソースコードからダウンロードする。 

curl -o simplemultiprojectplugin.zip  https://trac-hacks.org/browser/simplemultiprojectplugin?rev=18669&format=zip

pip download TracSimpleMultiProject
tar -xf TracSimpleMultiProject-*.tar.gz
cd TracSimpleMultiProject-*/
python setup.py bdist_egg
cp dist/TracSimpleMultiProject-0.7.4-py3.6.egg  ../../gnusocial/plugins/
trac-admin gnusocial upgrade
trac-admin "/virtual/senooken/public_html/trac/gnusocial" wiki upgrade

手順に従って、インストールしたが、プラグインのバージョンが古いのか動作しない。

しかたないので、最初から複数プロジェクトも対応したApache Bloodhoundを試す。

いや、Apache Bloodhoundは開発停止しているからやめたほうがいい。Tracで基本は単一プロジェクトで、OSGeoと同じで手作業でプロジェクトを分けたほうがいい。

Authentication

根本的な認証方法として、以下の2種類がある。

  • Trac標準のHTTP認証
  • AccountManagerPlugin

Tracの標準では、Basic/DigestのHTTP認証で管理者アカウントを認証して、後はユーザー設定などで管理する。

他に、AccountManagerPluginでフォーム認証できる。

プラグインでの認証のほうが融通が効いて扱いやすいのでこちらで行うと良い。

HTTP authentication

「TracAuthenticationIntroduction – The Trac Project」が一番まとまっている模様。

インストール後、管理者アカウントを作らないとログインできない。

インストール方法別に、認証方法がある。

基本的な考え

  • サイト全体の認証
  • 一部の認証=各プロジェクトの/loginにのみHTTP認証が必要。
    • Basic認証: パスワードをBase64で送信。HTTPSで送信すれば盗聴はされないが、生のパスワードを残す。ただし、シンプル。
    • Digest認証: パスワードをハッシュ関数で暗号化する。主にHTTPを使えない環境用。

Digest認証でやる。 

htdigest -c /path/to/.htdigest TracRealmName UserName
htdigest -c .htdigest TracRealmName admin

.htaccessに以下の内容を記入する。 

cd ~/public_html/trac.gnusocial.jp
cat <<-'EOT' >>.htaccess
AuthType Digest
AuthName "TracRealmName"
AuthDigestProvider file
AuthUserFile /virtual/senooken/public_html/trac/.htdigest 
Require valid-user
EOT

コマンドで管理者アカウントを作ってやる感じだと思う。 

# trac-admin /path/to/myproject permission add admin TRAC_ADMIN
trac-admin gnusocial permission add admin TRAC_ADMIN

これでtrac.gnusocial.jpを開くとWebブラウザーのログインダイアログが表示されて、adminでログインできる。

ログアウトは [任意の文字@domain] でWebブラウザーにアクセスするとできるらしい (Basic認証のキャッシュを削除する（ログアウトする） | DevelopersIO)。

複数プロジェクトでの認証設定方法がいくつかある。

1点目は、/tracに設定する。ただし、この方法はanonymousユーザーの閲覧を拒絶する。非公開サービスならいいのだけど。

2点目はhttpd.confを使える場合、以下のようにLocationMatchで各プロジェクトの/loginに設定する。共用サーバーだと無理。 

<LocationMatch "/projects/[[:alnum:]]+/login">
	AuthType Basic
	AuthName "trac"
	AuthUserFile /path/to/trac.htpasswd
	Require valid-user
</LocationMatch>

3点目はプロジェクトごとの/loginに設定する。これが無難か。

4点目、1点目+3点目。/tracで認証設定するが、anonymousユーザーの閲覧を許可する。

AccountManagerPlugin

Install
pip install TracAccountManager

インストール後の設定は [CookBook/AccountManagerPluginConfiguration – Trac Hacks - Plugins Macros etc.] を参考にする。「AccountManagerPlugin/Modules – Trac Hacks - Plugins Macros etc.」も情報源。

AMPの認証方式が4種類ある (AccountManagerPlugin/AuthStores – Trac Hacks - Plugins Macros etc.)。

  • PasswordFileStores
    • HtDigestStore: htdigestファイル形式でパスワードを保存。
    • HtPasswdStore: htpasswd形式で保存。
  • HttpAuthStore: 認証をWebサーバーに移譲。LDAPなどの組み合わせでアクセスを制御可能。ただし、ユーザーの一覧表示、追加、削除、パスワード変更に未対応。
  • SessionStore: パスワード情報をDBに保存。ユーザーが多数いてパスファードファイルへの書き込み競合エラーが起こるならこれ。
  • SvnServePasswordStore: tracユーザーに加えて、SVNユーザーも使用可能にする。

https://chatgpt.com/c/6763470f-c474-800b-90d1-33febab854bf

SessionStoreでいい気がする。DBに保存しておくのが一番。

trac.iniに以下を記述する。 

[account-manager]
hash_method = HtDigestHashMethod
db_htdigest_realm = TracDB
password_store = SessionStore
reset_password = false

[components]
acct_mgr.admin.* = enabled
acct_mgr.api.* = enabled
acct_mgr.db.sessionstore = enabled
acct_mgr.htfile.* = disabled
acct_mgr.http.* = disabled
acct_mgr.notification.* = enabled
acct_mgr.pwhash.htdigesthashmethod = enabled
acct_mgr.pwhash.htpasswdhashmethod = disabled
acct_mgr.register.* = enabled
acct_mgr.svnserve.svnservepasswordstore = disabled
acct_mgr.web_ui.* = enabled
acct_mgr.web_ui.resetpwstore = disabled
trac.web.auth.loginmodule = disabled

この状態でWebブラウザーでtracの画面 (https://trac.gnusocial.jp/trac/gnusocial/) を開き [Login] を選ぶ。

Wizard

自動でログインして、初回登録時の設定画面 (Accounts: Configuration) が表示されるので、順番に初回設定する。

特に重要な設定だけ記載する。

  • Step 1
    • Authentication Frond-end=[◎Use a HTML login form backed by one or more password stores managed by AccountManagerPlugin.]: これを選ぶことでプラグインのフォーム認証を使う。
    • 上記以外は初期値のままでも問題はない。
  • Step 6: 初期管理者アカウントを作成する。TRAC_ADMIN権限を保有するアカウントを1個作る。adminなどの専用ユーザーにするとよい。

最後に [Apply changes] で完了。

Component

AMPはいくつかの部品から構成されており、それぞれの部品の設定で機能を変更できる。

特に重要なのは以下。

  • AccountManagerAdminPanel
  • AccountGuard
  • RegistrationModule
  • EmailVerificationModule

Repository

TracRepositoryAdmin – The Trac Project

インストールの最後の手順にリポジトリーの設定がある。

以下の流れで設定する。

  1. コンポーネントの有効化
  2. リポジトリーを追加。

Enabling the components

VCSサポートは同梱されているが、デフォルトでは無効になっており、明示的に有効化が必要。

trac.iniに以下を記載するか、プラグイン管理ページからも有効にできる。 

tracopt.versioncontrol.svn.*  = 有効
tracopt.versioncontrol.git.*  = 有効

Web UIだと以下があった。

  • tracopt.versioncontrol.git.git_fs.*
    • CsetPropertyRenderer
    • GitConnector
    • GitwebProjectsRepositoryProvider

管理画面場は全項目が表示されている。全部チェックする。gitは「TracGit – The Trac Project」が公式情報源。だが、細かい設定の説明はない。

GitConnectorに (最低限) チェックすると、管理画面の左下に [Version Control] が登場する。

Specifying repositories

tracは環境ごとに複数のリポジトリーに対応している。リポジトリーごとに異なるVCSでも問題ない。

Default Repository

tracのリポジトリーは[Browse Source]の[Repository Index]で一覧される。デフォルトリポジトリーが最初に表示される。パス指定のないリポジトリー名 ([1/repos1]ではなく[1]の形式) のTrackLinks (trac内の自動ハイパーリンク機能) はデフォルトリポジトリーを参照する。

[Repository Admin] ページで、デフォルトリポジトリーは [Name] 属性を空にすることで指定する。コマンドラインで指定する場合、(default)か""で指定する。TracIniでは .dir = /path/to/dirのように、{name}.{attbitute}の{name}を空にする。

Repository Attributes

リポジトリーは以下の属性の定義が必須。

  1. name属性
  2. aliasかdir属性

他にもあるが、それらは任意。

Attbitute Description
alias 実リポジトリーのエイリアス。aliasとdirは二者択一で必須。既存の他のnameを指定して別名で流用する。既存のリポジトリーを別名で参照したい場合などに使用。あまり使わないか。
cached
description
dir ファイルシステム上のリポジトリー位置を指定。aliasとdirは二者択一で必須。
hidden
name リポジトリー名。必須。
In the database

リポジトリーはデータベース内でも指定できる。管理ページの [Version Control]-[Repositories]か、trac-admin $ENV repositoryコマンドで行う。trac.iniで定義されたリポジトリーは表示されるが、編集不能。

管理画面から追加・編集してDBで管理するのが楽な気がする。

In trac.init

リポジトリーとリポジトリー属性はtrac.iniの[repositories]セクションでも指定できる。

  • 利点: DBでの登録と異なり、global configurationから設定を継承できる点。
  • 欠点: trac.iniのパーサーの都合でリポジトリー名が常に小文字になる。

リポジトリー名に制約が生じるので使わなくていい気がする。

In GitWeb

TracIni – The Trac Project

Gitには同梱されるWebベースのビューアーのGitWebがある。Tracはgitwebで使用するproject.listsを読み込める。trac.iniの[gitweb-repositories]で設定する。

[gitweb-repositories]

projects_base git プロジェクトのベースディレクトリのパスを指定します。 (デフォルトなし)
projects_list gitweb 形式の projects.list ファイルへのパスを指定します。 (デフォルトなし)
projects_url プロジェクト URL のテンプレート。%s はリポジトリ名に置換されます。 (デフォルトなし)
sync_per_request リクエストごとに同期を行うリポジトリを指定します (非推奨)。 (デフォルトなし)

Repository synchronization

明示的、暗黙的な2種類の同期が可能。

Explicit synchronization

推奨される同期方法。リポジトリーのpost-commitにtrac-adminの呼び出しが必要。また、リポジトリーがリビジョンメタデータの変更を許可するなら、post-revprop-changeフックにもtrac-adminの呼び出しが必要。

Per-request synchronization

暗黙な同期方法。非推奨。post-commitフックが利用できない場合に使う。

trac.iniとDBのリポジトリーごとのsync_per_requestをtrueにする。

フックが呼ばれないので、変更セットの追加、変更イベントに依存するプラグインはうまく動作しない。例えば、[automatic changeset references]は使用不能。

Automatic changeset references in tickets

変更がリポジトリーにコミットされるたびに、コミットへの参照をチケットコミットに自動追加できる機能がある。参照の自動追加はコミットメッセージに以下のいずれかのパターンが条件。

  • Refs #123 #123チケットでこの変更を参照。
  • Fixes #123 デフォルトステータス [fixed] の#123チケットでこの変更を参照して終了する。

この機能はpost-commitフックの設置が必要で、以下の設定が必要。 

tracopt.ticket.commit_updater.* = enabled

詳細は CommitTicketUpdater (CommitTicketUpdater – The Trac Project) にある。

Plugin

Detection

tracのプラグインは以下のどちらか。

  • 単一ファイル (.py)
  • パッケージ (.egg/.whl)

tracでは、プラグインを以下から検索する。

  • Pythonのsite-packagesディレクトリー
  • グローバル共有plugins
  • プロジェクトのplugins

プロジェクトのtrac.initの[components]で明示的に無効にしない限り、有効になる。上記以外にインストールした場合、[components]で明示的に有効化が必要。

Install

単一プロジェクトとプロジェクト全体とでインストール方法が若干異なる。

All project

pipでインストールする。

グローバルにインストールしたプラグインは、trac.iniのcomponentsで明示的に有効化が必要。なお、Webの管理画面からもオン・オフ可能。

なお、プラグインの検知には、再起動が必要。

プラグインのインストール結果は、trac-admin plugin listで確認できる。 

trac-admin /path/to/trac/environment plugin list


Apache Bloodhound

Apache Bloodhound

Apache Bloodhound - Apache Attic

2024-07に完全に終了。

https://gnusocial.jp/notice/8176358

うーん。開発停止しているなら諦めて、tracで1プロジェクトで複数リポジトリーを管理する方式でいいと思う。その際に、/gnusocialのパスにして、今後マルチプロジェクトも対応可能な余地を残す。

「https://wiki.senooken.jp/index.php?title=VCS&oldid=2769」から取得