カテゴリー「Subversion」の15件の記事

バージョン管理システム subversion にまつわる備忘録。

2009年4月16日 (木)

今日の日記:席替え…他。

 昨日、参考になりそうな本があったと書いた。それが以下の書籍である。

誰も書かなかった SEサバイバルガイド ~やりたいことしかやらない「悪魔の流儀(デーモン・スタイル)」~ (WEB+DB PRESS plus)

 SE(システムエンジニア)職とはカバーすべき領域がヒューマンスキルからテクノロジまで幅も広く奥も深い。とてもすべての領域でプロフェッショナルになるなんて無理だ。そういう意味では、この本で言っているスタイルは、なかなか良いのかもしれない。まだナナメ読みだけれど。

 …。

 昨年より当部署においては「設計ドキュメントの電子化」というプロジェクトが進行していた。数十年も前の仕様書などは紙がマスターとなっている。そんなドキュメントでも捨てるわけにはいかない。そのシステムは未だに現役だから。
 そのプロジェクトがそろそろ佳境である。電子化メンバーより、今日グループ会議にて今後の運用案の説明があった。その運用案では、有償のドキュメント管理ツールと、オープンソースのバージョン管理システムである subversion とを使用することになっていた。

 ところが、僕にはどうしても subversion の利用方法を間違えているように思えて、質問をしてみた。svnリポジトリは最深部に配置してこそ意味があり、中間的な一時領域として運用するには適さない。
 想像した通り subversion の仕様については、あまり理解が進んでいないようだった。五年前ならまだしも、すでにリソース管理で subversion を、間接的にでも使用している人が増えているはずなのに、疑問の声をあげる人が居ないことに、ちょっと淋しさを感じた。まあ僕が真っ先に質問してしまったから言えなかったのかもしれないけれど。

 会議の席では否定することはせず、やんわりと「試運用してみたほうが良いですね」とだけ言った。その後、電子化プロジェクトを指揮しているマネージャに「ちょっと間違いがあるかも」と言ってみた。すると、その後、僕にも電子化プロジェクトに参加して欲しいと言われた。「はい」とは答えたけれど、一応就業制限の身なので、直属の上司には後で相談してみよう。

 …。

 夕方は新体制に伴って座席替があったので、座席移動。これもけっこう大変。僕の席、本だらけなので。

 …。

 ああ、もうすぐ情報処理技術者試験だ。はっきり言って前回以上に、何も準備していない。土曜日に悪あがきするかどうするか…。多分しない気がする。

| | コメント (6)

2009年1月10日 (土)

