「VCS」の版間の差分

提供：senooken JP Wiki
(Checking Out A Local Tree)
(Git to Fossil Translation Guide)
502行目: 502行目:
  fossil open ../myclone.fossil
  fossil open ../myclone.fossil
このコマンドで最新のファイル群がチェックアウトされる。以下のコマンド群でローカルツリーの状態を把握できる。
このコマンドで最新のファイル群がチェックアウトされる。以下のコマンド群でローカルツリーの状態を把握できる。
  fossil info
  fossil info # git status --name-status相当？
  fossil status
  fossil status # git status相当？
  fossil changes
  fossil changes # git status相当？
  fossil diff
  fossil diff # git diff相当？
  fossil timeline
  fossil timeline # git log相当？
  fossil ls
  fossil ls # git ls-files相当？
  fossil branch
  fossil branch # git branch相当？
違うバージョンやブランチに切り替えるには、以下のコマンドを使う。
違うバージョンやブランチに切り替えるには、以下のコマンドを使う。
  fossil update
  fossil update
661行目: 661行目:


はっきりいって面倒だから、ローカルPCで履歴を全部取得して、fossilに取り込んで、取り込んだDBを転送した方が確実。
はっきりいって面倒だから、ローカルPCで履歴を全部取得して、fossilに取り込んで、取り込んだDBを転送した方が確実。
==== Git to Fossil Translation Guide ====
[https://fossil-scm.org/home/doc/trunk/www/gitusers.md Fossil: Git to Fossil Translation Guide]
===== Repositories and Checkouts Are Distinct =====
Fossilではリポジトリーとチェックアウトは明確に区別されている。gitの場合、.gitのあるディレクトリーで管理しているので、複数のチェックアウトを展開できない。


== Phorge ==
== Phorge ==

2024年12月30日 (月) 09:32時点における版

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で動作しない。

Git

Commit

マージコミット後のコミット追加

マージコミット後に次の開発作業を始めることが多い。が、直後の初回のコミットを追加したい場合困る。

git rebase -iにすると、コミットが残るから。編集はできるが、その直前にコミットの追加ができない。マージコミットは扱いが特殊で直接rebaseで編集できない。

しかたないので、該当コミットでブランチを作成して、コミット。その後、既存の修正ブランチをrebaseでそのコミットの後にくっつける。これでいける。

コミットオプション

Git - git-commit Documentation

コミットメッセージ指定のためのオプションがある。

  • -m|--message <message>: コミットを文字列で指定。複数指定可能で、その場合段落で区切ってくれる。2行目以後を書きたい場合などで使う。
  • -C|--reuse-message <commit>: 指定したコミットのコミット情報を再使用する。
  • -c|--reedit-message <commit>: -Cの同じだが、編集画面を表示してコミットメッセージを編集して再使用する。
  • -F|--file=<file>: 指定したファイルをコミットメッセージに使う。-を指定すると標準入力を使う。

基本は-m。-mの複数指定。

過去コミットのメールアドレスの変更

単一コミットのメールアドレスを指定する場合、commitに--authorを指定する。 

git commit --author="John Doe <john@doe.org>"

--amendと併用することで、過去コミットも変更できる。

数が少ないなら、rebase -iで1個ずつamendする。数が多いならfilter-branch。

第一コミットの変更

通常、第一コミットはammend以外では変更できない。

rebase --root [branch] でブランチの第一コミットも参照して改変可能。

マージコミットの打ち消し

マージコミットは扱いがやや特殊。 

git revert -m 1 マージコミット
git reset --hard HEAD~1 # マージコミット前

どちらか。

stash

復元

Git Stashの復元: 誤って削除されたスタッシュの復元方法 #Git-Stash - Qiita

git stash drop実行時に、削除したコミットのSHA1が表示される。

そのSHA1をapplyで指定すれば、取り込める。 

git stash apply [stash_hash]

リモート

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

差分ファイル抽出

情報源: 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

warning: in the working copy of 'docker/README.md', LF will be replaced by CRLF the next time Git touches it

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の文字化け対策

gitkのエンコーディングを設定する - Pistolfly

gitkはシステムのデフォルトエンコーディングで表示しようとするので、文字エンコーディングを指定しておく。 

git config --global gui.encoding utf-8

ファイル名などの文字化け対策

Git for Windows で日本語を使いたい #Vim - Qiita 

git config --global core.quotepath false
git config --global gui.encoding utf-8

改名と修正

改名と修正を同時にすると、改名を検知できない。

-Mオプションを指定すると、類似度で同時も検知できる。が、基本はリネーム・改名と修正は別コミットにしたほうがよさそう。

差分無視

git diffの--ignoreオプションにおけるスペース、タブ、改行の扱いを理解する #Git - Qiita

-wでインデント違いを無視してくれる。

squash

squashすると、squash対象コミットが、対象の直前のコミットに含められる。

gitignore

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
空ディレクトリーの維持

How do I add an empty directory to a Git repository? - Stack Overflow

gitは空ディレクトリーを履歴管理できない。何かファイルが必要。

logなど維持したい空ディレクトリーに、以下の内容の.gitignoreを置く。 

!.gitignore

.gitignore以外を無視する。これで.gitignoreのみがあるので管理できる。

指定ファイルのみ除外
*
!.gitignore

ディレクトリーを残す以外 (.gitignore1ファイル以外) に、サンプルファイルなど複数ファイルを残したい場合は、上記のように*で最初に全部除外して指定ファイルのみ含める。/は必要に応じてつける。

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を使っている。

https://github.com/git/git/blob/master/INSTALL#L141

2. cURLが.netrcにも対応しているから。

https://ec.haxx.se/usingcurl-netrc.html

GitHub

Account

Username may only contain alphanumeric characters or single hyphens, and cannot begin or end with a hyphen.

ユーザー名は、英数字と-のみが使用可能。

組織別にアカウントを分けるなら、かぶらないように末尾に-組織名のようなサフィックスがあるとよいだろう。

Fossil

外部依存を排除しており、CGIでも動作するという点が非常に良い。気になる。Phorgeの検討が不要になる。

Fossil: A Coherent Software Configuration Management System

いくつか癖があるので注意する。

https://chatgpt.com/c/674e38de-a8c0-800b-8991-e0d68a2f0d86

複数のリポジトリーを取り扱うことは可能。ただし、Web UI上からリポジトリーの新規作成はできない。リポジトリーの新規作成はあくまでコマンドラインから行う必要がある。ここは集中的。

git と fossil の比較 git vs fossil-scm | タイトル

完全に個人なら悪くないが、コマンドの操作体系も異なるし、ややリスクがある。Tracのほうが無難。

Install

Binary

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-$VER.tar.gz
tar -xf fossil-$VER.*
ln -fns ../stow/fossil-$VER/fossil ../../bin/

Server

Method

Fossil: How To Configure A Fossil Server

Fosilをサーバーとして稼働させる場合、可能な方式がいくつかある。

  • CGI
  • FastCGI: OpenBSDのみ。
  • server: fossil server
  • SCGI: fossil server実行時。

共用サーバーの場合、ほぼCGIのみ。サーバーがOpenBSDならFastCGIもOK。パフォーマンス優先なら単独サーバーかSCGI。基本はCGIでいいと思う。リポジトリーだからそんなに頻繁にアクセス来ないと思う。

https://chatgpt.com/c/674e38de-a8c0-800b-8991-e0d68a2f0d86

fossilのweb uiではリポジトリーの新規作成ができない。新規作成だけはコマンドラインから行う必要がある。これだけがいまいち。

CGI

Fossil: Serving via CGI

CGIで実行するにはいくつか手順がある。

CGIディレクトリーに以下の内容のCGIスクリプトを用意する。 

#!/usr/bin/fossil
repository: /home/fossil/repo.fossil

1行目のシバン部分をインストールしたfossilの絶対パスにする。

repositoryの部分は指定方法がいろいろある。単一リポジトリーのホストなら上記でいいが、複数のリポジトリーを取り扱いたければ、リポジトリー群の格納ディレクトリーをdirectory: で指定する。

また、リポジトリーが不在の場合のリダイレクト先を指定するnotfound:もある。 

#!/usr/bin/fossil
directory: /home/fossil/repos
notfound: http://url-to-go-to-if-repo-not-found/

CGIスクリプトをcgi-bin/repoとした場合、展開後は [http://mydomain.org/cgi-bin/repo/XYZ] のようなURLで [/home/fossil/repos/XYZ.fossil] にアクセス可能。

したがって、実際の展開時は、アクセスURLの綺麗さを考慮して、CGIのファイル名をfossilにして、以下の.htaccessでfossilをCGI扱いする。 

<FilesMatch fossil$>
	SetHandler cgi-script
</FilesMatch>

これで [http://mydomain.org/fossil/repoX] でアクセスする感じになる。これがいい。こういう方式にしておくと、既存のサイトにfossilを配置するだけでfossilのホストも可能になる。

Configure

Fossil: CGI Script Configuration Options

fossilをCGIで動作させる場合、CGIスクリプトに記載可能なオプションがある。

重要 項目 説明
repository: PATH repositoryかdirectoryは必須。fossilのリポジトリーパス。
x directory: PATH repositoryかdirectoryは必須。fossilのリポジトリーが複数ある場合の親ディレクトリー。親ディレクトリー内の全リポジトリーを提供可能。
notfound: URL directory指定時に、PATH_INFOがfossilのリポジトリーと不一致の場合このURLにリダイレクトする。
x repolist ブール値。この項目の指定があり、direcotoryも指定があれば、PATH_INFOが空の場合、リポジトリーリストを表示する。

応答のskinはrepolist-skinが0以外の最初のリポジトリーの設定で決まる。 サブディレクトリーを再帰して、*.fossilを表示するが以下の例外がある。

  • .で始まるファイルは隠しファイル扱いでスキップ。
  • .fossilのベース名と同じディレクトリーがある場合、リストは表示されるがリンクにはならない。例えば、XYZとXYZ.fossilが同じ階層にある場合。大文字・小文字無視。この場合、ベース名の異なるディレクトリーに移動させる。
localauth
skin: NAME NAMEが組み込みスキンの場合、リポジトリー自体のskinを無視してこれを使用する。

ユーザーにskinを選択させたい場合、skinの異なる複数のCGIスクリプトを用意して、同じrepositoryかdirecotoryを指定すれば、任意のCGIにアクセスすることでスキンを選択可能になる。

files
setenv
HOME
cgi-debug
errorlog
timeout
extroot
redirect
jsmode
mainmenu

とりあえず、direcotryとrepolistを指定すると良いと思う。 

#!/usr/bin/fossil
directory: /home/fossil/repos
notfound: /fossil
repolist

repolistはskinがない場合、以下のようなシンプルな表示になる。 

Fossil Repositories
Filename		Project Name		Last Modified		Login Group
dir/test.fossil				3.0 days		
fossil.fossil		Fossil		3.1 days		
test.fossil				3.0 days

repolistはディレクトリー単位の表示はできず、dirにアクセスするとnotfoundになる。notfoundで/か/fossilの一覧ページを指定したほうがよさそう。

Download

Fossil: How The Fossil Download Page Works

FossilのDownload (Fossil: Downloads) ページの仕組み。デフォルトではこのページはない。

この画面はバージョン管理していないファイルで実装されている。配布物の格納ディレクトリーのファイルリストをXMLHttpRequestで取得して、それを表示している。

以下の手順で行う。

  1. download.jsに新しいリリース用の情報を記入して、新しいバージョン番号を認識できるようにする。
  2. fossil uv addで配布用バイナリーを追加。
  3. fossil uv syncでpush

y権限を持つユーザーのpush可能。権限者を最小にして不正なバイナリーの混入を予防できる。

Usage

Quick

Fossil: Fossil Quick Start Guide

プロジェクトの基本作業。

Checking Out A Local Tree

まず、ツリーのルートとなるディレクトリーを作成して、fossil openでDBからローカルコピーをチェックアウトする。 

fossil open ../myclone.fossil

このコマンドで最新のファイル群がチェックアウトされる。以下のコマンド群でローカルツリーの状態を把握できる。 

fossil info # git status --name-status相当？
fossil status # git status相当？
fossil changes # git status相当？
fossil diff # git diff相当？
fossil timeline # git log相当？
fossil ls # git ls-files相当？
fossil branch # git branch相当？

違うバージョンやブランチに切り替えるには、以下のコマンドを使う。 

fossil update
fossil checkout

updateはローカルの変更を対象バージョンにマージする。checkoutはマージせず、ローカルの変更を上書きする。

Making and Committing Changes

以下のコマンドでファイルの追加・削除ができる。 

fossil add file...
fossil rm file...
fossil addremove file...

以下のコマンドで前回コミットからの変更点の概要を表示する。 

fossil changes

正確な差分はfossil diffで表示できる。 

fossil diff

fossil difは現在のツリーと最後に変更をコミット時の差分を表示する。コミットしていない場合、最新コミットの差分を表示する。

他のユーザーの変更の確認にはfossil timelineを実行し、コミットを見つけて、diffを実行する。実行する。 

fossil timeline

2021-03-28
03:18:54 [ad75dfa4a0] *CURRENT* Added details to frobnicate command (user: user-one tags: trunk)
2021-03-27
23:58:05 [ab975c6632] Update README.md. (user: user-two tags: trunk)

fossil diff --from current --to ab975c6632

ローカルの変更のコミットはcommitで行う。 

fossil commit

VISUALかEDITOR環境変数で指定されたエディターでコメントの入力を要請される。

リモートリポジトリーからクローンしている場合、デフォルトで自動同期モードになっているので自動的にリモートにも同期する。

Branching And Merging

新しいブランチの開始には、commit --branchを実行する。Fossilではブランチはコミット時に作成する。ただ、必要に応じてコミット前にbranch newでも作成できる。

2個のブランチのマージには、まずマージ先のブランチを更新する。その後、組み込む他のブランチをマージする。例えば、trunkにfeatureXをマージするにはイアｋのようにする。 

fossil update trunk
fossil merge featureX
# make sure the merge didn't break anything...
fossil commit

マージがうまくいかなかったりしたら、以下のコマンドで復元できる。 

fossil undo

redoもある。

Branching, Forking, Merging, and Tagging

Fossil: Branching, Forking, Merging, and Tagging

一つの親コミットに対して、複数のコミットが派生して並列することをフォークと呼んでいる。それとは別でブランチというのがある。Fossilの内部的にはどちらも同じ。違いは、人間に意図があるか。ブランチは名前のついたフォークという扱い。

特定の機能の開発などで、完了するまで本流とは別で進めたい場合に使う。

fossilでブランチの作成には2の方法がある。

1個目はcommit --branch。ほとんどの場合に推奨される。最初のコミット作成時にブランチも作る。 

fossil commit --branch my-new-branch-name

2番目はbranch new。 

fossil branch new my-new-branch-name trunk
fossil update my-new-branch-name
fossil commit

この方法は手順が多いし、YAGNI原則に反するのでお勧めされない。

trunkという名前のブランチは、fossilのデフォルトブランチ名。

ローカルチェックアウトがブランチの場合、以下のコマンドで単純にtrunkにマージできる。 

fossil merge

自動的に検知してくれる。

Get

基本的な使用方法 

# clone
fossil clone <repository url>

# sync: cloneの再開など。
fossil sync -R <repository url>

# rebuild: 取得後のDB再構築。
fossil rebuild <repository path>

上記コマンドでファイルを取得する。Fossilは1ファイルで管理するので、cloneだと取得しきれない可能性がある。中断した場合などはsyncで再取得する。再取得後、反映されない場合、rebuildで取得データからDBを再構築する。

Empty

fossilをcloneすると空で、Web UIで [cannot resolve name: trunk] と表示されることがある。これは、リポジトリーのクローンが失敗している。

以下のコマンドでデータ取得を継続する。 

fossile sync -R <repositor url>

これでもダメなら、以下のコマンドでDBを再構築する。 

fossile rebuild <repository path>

これで解決した。

Import And Export

情報源=Fossil: Import And Export

FossilにはGitのインポート・エクスポート機能がある。Gitに他のVCSのインポート・エクスポート機能があるので、Gitを経由して他のいろんなVCSをfossilとインポート・エクスポート可能。

Git → Fossil

以下のコマンドでインポート・取り込める。 

cd git-repo
git fast-export --all | fossil import --git new-repo.fossil

fossil importコマンドの第3匹数で新しいFossilリポジトリーの名前を指定する。

--gitを指定しているが、実際は不要。なぜなら、Fossilが対応している他のリポジトリーはgitだけだから。ただし、将来的に他のリポジトリーにも対応するかもしれないので、互換性のために一応--gitを指定しておく。

Fossil → Git

Fossilリポジトリーのgitへの変換は以下のコマンド。 

git init new-repo
cd new-repo
fossil export --git ../repo.fossil | git fast-import
Mirror A Fossil Repository In Git

Fossil v2.9からFossilリポジトリーのgitまたはGitHubへのミラーリングに対応している。Fossilは元々自己ホスト可能だが、この機能でGitHubでのホストも可能になる。

Bidirectional Synchronization

Gitとの同期機能もある。マークファイルを使用して行う。

例として、fossilリポジトリーの最新コミットをgitに取り込む場合を考える。

まず最初にfossilをクローンして取り込む。 

fossil clone /path/to/remote/repo.fossil repo.fossil
mkdir repo
cd repo
fossil open ../repo.fossil
mkdir ../repo.git
cd ../repo.git
git init .
fossil export --git --export-marks ../repo/fossil.marks  \
       ../repo.fossil | git fast-import                  \
       --export-marks=../repo/git.marks

fossilの最新コードをgitに取り込む場合、以下のようにfossil pullで最新コミットを取得後、 

cd ../repo
fossil pull
cd ../repo.git
fossil export --git --import-marks ../repo/fossil.marks  \
       --export-marks ../repo/fossil.marks               \
       ../repo.fossil | git fast-import                  \
       --import-marks=../repo/git.marks                  \
       --export-marks=../repo/git.marks
git fast-export --import-marks=../repo/git.marks                  \
    --export-marks=../repo/git.marks --all | fossil import --git  \
    --incremental --import-marks ../repo/fossil.marks             \
    --export-marks ../repo/fossil.marks ../repo.fossil
cd ../repo
fossil push

わかりにくいからあまりしたくない。

インポートの再開

https://chatgpt.com/c/676fb751-f140-800b-b27b-22d683926e3e

インポートが途中で中断された場合。ややこしい。fossil importは1回のコマンドで完了する設計になっているから。途中から再開する機能は直接はない。工夫が必要。

  1. gitリポジトリー側のコミットログをフィルターして必要な部分だけ残す。
  2. fossilに一部インポート済みの場合、インポート後の履歴をformat-patchでファイルに出力して、それをfossil patch applyで取り込む。
  3. 何回かに分けて、fossilのリポジトリーにインポート後、fossilのマージ機能で1個のfossilリポジトリーにマージ。

はっきりいって面倒だから、ローカルPCで履歴を全部取得して、fossilに取り込んで、取り込んだDBを転送した方が確実。

Git to Fossil Translation Guide

Fossil: Git to Fossil Translation Guide

Repositories and Checkouts Are Distinct

Fossilではリポジトリーとチェックアウトは明確に区別されている。gitの場合、.gitのあるディレクトリーで管理しているので、複数のチェックアウトを展開できない。

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=2634」から取得