第10章 データー管理

Debian システム上で利用可能なアーカイブと圧縮ツールのまとめを以下に記します。

Debian システム上で利用可能な単純なコピーとバックアップツールのまとめを以下に記します。

rsync(8) を使ってのファイルのコピーには他の方法より豊かな機能があります。

	ヒント
	「データーバックアップ用コピースクリプト」 に記された bkup スクリプトを "-gl" オプションとともに cron(8) の下で実行すると静的なデーターアーカイブに関して Plan9 の dumpfs と非常に似た機能を実現できます。

	ヒント
	表10.11「バージョンコントロールシステムツールのリスト」に記されたバージョンコントロールシステム (VCS) ツールは多方向のコピーと同期のツールとして機能します。

"./source" ディレクトリー中の全内容を異なるツールを用いてアーカイブしアーカイブ解凍するいくつかの方法を以下に記します。

GNU tar(1):

$ tar -cvJf archive.tar.xz ./source
$ tar -xvJf archive.tar.xz

この代わりに、次のようにも出来ます。

$ find ./source -xdev -print0 | tar -cvJf archive.tar.xz --null -F -

cpio(1):

$ find ./source -xdev -print0 | cpio -ov --null > archive.cpio; xz archive.cpio
$ zcat archive.cpio.xz | cpio -i

"./source" ディレクトリー中の全内容を異なるツールを用いてコピーするいくつかの方法を以下に記します。

rsync(8):

# cd ./source; rsync -aHAXSv . /dest
# cd ./source; rsync -aHAXSv . user@host.dom:/dest

「転送元ディレクトリー後スラシュ付加」文法を上記の代わりに使えます。

# rsync -aHAXSv ./source/ /dest
# rsync -aHAXSv ./source/ user@host.dom:/dest

この代わりに、次のようにも出来ます。

# cd ./source; find . -print0 | rsync -aHAXSv0 --files-from=- . /dest
# cd ./source; find . -print0 | rsync -aHAXSv0 --files-from=- . user@host.dom:/dest

GNU cp(1) と openSSH scp(1):

# cd ./source; cp -a . /dest
# cd ./source; scp -pr . user@host.dom:/dest

GNU tar(1):

# (cd ./source && tar cf - . ) | (cd /dest && tar xvfp - )
# (cd ./source && tar cf - . ) | ssh user@host.dom '(cd /dest && tar xvfp - )'

cpio(1):

# cd ./source; find . -print0 | cpio -pvdm --null --sparse /dest

"." を含むすべての例で "." は"foo" で代替でき、ファイルを "./source/foo" ディレクトリーから "/dest/foo" ディレクトリにコピーできます。

"." を含むすべての例で "." を絶対パスの "/path/to/source/foo" で代替でき、"cd ./source;" を削除することができます。これらは使うツール次第で異なる場所にファイルをコピーします。

	ヒント
	rsync(8) や GNU cp(1) には転送先のファイルが新しい場合にスキップする "-u" オプションがあります。

リムーバブルストレージデバイスは次の何れも指します。

	ヒント
	デバイスレベルの暗号化を使ったクロスプラットフォームのデーター共有に関しては、「dm-crypt/LUKS を使ったリムーバブルディスクの暗号化」を参照下さい。

FAT ファイルシステムはほとんど全ての現代的なオペレーティングシステムでサポートされていて、ハードディスク類似のメディア経由でのデーター交換目的に非常に有用です。

クロスプラットフォームの FAT ファイルシステムを使ったデーター共有にリムーバブルハードディスク類似デバイスをフォーマットする時の安全な選択肢は次です。

データーをネットワーク経由で他のシステムと共有するときには、共通のサービスを使うべきです。次に一部のヒントを記します。

このようなネットワーク経由でマウントされたファイルシステムやネットワーク経由のファイル転送法はデーター共有のために非常に便利ですが、インセキュアーかもしれませんこれらのネットワーク接続は次に記すようにしてセキュアーにされなければいけません。

Debian システム上で利用可能でバックアップユーティリティーのスイートのなかで際立った選ばれたリストを記します。

バックアップツールにはそれぞれの特別な狙いがあります。