[IT覚書][subversion]業務で大量のファイルを扱うときはやっぱりコマンドラインだね。

 どうしてもGUIの方がとっつき易い。それはそうだろう。僕もたとえばSVN(subversion)を業務で使い始めたときは、クライアント側では TortoiseSVN を使っていろいろと感触をつかんだ。TortoiseSVN は Subversion 本家との互換性がとても高く、Subversion のクライアント側の機能のほぼすべてを GUI で実行できる。
 もともと Subversion 自身が、サーバ機能とクライアント機能の両方を兼ね備えていることもあり、TortoiseSVN だけでも、ローカル環境に限定するなら、リポジトリの構築もできる。これはつまり、バックアップソフトとして Subversion を個人環境で使いたいといった場合には、TortoiseSVN だけですべて足りるということである。

 …。

 一方で、僕は業務システム開発の現場で、Subversion を使っている。ドキュメントサーバ(Windows Server 2003 R2 サーバ)に、Subversion 1.4.5 を導入している。そしてネットワーク上の共用フォルダに「作業コピー」を配置することで、複数のライブラリアンによるチェックができるようにしている。まだまだ運用は常に継続的改善中だけれど。

 「バージョン管理システムを導入しさえすればライブラリアンが必要なくなる」といった意見をよく耳にするけれど、それは絵空事だと思う。バージョン管理システムはあくまでも道具に過ぎず、ライブラリアンの仕事の効率化に一役買ってくれることは事実だけれど、そんなに言われるほど作業量を激減できるわけでもない。ライブラリアンはバージョン管理システムの仕様を踏まえ、相性の良い運用を行わなければならない。そう。バージョン管理システムの仕様をしっかりと押さえた上で運用しないとかえって作業量が増えることもある。

 …。

 現時点での最新バージョンは、1.5.4 あたりのはずだけれど、このバージョンでも「タイムスタンプの保持」の問題は解決されていない。バージョン管理とは一種の文化だから、仕方がないのかもしれない。SVNを開発している人たちの頭の中には「タイムスタンプを固定してしまうと、それはけっこう前の日時情報を持つことになるので、タイムスタンプの更新をビルドのトリガーにしているようなプロジェクトでは、とても危険な行為じゃないか」…という考えがあるんだろう。

 しかし、僕の所属している(もしくはしてきた)プロジェクトの文化では、内容的に何にも変わっていないファイルのタイムスタンプが、チェックアウトされただけで変更されてしまうことに、逆にものすごい違和感を感じるんだ。つまり、バージョン管理システムにはいっさいファイルが持っているタイムスタンプをいじってほしくないのだ。タイムスタンプを変更するのは「そのファイルを実際に開いて保存した人」だけにしたいのだ。

 今後、現行システムの保守をやっているチームにもSVNを知ってもらい、使ってもらう必要があるけれど、このタイムスタンプ問題は、必ず問題視されるだろう…。

 …。

 現時点で、その問題を少しでも軽減しようと思うなら、「ファイルの日付を"最後にコミットした日付"に設定する」というオプションを使うことくらいしかない。Subversion,TortoiseSVN ともに初期設定ではオフになっているオプションだ。

 TortoiseSVN では「設定」画面でそのオプションのオン/オフを設定できる。それでは、コマンドライン版の Subversion ではどうするのか。けっこう悩んだけれど、クライアント側の設定ファイルを書き換えることで同じことができるのがわかった。

 WindowsXP であれば、下記の位置に設定ファイルが作られている。(隠しフォルダなのでエクスプローラの表示設定を変える必要がある)

 C:\Documents and Settings\
  [USERNAME]\Application Data\
  Subversion

 ここに、config という拡張子もないテキストファイルがある。この内容を編集する。

# use-commit-times = yes

 という行がある。これは先頭に「#」がついてコメント行扱いになっている。これを有効化する。

use-commit-times = yes

 ここでの注意点は、行頭にスペースを入れないことである。

 …。

 ついでに、同ファイル内に、editor-cmd 行も有効化/修正しておけば、コマンドライン版 Subversion からリポジトリにメッセージログをスクリーンエディタで編集することができる。

editor-cmd = %SystemRoot%\system32\notepad.exe

 こうすれば「メモ帳」が登録される。
 注意点は、同じく行頭にスペースを入れないことである。

 …。

 使い方にもよるけれど、たいていの小規模なコミット(チェックイン)ならば、TortoiseSVN のGUIでやった方が良いだろう。でも、大規模な開発プロジェクトにおいて、ものすごく大量のファイルをコミットする場合、作業の証跡を残すと言う意味でも、コマンドライン版を使用して、確実にログを取ることが望ましい。

 ここで誤解しないでほしいことは、コマンドライン版 Subversion に特殊なロギング機能があるわけではないということ。もしそんな機能があったならば、GUI版の TortoiseSVN にも実装されていたはずだ。

 コマンドラインでは、普通に標準出力(またはエラー出力)をリダイレクトできるというだけである。

 変更をチェック(svn status)の場合なら

svn stat [パス名] >> [ログファイル] 2>&1

 …という感じで。

 …。

 それにしても、最近の人たちはコマンドライン操作に、本当に慣れていない。これも Windows がもたらしたものだろう。
 Unix/Linux 環境のファイルを操作するのに、FFFTP (ftpクライアントのGUIソフト:優れたフリーソフトだ) で、それをあたかもファイルエクスプローラみたいな使い方をしているんだもの。
 その使い方はどうなんだ?

 まあ、これはおじさんの愚痴だな。

| | コメント (1)

2008年9月18日 (木)

現場の実態。

 現プロジェクトは従来からのウォーターフォール開発プロセスだ。大規模は未だにこれが現実だ。
 一方で、当社の開発基盤は、「バージョン管理」を日常的に行いながら「継続的インテグレーション」(CI)を行うことを推奨している。バージョン管理は subversion を使い、CI は CruiseControl を使う。両方共にOSS(オープンソースソフトウェア→無償)だ。CI とは、プログラムの単体テストとビルドを自動化して毎日のように実行するやりかただ。(定期ビルドと定期テスト)
 これはウォーターフォールのような直列的な開発プロセスには適用しづらい。こういうのはテスト駆動型のプロセスで最大の効果を生む。(少なくとも僕はそう理解している。もしかすると違うのかもしれない)
 またまた一方で、当社の「PM標準」というものでは、開発プロセスは従来型(ウォーターフォール)を標準としている。

 僕はいまのプロジェクトの状況を様々な視点から勘案しても、バージョン管理は保守を見据えても実践すべきだけれど、定期ビルドなどといった CI は、導入できないと考えた。
 そもそも今月中に、バージョン管理に使うリポジトリの整備と、手動によるビルド環境を、なんとか構築すべく、若手への働きかけをしながらギリギリでやっている。この状況下で僕にとっては未知な「継続的インテグレーション」はとても導入できない。
 …というか、既に工程が結合テストに入っている局面では遅い。また、僕の中に CI を導入した場合の良いイメージがないことも理由だ。わからん者がわからんモノを導入してはうまくいかない。

 ああでも、開発基盤の人たちからは、だらしなく思われるのだろう。現場の言い分もあるにはあるが、あまり言っても平行線だろうし。

 僕があと1.5倍くらい働けたら、状況は異なっていたかもしれないけれど、それもタラレバに過ぎない。

 来週のリーダー会議でははっきりと言おう。CI はやらない判断をしたと。

 未来にあるであろう新規開発では、もっと初期の段階から構成管理環境を整えよう。

| | コメント (1)

2008年8月10日 (日)

[IT覚書][Linux][subversion]rpm形式の最新ではないバージョンを取得する。

 日記に書いているように、職場でのドキュメントサーバ(Windows Server 2003 R2)におけるバージョン移行(1.3 系→ 1.4 系)は先週実施できた。後はビルドサーバ(Linux:RHEL)における svn クライアントの移行や導入が残っている。Red Hat だから rpm でインストールする。そのやり方を事前に整理してみた。

1.インストールしたい subversion の
 パッケージを取得する

1-1.svn本家URL <http://subversion.tigris.org/>

1-2.「Get Subversion」という部分から「Red Hat binaries」<http://subversion.tigris.org/getting.html#redhat>を選択→リンクへ移動

1-3.「SummerSoft」<http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/>を選択→リンクへ移動

1-4.svnのバージョン1.4系が欲しいなら、「rhel-4/」を選択→リンクへ移動

1-5.インストール対象マシンのCPUアーキテクチャがインテル386であれば「i386」を選択→リンクへ移動

1-6.例えば 1.4.5 が欲しいのであれば、「subversion-1.4.5-1.i386.rpm」が対象のパッケージとなる→それをダウンロードする
(1.3系はディレクトリは存在するけれど、1.3系そのもののrpmは無いみたいだ…)

1-7.パッケージの検証

 作業用ディレクトリにrpmファイルを配置して

$ md5sum ./subversion-1.4.5-1.i386.rpm
$ rpm --checksig ./subversion-1.4.5-1.i386.rpm
$ rpm -K ./subversion-1.4.5-1.i386.rpm  などなど

2.インストールされているパッケージを削除する

2-1.作業ディレクトリに移動

2-2.インストール状況を確認

$ rpm -q subversion
$ rpm -qi subversion
$ rpm -qa | grep subversion
$ rpm -qa | grep svn
$ rpm -qR subversion
$ rpm -ql subversion
$ rpm -qf /usr/sbin/svnseve
$ rpm -qRp subversion-1.3.1-1.i386.rpm  などなど

2-3.アンインストールを実行

$ rpm -e subversion

(-e:--erase)

-v が効くなら -ev

3.新バージョンをインストールする

3-1.これからインストールされるファイルを調べる

$ rpm qlp ./subversion-1.4.5-1.i386.rpm

3-2.新規インストールの実行

(testing)
$ rpm -ivht ./subversion-1.4.5-1.i386.rpm
(go)
$ rpm -ivh ./subversion-1.4.5-1.i386.rpm

echo などで実行ログをとることを忘れずに…。

(echo 時に -h:--hash オプションがどうなるのかちょっと不明)

3-3.アップデートインストール(参考)

 今回はこれを使う予定はないけれど参考までに。

$ rpm -Uvh ./subversion-1.4.5-1.i386.rpm

$ rpm -Fvh ./subversion-1.4.5-1.i386.rpm

 通常にアップグレードという意味では -U みたい。-F との違いはちゃんと調べた方が良さそう。