個人の Debian の unstable (非安定) スイートを実行するデスクトップシステムでは、個人的だったりクリティカルなデーターのみを保護する必要しかありません。いずれにせよ1年に1回はシステムを再インストールします。だから全システムをバックアップする理由もありませんし、フル機能のバックアップユーティリティーをインストールする理由もありません。

簡単なスクリプトでバックアップ用アーカイブを作成し、GUI を使って CD/DVD にそれを焼きます。次のこのスクリプトの例を示します。

#!/bin/sh -e
# Copyright (C) 2007-2008 Osamu Aoki <osamu@debian.org>, Public Domain
BUUID=1000; USER=osamu # UID and name of a user who accesses backup files
BUDIR="/var/backups"
XDIR0=".+/Mail|.+/Desktop"
XDIR1=".+/\.thumbnails|.+/\.?Trash|.+/\.?[cC]ache|.+/\.gvfs|.+/sessions"
XDIR2=".+/CVS|.+/\.git|.+/\.svn|.+/Downloads|.+/Archive|.+/Checkout|.+/tmp"
XSFX=".+\.iso|.+\.tgz|.+\.tar\.gz|.+\.tar\.bz2|.+\.cpio|.+\.tmp|.+\.swp|.+~"
SIZE="+99M"
DATE=$(date --utc +"%Y%m%d-%H%M")
[ -d "$BUDIR" ] || mkdir -p "BUDIR"
umask 077
dpkg --get-selections \* > /var/lib/dpkg/dpkg-selections.list
debconf-get-selections > /var/cache/debconf/debconf-selections

{
find /etc /usr/local /opt /var/lib/dpkg/dpkg-selections.list \
     /var/cache/debconf/debconf-selections -xdev -print0
find /home/$USER /root -xdev -regextype posix-extended \
  -type d -regex "$XDIR0|$XDIR1" -prune -o -type f -regex "$XSFX" -prune -o \
  -type f -size  "$SIZE" -prune -o -print0
find /home/$USER/Mail/Inbox /home/$USER/Mail/Outbox -print0
find /home/$USER/Desktop  -xdev -regextype posix-extended \
  -type d -regex "$XDIR2" -prune -o -type f -regex "$XSFX" -prune -o \
  -type f -size  "$SIZE" -prune -o -print0
} | cpio -ov --null -O $BUDIR/BU$DATE.cpio
chown $BUUID $BUDIR/BU$DATE.cpio
touch $BUDIR/backup.stamp

root から実行されるスクリプト断片の例と言う位置づけです。

著者はこれをあなたが次のように変更し実行する事を期待します。

ディレクトリーツリーの下のデーターセットは、"cp -a" としてコピーすると通常のバックアップができます。

"/var/cache/apt/packages/" ディレクトリーの下のデーターのようなディレクトリーの下の大きな上書きされない静的なデーターセットは、"cp -al" を利用するハードリンクを使うと通常のバックアップに代わるディスク空間を効率的に利用するバックアップができます。

私が bkup と名付けたデーターバックアップのためのコピースクリプトを次に示します。このスクリプトは現ディレクトリーの下の全ての (非 VCS) ファイルを親ディレクトリーかリモートホストの日付入りディレクトリーにコピーします。