いまは家では試せないので、とりあえずのメモ。

| | コメント (1)

2008年8月 7日 (木)

今日の日記:まあマイペースですよ。

 今日、午前は昨日の説明会の議事まとめ。僕は昔から議事録は過剰なくらいに書く。「議事録」は近年では「議事メモ」と呼ばれるようになって内容も簡素なものとなっている。内容が薄くても書かないよりはマシだという考え方が主流になりつつある。

 午後はLinuxサーバへの subversion インストール手順を調べた。開発基盤の人とも話した。Linuxでも業務サーバでは圧倒的なシェアを誇るのがRHEL(Red Hat Enterprise Linux)である(あくまでもLinuxではだけれど。数的にはWindowsServerの方が多い)。Red Hat だからrpm形式のパッケージなんだろうと思っていたら、やっぱりそうだった。パッケージ管理システムがちゃんと動いてくれればすんなり行くだろうけれど、ハマると怖そう。

 先日ちょっと愚痴を言った情報処理技術者試験の件。今日インターネット申し込みをした。10年以上受けていない高度試験は何を受けようか迷ったけれど、PM(プロマネ)にした。はっきり言って一発では受かりそうに無い。それでもテクニカルエンジニアネットワークよりは、僕にとっては与しやすいと思える。将来的にはネットワークやデータベースが欲しいところ。

 まあマイペースですよ。

| | コメント (4)

2008年8月 5日 (火)

昨日と今日の日記:この時期HDDクラッシュに注意せねばいけなかったのに。

 先週の金曜日に、ドキュメントサーバ(WIndowsServer)のバックアップスクリプトを流したまま帰宅した。それに伴ってローカルPCも起動したままだった。この蒸し暑い中、それはPCのハードディスクには災いしたようだった。
 月曜日に自席のPCを見てみると、画面は真っ暗でHDDからは異音がする。一発で「あーHDDがヤバいかも」と思った。湿度と温度が高い状況はHDDにとても良くないのだった。
 案の定、いろいろ手を尽くしたものの起動はできなかった。水曜日(明日)に開催予定のsubversionの説明会
にも使おうと思っていたのに。それでなくとも長年使ってきたいろいろな環境が入っていたのに。かなりショックだ。

 一方で、昨日と今日とで、ドキュメントサーバの subversion のバージョンアップ作業も決行した。他プロジェクトで既に保守運用に入っているリポジトリもあったので、慎重に行う必要があった。けっこう難航した。サーバサービスの起動という、ソフトの種類にあまり依存しなさそうな部分でハマった。
 まだLinuxサーバの方が残っている。どうやるんだ? LinuxでRed Hat系ならrpmパッケージだと思うので、パッケージ管理システムでインストールするんじゃないかと思っていたけれど、違うらしい。
 まあこれは後日改めてとなった。

 やっぱり実際に手を動かさないとわからないものだと改めて思った。

 なんだかんだと、見かけよりも余裕がない。あいかわらずギリギリの日々だ。

| | コメント (1)

2008年8月 1日 (金)

[IT覚書][subversion]最新版管理だって難しい。

 つい昨日、TortoiseSVN の 1.5.2 がリリースされたようだ。対象 svn サーバのバージョンは Subversion 1.5.1 である。
 1.5.x 系が安定するのはもう少し先かもしれない。

 バージョン管理システムというのは一種の文化であり、本来ならば何気なく運用されるべきなんだろう。そしてそのためには、プロジェクトに参加している人すべてが、バージョン管理システムの仕様を理解していないといけない。一部の人だけが知っていても意味が無い。

 ちょうど一年前携わっていた、大規模システム開発の基本設計において、僕は構成管理の役目を担ったので、まずネットワークで共用しているドキュメントサーバにおけるディレクトリ/ファイルの命名規則などを作った。
 最も口を酸っぱくして言い続けたことが「ドキュメントの最新版が入っているディレクトリには最新版だけ入れて古いファイルは消してしまうか別ディレクトリに移動させろ」ということだった。

\010_最新成果物
\020_成果物履歴

 などというディレクトリ名を決め、ここでいう「\010_最新成果物」の中には、文字通り最新の成果物しか入れてはいけない。同じディレクトリに日付で区別された複数の版が存在していてはいけない。
 このことを割と初めの段階から言い続けていたので、大人数で一斉にドキュメントを作成したときにも大きな混乱はなかった。これはバージョン管理よりももっと基礎となる「最新版管理」だ。なんだそんな基本的なことか。そう言われるかもしれない。でも、これは皆がちゃんとやろうとしないとすぐに崩れる。

 バージョン管理システムをちゃんと使えば、このようなことをしなくても良くなる……はずである。あくまでも、バージョン管理システムがどういうものかを皆が理解して運用することが前提となる。

 来週、グループ内部向けに、3回めとなるsvnの説明会をやる予定。啓蒙活動である。

 …開発言語に関する話題はまたいずれ…。

| | コメント (2)

2008年7月21日 (月)

[subversion]ver.1.5.0 リリースされていたのね。

 約1ヶ月も前にリリースされていた模様。
 気づくの遅すぎ。(汗)
 …緊急の仕事が色々あったもので…(言い訳)

 いまのプロジェクトでは svn 1.4.5 でサーバもクライアントも統一する方向で動いている。当社の開発基盤を見ている部署がそれで動作検証を行っているという理由で。僕も先週ようやく、自分が作った構成管理ガイドで想定した通りに動いてくれるかの動作確認に着手したと言うのに、世間の先端では次バージョンが出ている。

 でも、やはり単に新しいバージョンのソフトウェアを使用していれば良いという訳ではない。上位互換性が完全に保たれているのであれば、それで良いのだろうけれど、実際には細かいデグレード漏れが発生する。ネットで検索しただけでも、いくつかのバグが報告されているのが分かった。
 特に、このソフトウェアのような「バージョン管理システム」自身のバグは、プロジェクトにとって致命的な損害を与えかねない。バグではなくとも、サーバとクライアントとのバージョン相違は怖い。それが先日の動作確認でもわかった。
 例えば、Windows向けのGUIクライアント TortoiseSVN 1.4.5 は、svnサーバも 1.4.5 を想定しているが、TortoiseSVN 1.4.6〜8 は、svn 1.4.6 を想定している。
 バージョンの違いがリポジトリの作りに影響しているだけであればまだしも、チェックアウトした「作業コピー」の中身(.svnディレクトリの中身)に影響している場合は、取扱いに注意が必要だ。

 要望が多い「リポジトリへのタイムスタンプの保存」機能は、1.6.x に後ろ送りになった模様。後、英語だから詳細は不明だったけれど、1.3.x はサポート切れになる模様。

 OSSとの距離感も掴んでいかないと…。

| | コメント (2)

2008年7月16日 (水)

[IT覚書][subversion]異なるバージョンで作業コピーを作る。

 本来ならば今月の初旬にはやっておきたかったことを、ようやく今日やれた。クライアントPCではなく、WindowsServerを使っての、Subversion 動作確認。どういう挙動をするかという情報は、案外表に出ていない。基本的には自分で試すしかないのだろう。

 うちのグループの構成管理サーバである WindowsServer2003 R2 には、Subversion ver.1.3.1 がインストールされている。これは近々に ver.1.4.5 にバージョンUPする予定だけれど、他のプロジェクトも使用しているので勝手にはできない。
 それでも基本的な仕様は変わらないので、いまの状況で色々と試している。やっとサーバの admin 権限ももらえたし。

 発見があった。svn 1.3 で作成したテスト用リポジトリから、まったく同一のタイミングで、同じ範囲を、二つの「作業コピー」にチェックアウトしてみた。一方はサーバのコマンドラインで、もう一方はGUIクライアントである TortoiseSVN 1.4.5 で。その二つのディレクトリのファイルリストをとって比較してみると、内容が違う。「.svn」ディレクトリの内容が違う。
 1.4.5 によって作られた作業コピーの「.svn」方が軽量化されているみたい。でも、違うということは、互換性の問題があるわけで…。おそらく、TortoiseSVN の方で作られた「作業コピー」を、svn サーバのコマンドラインからは扱えないだろう。もしくは扱うと内容がこわれる。
 「作業コピー」を共用ディレクトリに作る場合はかなりバージョンの注意はしないといけないだろう。

| | コメント (2)

2008年6月28日 (土)

[Linux][IT覚書][subversion]バージョン管理を始めてみる。

subversion 関連 備忘録です。
自分のホームのテキストと、Webページのソースをとりあえずリポジトリに入れてバージョン管理を開始します。

★その1.Subversion リポジトリを作る