#!/bin/sh -e
# Copyright (C) 2007-2008 Osamu Aoki <osamu@debian.org>, Public Domain
fdot(){ find . -type d \( -iname ".?*" -o -iname "CVS" \) -prune -o -print0;}
fall(){ find . -print0;}
mkdircd(){ mkdir -p "$1";chmod 700 "$1";cd "$1">/dev/null;}
FIND="fdot";OPT="-a";MODE="CPIOP";HOST="localhost";EXTP="$(hostname -f)"
BKUP="$(basename $(pwd)).bkup";TIME="$(date  +%Y%m%d-%H%M%S)";BU="$BKUP/$TIME"
while getopts gcCsStrlLaAxe:h:T f; do case $f in
g)  MODE="GNUCP";; # cp (GNU)
c)  MODE="CPIOP";; # cpio -p
C)  MODE="CPIOI";; # cpio -i
s)  MODE="CPIOSSH";; # cpio/ssh
t)  MODE="TARSSH";; # tar/ssh
r)  MODE="RSYNCSSH";; # rsync/ssh
l)  OPT="-alv";; # hardlink (GNU cp)
L)  OPT="-av";;  # copy (GNU cp)
a)  FIND="fall";; # find all
A)  FIND="fdot";; # find non CVS/ .???/
x)  set -x;; # trace
e)  EXTP="${OPTARG}";; # hostname -f
h)  HOST="${OPTARG}";; # user@remotehost.example.com
T)  MODE="TEST";; # test find mode
\?) echo "use -x for trace."
esac; done
shift $(expr $OPTIND - 1)
if [ $# -gt 0 ]; then
  for x in $@; do cp $OPT $x $x.$TIME; done
elif [ $MODE = GNUCP ]; then
  mkdir -p "../$BU";chmod 700 "../$BU";cp $OPT . "../$BU/"
elif [ $MODE = CPIOP ]; then
  mkdir -p "../$BU";chmod 700 "../$BU"
  $FIND|cpio --null --sparse -pvd ../$BU
elif [ $MODE = CPIOI ]; then
  $FIND|cpio -ov --null | ( mkdircd "../$BU"&&cpio -i )
elif [ $MODE = CPIOSSH ]; then
  $FIND|cpio -ov --null|ssh -C $HOST "( mkdircd \"$EXTP/$BU\"&&cpio -i )"
elif [ $MODE = TARSSH ]; then
  (tar cvf - . )|ssh -C $HOST "( mkdircd \"$EXTP/$BU\"&& tar xvfp - )"
elif [ $MODE = RSYNCSSH ]; then
  rsync -aHAXSv ./ "${HOST}:${EXTP}-${BKUP}-${TIME}"
else
  echo "Any other idea to backup?"
  $FIND |xargs -0 -n 1 echo
fi

これはコマンド例の位置付けです。スクリプトを読んで自分自身で編集してからご使用下さい。

	ヒント
	私はこの bkup を私の "/usr/local/bin/" ディレクトリーに置いています。わたしは一時的スナップショットのバックアップが必要な時に、作業ディレクトリー中で引数無しにこの bkup コマンドを実行します。

	ヒント
	ソースファイルツリーや設定ファイルツリーのスナップショットの履歴を作成するには、git(7) を使うのが簡単でスペースの効率も良ろしいです (「設定履歴記録のための Git」参照下さい)。

トラストコードの意味を次に記します。

次のようにすると私のキー "1DD8D791" をポピュラーなキーサーバー "hkp://keys.gnupg.net" にアップロード出来ます。

$ gpg --keyserver hkp://keys.gnupg.net --send-keys 1DD8D791

"~/.gnupg/gpg.conf" (もしくは古い場所 "~/.gnupg/options") 中の良いデフォールトのキーサーバーの設定は次を含みます。

keyserver hkp://keys.gnupg.net

次によってキーサーバーから知らないキーが獲得できます。

$ gpg --list-sigs --with-colons | grep '^sig.*\[User ID not found\]' |\
  cut -d ':' -f 5| sort | uniq | xargs gpg --recv-keys

インデックスメニュー上で "S" とすれば GnuPG が使えるようにしておきながら、遅い GnuPG が自動的に起動しないように "~/.muttrc" に次の内容を追加します。

macro index S ":toggle pgp_verify_sig\n"
set pgp_verify_sig=no

gnupg のプラグインを使うと ".gpg" や ".asc" や ".ppg" というファイル拡張子のファイルに対して透過的に GnuPG を実行できます。

# aptitude install vim-scripts vim-addon-manager
$ vim-addons install gnupg

ふたつのソースファイル間の相違を抽出したユニファイド差分ファイル は、以下の要領でファイル位置に対応し "file.patch0" か "file.patch1" として作成されます。

$ diff -u file.old file.new > file.patch0
$ diff -u old/file new/file > file.patch1

差分ファイル (別名、パッチファイル) はプログラム更新を送るのに使われます。受け取った側はこの更新を別のファイルに次のようにして適用します。

$ patch -p0 file < file.patch0
$ patch -p1 file < file.patch1

3つのバージョンのソースコードがある場合、diff3(1) を使って効率的に3方マージを次のように実行できます。

$ diff3 -m file.mine file.old file.yours > file

次に全体像を提供するべく元来の VCS コマンドを極端に簡略化した比較を示します。典型的なコマンド文字列はオプションや引数が必要となるかもしれません。

Git は使うあなたの名前や email アドレス等を "~/.gitconfig" 中のいくつかのグローバル設定に設定したいなら次のようにします。

$ git config --global user.name "Name Surname"
$ git config --global user.email yourname@example.com

もしあなたが CVS や Subversion コマンドに慣れ過ぎている場合には、いくつかのコマンドエリアスの設定を次のようにするのも一計です。

$ git config --global alias.ci "commit -a"
$ git config --global alias.co checkout

あなたのグローバル設定は次のようにするとチェックできます。

$ git config --global --list

次を参照下さい。

アップストリームが異なる VCS を使っていようと、アップストリームへのネットワーク接続無しにローカルコピーを管理できるので、ローカル活動に git(1) を使うのは良い考えかもしれません。次は git(1) とともに使われるパッケージとコマンドのリストです。

"svn+ssh://svn.example.org/project/module/trunk" にある Subversion のレポジトリを "./dest" にあるローカルの Git レポジトリにチェックアウトでき、また Subversion レポジトリに戻すコミットができます。例えば:

$ git svn clone -s -rHEAD svn+ssh://svn.example.org/project dest
$ cd dest
... make changes
$ git commit -a
... keep working locally with git
$ git svn dcommit

	ヒント
	"-rHEAD" を使うことにより Subversion のレポジトリから過去の全コンテントを複製することが避けられます。

CVS レポジトリーへのコミットを "src" グループメンバに限定し許可し、CVS の管理を "staff" グループメンバに限定し許可するように次の設定をすることでうっかりミスを予防できます。

# cd /var/lib; umask 002; mkdir cvs
# export CVSROOT=/srv/cvs/project
# cd $CVSROOT
# chown root:src .
# chmod 2775 .
# cvs -d $CVSROOT init
# cd CVSROOT
# chown -R root:staff .
# chmod 2775 .
# touch val-tags
# chmod 664 history val-tags
# chown root:src history val-tags

	ヒント
	"$CVSROOT" ディレクトリーの所有者を "root:staff" とし、そのパーミッションを "3775" と変更すると新規プロジェクトの作成を制限できます。

デフォールトの CVS レポジトリーは "$CVSROOT" で指示されます。次はローカルアクセスのための "$CVSROOT" を設定します。

$ export CVSROOT=/srv/cvs/project

"~/path/to/module1" で新規のローカルソースツリーの場所を作成。

$ mkdir -p ~/path/to/module1; cd ~/path/to/module1

"~/path/to/module1" の下の新規のローカルソースツリーを埋める。

次のパラメーターを使って CVS にインポートします。

$ cd ~/path/to/module1
$ cvs import -m "Start module1" module1 Main-branch Release-initial
$ rm -Rf . # optional

CVS は現レポジトリーファイルを上書きせず他のファイルで置き換えます。だからレポジトリーディレクトリーへの書込みパーミッションはクリチカルです。"module1" という新規レポジトリーを "/srv/cvs/project" に作成の際毎に、必要ならこの条件を満たすために次を実行します。

# cd /srv/cvs/project
# chown -R root:src module1
# chmod -R ug+rwX   module1
# chmod    2775     module1

次に CVS を使う典型的なワークフローを記します。

"$CVSROOT" で指される CVS プロジェクトから得られる全てのモジュールを次のようにしてチェックします。

$ cvs rls
CVSROOT
module1
module2
...

"module1" をそのデフォールトディレクトリーの "./module1" に次のようにしてチェックアウトします。

$ cd ~/path/to
$ cvs co module1
$ cd module1

必要に応じ内容に変更を加える。

次のようにして "diff -u [repository] [local]" と等価を作成し変更をチェックします。

$ cvs diff -u

あるファイル "file_to_undo" をひどく壊したが他のファイルは大丈夫な事に気づきます。

次のようにして "file_to_undo" ファイルを CVS からのクリーンコピーで上書きします。

$ cvs up -C file_to_undo

次のようにして更新されたローカルソースツリーを CVS に保存します。

$ cvs ci -m "Describe change"

次のようにして "file_to_add" ファイルを作成し CVS に追加します。

$ vi file_to_add
$ cvs add file_to_add
$ cvs ci -m "Added file_to_add"

次のようにして CVS から最新バージョンをマージします。

$ cvs up -d

コンフリクトある変更を意味する "C filename" で始まる行に注意します。

".#filename.version" 中の変更されていないコードを探します。

コンフリクトある変更はファイル中の "<<<<<<<" や ">>>>>>>" を探索します。

必要に応じコンフリクト解消のためにファイルを編集します。

次のようにしてリリースタグ "Release-1" を追加します。

$ cvs ci -m "last commit for Release-1"
$ cvs tag Release-1

さらに編集します。

次のようにリリースタグ "Release-1" を削除します。

$ cvs tag -d Release-1

次のように CVS へ変更をチェックインします。

$ cvs ci -m "real last commit for Release-1"

リリースタグ "Release-1" を更新した CVS の main の HEAD に次のようにして再付加します。

$ cvs tag Release-1

次のようにして "Release-initial" タグによってで指定されるオリジナルのバージョンから、スティッキーブランチタグが "Release-initial-bugfixes" のブランチを作成し、"~/path/to/old" ディレクトリーにチェックアウトします。

$ cvs rtag -b -r Release-initial Release-initial-bugfixes module1
$ cd ~/path/to
$ cvs co -r Release-initial-bugfixes -d old module1
$ cd old

	ヒント
	ブランチポイントとして特定の日付を指定するには "-r Release-initial" の代わりに "-D 2005-12-20" (ISO 8601 日付フォーマット) を使います。

オリジナルバージョンに基づいたスティッキータグ "Release-initial-bugfixes" が付いているこのローカルのソースツリーで作業をします。

このブランチで一人で作業をします … 誰か他の人がこの "Release-initial-bugfixes" ブランチに合流するまで。

次のようにして必要に応じて新規ディレクトリーを作りながらこのブランチ上の他の人が変更したファイルと同期します。

$ cvs up -d

必要に応じコンフリクト解消のためにファイルを編集します。

次のように CVS へ変更をチェックインします。

$ cvs ci -m "checked into this branch"

次のようにしてスティッキータグを削除し ("-A")、キーワード展開せずに ("-kk")、main の HEAD (最新版) をつかってローカルのツリーを更新します。

$ cvs up -d -kk -A

次のようにしてキーワード展開せずに ("-kk")、"Release-initial-bugfixes" ブランチをマージしてローカルのツリー (内容 = main の HEAD) を更新します。

$ cvs up -d -kk -j Release-initial-bugfixes

エディターを使ってコンフリクト解消します。

次のように CVS へ変更をチェックインします。

$ cvs ci -m "merged Release-initial-bugfixes"

次のようにしてアーカイブを作成します。

$ cd ..
$ mv old old-module1-bugfixes
$ tar -cvzf old-module1-bugfixes.tar.gz old-module1-bugfixes
$ rm -rf old-module1-bugfixes

	ヒント
	"cvs up" コマンドには、新規ディレクトリー作成には "-d" オプションを、また空ディレクトリーの摘み取りには "-P" オプションを指定できます。

	ヒント
	"cvs co module1/subdir" とサブディレクトリーの名前を提供して、"module1" のサブディレクトリーだけをチェックアウトすることが出来ます。

CVS から最新ファイルを取り込むには、次のように "tomorrow" (明日) を使います:

$ cvs ex -D tomorrow module_name

モジュールのエリアス "mx" を CVS プロジェクト (ローカルサーバー) に追加します。

$ export CVSROOT=/srv/cvs/project
$ cvs co CVSROOT/modules
$ cd CVSROOT
$ echo "mx -a module1" >>modules
$ cvs ci -m "Now mx is an alias for module1"
$ cvs release -d .

さて、CVS から "new" ディレクトリーに "module1" (エリアス: "mx") を次のようにしてチェックアウトします。

$ cvs co -d new mx
$ cd new

	注記
	上記プロシージャを行うには、適切なファイルパーミッションが設定されているべきです。

CVS からファイルをチェックアウトする時に、その実行パーミッションビットは保持されます。

チェックアウトされた例えば "filename" ファイルで実行ビットの問題にあった際には、次のコマンドを使い CVS レポジトリー中のそのパーミッションを変更します。

# chmod ugo-x filename

現状の subversion パッケージはレポジトリーの設定はしないので手動で設定を行う必要があります。レポジトリーを置く可能な場所の1つは "/srv/svn/project" 中です。

ディレクトリーを次のように作成します。

# mkdir -p        /srv/svn/project

レポジトリーデーターベースを次のように作成します。

# svnadmin create /srv/svn/project

Apache2 サーバー経由で Subversion レポジトリーにアクセスするだけなら、レポジトリーを次に記すように WWW サーバーのみによって書込み可とするだけが必要です。

# chown -R www-data:www-data /srv/svn/project

ユーザー認証経由でレポジトリーにアクセス許可するために "/etc/apache2/mods-available/dav_svn.conf" 中の次の部分を追加 (もしくはアンコメント) します。

<Location /project>
  DAV svn
  SVNPath /srv/svn/project
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /etc/subversion/passwd
<LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
</LimitExcept>
</Location>

次のコマンドでユーザー認証ファイルを作成します。

# htpasswd2 -c /etc/subversion/passwd some-username

Apach2 を再スタート

あなたの新規の Subversion レポジトリーは "http://localhost/project" と (ウェッブサーバーの URL が"http://example.com/" と仮定すると) "http://example.com/project" の URL にてアクセスできます。

次は Subversion レポジトリーを例えば project というグループによってローカルアクセス出きるようにする設定です。

# chmod  2775     /srv/svn/project
# chown -R root:src /srv/svn/project
# chmod -R ug+rwX   /srv/svn/project

あなたの新しい Subversion レポジトリーは、project グループに属するローカルユーザーにとって svn(1) から "file:///localhost/srv/svn/project" か "file:///srv/svn/project" の URL からグループアクセスできます。グループアクセスを確実にするために、svn や svnserve や svnlook や svnadmin 等のコマンドを "umask 002" の下で実行しなければいけません。

SSH から "example.com:/srv/svn/project" の URL にあるグループアクセス可能な Subversion レポジトリーは、svn(1) を使って "svn+ssh://example.com:/srv/svn/project" にてアクセスできます。

Subversion のブランチやタグの機能を欠くことを補うべく、多くのプロジェクトは次と似たようなディレクトリーツリーを使っています。

  ----- module1
    |   |-- branches
    |   |-- tags
    |   |   |-- release-1.0
    |   |   `-- release-2.0
    |   |
    |   `-- trunk
    |       |-- file1
    |       |-- file2
    |       `-- file3
    |
    `-- module2

	ヒント
	ブランチやタグをマークするためには "svn copy …" コマンドを使わなければいけません。こうすることで Subversion がファイルの変更履歴を適正な記録を確実にするとともに記録容量を節約できます。

"~/path/to/module1" で新規のローカルソースツリーの場所を作成。

$ mkdir -p ~/path/to/module1; cd ~/path/to/module1

"~/path/to/module1" の下の新規のローカルソースツリーを埋める。

ソースを次のパラメーターを使って Subversion にインポートします。

$ cd ~/path/to/module1
$ svn import file:///srv/svn/project/module1/trunk -m "Start module1"
$ svn cp file:///srv/svn/project/module1/trunk file:///srv/svn/project/module1/tags/Release-initial

この代わりに、次のようにも出来ます。

$ svn import ~/path/to/module1 file:///srv/svn/project/module1/trunk -m "Start module1"
$ svn cp file:///srv/svn/project/module1/trunk file:///srv/svn/project/module1/tags/Release-initial

	ヒント
	"file:///…" といった URL は、"http://…" や "svn+ssh://…" といったいかなる他形式の URL ででも置き換えられます。

次に Subversion をその本来のクライアントとともに使う典型的なワークフローを記します。

	ヒント
	git-svn パッケージによって提供されるクライアントコマンドは git コマンドを使う Subversion の代替ワークフローを提供します。「Subversion レポジトリー用の Git」を参照下さい。

"file:///srv/svn/project" の URL で指定される Subversion プロジェクトから得られる全ての利用可能なモジュールを次のようにしてチェックします。

$ svn list file:///srv/svn/project
module1
module2
...

次のようにして "module1/trunk" を"module1" ディレクトリーにチェックアウトします。

$ cd ~/path/to
$ svn co file:///srv/svn/project/module1/trunk module1
$ cd module1

必要に応じ内容に変更を加える。

次のようにして "diff -u [repository] [local]" と等価を作成し変更をチェックします。

$ svn diff

あるファイル "file_to_undo" をひどく壊したが他のファイルは大丈夫な事に気づきます。

次のようにして "file_to_undo" ファイルを Subversion からのクリーンコピーで上書きします。

$ svn revert file_to_undo

更新されたローカルソースツリーを次のようにして Subversion に保存します。

$ svn ci -m "Describe change"

次のようにして "file_to_add" ファイルを作成し Subversion に追加します。

$ vi file_to_add
$ svn add file_to_add
$ svn ci -m "Added file_to_add"

次のようにして Subversion から最新バージョンをマージします。

$ svn up

コンフリクトある変更を意味する "C filename" で始まる行に注意します。

"filename.r6" と "filename.r9" と "filename.mine" 等中の変更されていないコードを探します。

コンフリクトある変更はファイル中の "<<<<<<<" や ">>>>>>>" を探索します。

必要に応じコンフリクト解消のためにファイルを編集します。

次のようにしてリリースタグ "Release-1" を追加します。

$ svn ci -m "last commit for Release-1"
$ svn cp file:///srv/svn/project/module1/trunk file:///srv/svn/project/module1/tags/Release-1

さらに編集します。

次のようにリリースタグ "Release-1" を削除します。

$ svn rm file:///srv/svn/project/module1/tags/Release-1

次のようにして変更を Subversion にチェックインします。

$ svn ci -m "real last commit for Release-1"

リリースタグ "Release-1" を更新した Subversion の trunk の HEAD に再付加します。

$ svn cp file:///srv/svn/project/module1/trunk file:///srv/svn/project/module1/tags/Release-1

次のようにして "module1/tags/Release-initial" というパスで指定されるオリジナルのバージョンから、パスが "module1/branches/Release-initial-bugfixes" のブランチを作成し、"~/path/to/old" ディレクトリーにチェックアウトします。

$ svn cp file:///srv/svn/project/module1/tags/Release-initial file:///srv/svn/project/module1/branches/Release-initial-bugfixes
$ cd ~/path/to
$ svn co file:///srv/svn/project/module1/branches/Release-initial-bugfixes old
$ cd old

	ヒント
	ブランチポイントとして特定の日付を指定するには "module1/tags/Release-initial" の代わりに "module1/trunk@{2005-12-20}" (ISO 8601 日付フォーマット) を使います。

オリジナルバージョンに基づいたブランチ "Release-initial-bugfixes" を指定しているローカルのソースツリーで作業します。

このブランチで一人で作業をします … 誰か他の人がこの "Release-initial-bugfixes" ブランチに合流するまで。

次のようにしてこのブランチ上の他の人が変更したファイルと同期します。

$ svn up

必要に応じコンフリクト解消のためにファイルを編集します。

次のようにして変更を Subversion にチェックインします。

$ svn ci -m "checked into this branch"

trunk の HEAD を使って次のようにローカルツリーを更新します。

$ svn switch file:///srv/svn/project/module1/trunk

次のようにして "Release-initial-bugfixes" ブランチをマージしてローカルのツリー (内容 = trunk の HEAD) を更新します。

$ svn merge file:///srv/svn/project/module1/branches/Release-initial-bugfixes

エディターを使ってコンフリクト解消します。

次のようにして変更を Subversion にチェックインします。

$ svn ci -m "merged Release-initial-bugfixes"

次のようにしてアーカイブを作成します。

$ cd ..
$ mv old old-module1-bugfixes
$ tar -cvzf old-module1-bugfixes.tar.gz old-module1-bugfixes
$ rm -rf old-module1-bugfixes

	ヒント
	"file:///…" といった URL は、"http://…" や "svn+ssh://…" といったいかなる他形式の URL ででも置き換えられます。

	ヒント
	"svn co file:///srv/svn/project/module1/trunk/subdir module1/subdir" とサブディレクトリーの名前を提供して、"module1" のサブディレクトリーだけをチェックアウトすることが出来ます。