リポジトリ自体は、/var/lib/svn/repo
初期インポート元、~/temp
作業コピーは、~/work

 root になってみる。

$ su
パスワード:
su: 認証失敗

 ああ、ubuntu ではこうやるんだった。

$ sudo su
[sudo] password for kazuya:

# pwd
/var/lib
# mkdir svn

# ls -al ./svn
合計 8
drwxr-xr-x  2 root root 4096 2008-06-28 15:32 .
drwxr-xr-x 50 root root 4096 2008-06-28 15:32 ..

# cd ./svn/
# pwd
/var/lib/svn

 ここにリポジトリ作成。

# svnadmin create repo
# ls -al
合計 12
drwxr-xr-x  3 root root 4096 2008-06-28 15:34 .
drwxr-xr-x 50 root root 4096 2008-06-28 15:32 ..
drwxr-xr-x  7 root root 4096 2008-06-28 15:34 repo
# ls ./repo/
README.txt  conf  dav  db  format  hooks  locks
#

★その2.リポジトリ内に trunk ディレクトリを切って
     初期インポートする

 メッセージ"trunk create 20080628"とともに
 trunk を作成する。

$ svn mkdir file:///var/lib/svn/repo/trunk \
  -m "trunk create 20080628"

リビジョン 1 をコミットしました。
$ ls -l
合計 8
drwx------ 4 kazuya kazuya 4096 2008-05-04 13:17 local_html_master
drwxr-xr-x 2 kazuya kazuya 4096 2008-06-28 15:46 text

 メッセージ"first import 20080628"とともに
 trunk下にインポートする。

$ svn import -m "first import 20080628" ./* \
  file:///var/lib/svn/repo/trunk
svn: import コマンドへの引数が多すぎます

 あれ? 怒られた。じゃあこうかな?

$ svn import -m "first import 20080628" . \
  file:///var/lib/svn/repo/trunk

(リストが標準出力に出る)

追加しています  (バイナリ)  ...
追加しています              ...
追加しています  (バイナリ)  ...
追加しています              ...
追加しています              ...
...

リビジョン 2 をコミットしました。
$

★その3.リポジトリの中身を見てみる

 どのコマンドを使うと良いのかな?

$ svnlook tree
リポジトリの引数が必要です
使用方法を知りたいときは 'svnlook help' と打ってください。
$ svnlook tree file:///var/lib/svn/repo/
'file:///var/lib/svn/repo' は URL です。そこはパスで指定するべきです
$ svnlook tree file:///var/lib/svn/repo/trunk
'file:///var/lib/svn/repo/trunk' は URL です。そこはパスで指定するべきです

 …。
 なんかコマンドが違うみたい。
 こっちかな?

$ svn list file:///var/lib/svn/repo/trunk/

 これだと trunk 1行しか出てこない。

$ svn list -R  file:///var/lib/svn/repo/

(リストが出る)

★その4.チェックアウトして
     バージョン管理を開始する

$ pwd
/home/kazuya
$ ls
Examples           svn01.log  テンプレート  ドキュメント  音楽  公開
old_bookmark.html  temp       デスクトップ  ビデオ        画像

 インポート元はもう要らないのでバッサリ削除する。

$ rm -rf ./temp
$ ls
Examples           svn01.log     デスクトップ  ビデオ  画像
old_bookmark.html  テンプレート  ドキュメント  音楽    公開

 作業コピー用ディレクトリを作成する。

$ mkdir work
$ cd work/

 ここにチェックアウトする。

$ svn checkout file:///var/lib/svn/repo/trunk ./

(以下のようなリストが出る)
A    local_html_master/homepage2/ayuzaka/ail.htm
A    local_html_master/homepage2/ayuzaka/xxx.htm
A    local_html_master/homepage2/ayuzaka/yyy.htm
A    local_html_master/homepage2/ayuzaka/hi_ranking_cinema.htm
A    local_html_master/homepage2/ayuzaka/backup.bak
...
リビジョン 2 をチェックアウトしました。
$

$ pwd
/home/kazuya/work
$ ls
local_html_master  text
$

 ディレクトリの指定に一定のクセというか、決まりがあるみたいでした。
 trunk を指定すると、trunk 自身ではなく、その下の階層から出てくる。

 やっぱりGUIじゃなくてコマンドで試すべきだ。
 基本的な動きやクセがわかる。

以上、備忘録でした。

| | コメント (4)