en to ja translation catalogue (1510 entries)

note: Tag: title
en: Subversion Quick-Start Guide
ja: Subversion クイックスタートガイド

note: Tag: para
en: If you're new to the entire concept of version control or to the <quote>copy-modify-merge</quote> model used by both CVS and Subversion, then you should read <xref linkend="svn.basic"/> before going any further.
ja: バージョン管理モデルや CVS と Subversion の両者で利用される <quote>コピー・修正・マージ</quote>モデルについて全く聞いたことがない のであればまず<xref linkend="svn.basic"/>を読んでから先に進んだほうが よいでしょう。

note: Tag: title
en: Installing Subversion
ja: Subversionのインストール

note: Tag: para
en: Subversion is built on a portability layer called APR&mdash;the Apache Portable Runtime library. The APR library provides all the interfaces that Subversion needs to function on different operating systems: disk access, network access, memory management, and so on. While Subversion is able to use Apache as one of its network server programs, its dependence on APR <emphasis>does not</emphasis> mean that Apache is a required component. APR is a standalone library useable by any application. It does mean, however, that like Apache, Subversion clients and servers run on any operating system that the Apache httpd server runs on: Windows, Linux, all flavors of BSD, Mac OS X, Netware, and others.
ja: Subversion は APR (Apache Portable Runtime ライブラリ) と呼ばれる移植せいのある層上に構築されています。APR は異なるオペレーティングシステム上でSubversionが機能するために必要なすべてのインターフェース(ディスクアクセス、ネットワークアクセス、メモリ管理など)を提供します。いっぽう Subversion はApacheをネットワークサーバープログラムのひとつとして利用できます。APRに依存していることはApache が必須コンポーネントであることを<emphasis>意味しません</emphasis>。APRはアプリケーションから利用可能な単独のライブラリです。しかし、Subversion クライアントとサーバーは Apache httpd サーバーが動作可能などんなオペレーティングシステム(Windows、 Linux、すべてのBSD、Mac OS X、Netwareなど) で動作させることができることを意味します。

note: Tag: para
en: The easiest way to get Subversion is to download a binary package built for your operating system. Subversion's website (<ulink url="http://subversion.tigris.org"></ulink>) often has these packages available for download, posted by volunteers. The site usually contains graphical installer packages for users of Microsoft operating systems. If you run a Unix-like operating system, you can use your system's native package distribution system (RPMs, DEBs, the ports tree, etc.) to get Subversion.
ja: Subversionを手に入れる一番簡単な方法は自分のオペレーティング システム用のバイナリパッケージをダウンロードすることです。Subversionの ウェブサイト(<ulink url="http://subversion.tigris.org"></ulink>) には、ボランティアによって作られたダウンロード可能なパッケージが たくさんあります。このサイトには普通、Microsoft Windows のための グラフィックインストーラパッケージもあります。Unix系のオペレーティング システムを使っているなら、(RPM, DEB, ports tree などといった、)システム 固有のパッケージ配布システムを使うこともできます。

note: Tag: para
en: If you're one of those folks that likes to use bleeding-edge software, you can also get the Subversion source code from the Subversion repository in which it lives. Obviously, you'll need to already have a Subversion client on hand to do this. But once you do, you can check out a working copy of the Subversion source repository from <ulink url="http://svn.collab.net/repos/svn/trunk/"></ulink>:
ja: もしあなたが、bleeding-edge ソフトウェアを使うのが好きな人なら、Subversion のリポジトリからソースコードを取得して最新のSubversion を手に入れることができます。もしそうしたい場合、明らかにSubversion クライアントを既に手に入れている必要があります。でもいったんSubversion クライアントを手に入れたら、次のSubversion ソースリポジトリから作業コピーをチェックアウトすることができます。<ulink url="http://svn.collab.net/repos/svn/trunk/"></ulink>:

note: Tag: para
en: Note that the URL checked out in the example above ends not with <literal>svn</literal>, but with a subdirectory thereof called <literal>trunk</literal>. See our discussion of Subversion's branching and tagging model for the reasoning behind this.
ja: この例でチェックアウトするURLは、<literal>svn</literal>で終わるのでは なく、<literal>trunk</literal>というサブディレクトリになって います。この理由については、Subversionのブランチとタグモデルの議論を 参照してください。

note: Tag: para
en: The above command will create a working copy of the latest (unreleased) Subversion source code into a subdirectory named <filename>subversion</filename> in your current working directory. You can adjust that last argument as you see fit. Regardless of what you call the new working copy directory, though, after this operation completes, you will now have the Subversion source code. Of course, you will still need to fetch a few helper libraries (apr, apr-util, etc.)&mdash;see the <filename>INSTALL</filename> file in the top level of the working copy for details.
ja: 上のコマンドは、最新バージョンの(まだリリースされていない) Subversionのソースコード を、現在の作業ディレクトリに<filename>subversion</filename> という 名前のサブディレクトリを作りチェックアウトします。 明らかに、最後の引数は、個別の環境に応じて調整することができます。 新しい作業コピーディレクトリをどのように呼ぼうと、この操作が完了すれば Subversionのソースコードを取得できています。もちろん、他にもいくつかの 補助的なライブラリが必要になります(apr, apr-util, などなど)&mdash; 詳細は作業コピーの最上位にある<filename>INSTALL</filename>ファイルを見てください。

note: Tag: title
en: High-speed Tutorial
ja: 高速チュートリアル

note: Tag: para
en: The examples used in this appendix assume that you have <command>svn</command>, the Subversion command-line client, and <command>svnadmin</command>, the administrative tool, ready to go on a Unix-like operating system. (This tutorial also works at the Windows commandline prompt, assuming you make some obvious tweaks.) We also assume you are using Subversion 1.2 or later (run <command>svn --version</command> to check.)
ja: appendix の例では Subversion のコマンドラインクライアントである<command>svn</command>、管理用ツールである <command>svnadmin</command>が利用可能な形で手元にあることを前提とします。 そしてUnixライクのオペレーティングシステム上で作業を続けることを前提とします。(そのチュートリアルはWindows コマンドプロンプトでも動しますが、明らかな調整をすることを仮定します) さらに Subversion 1.2 かそれ以降を利用していることも仮定します (これを確認するには<command>svn --version</command>を実行してください)。

note: Tag: para
en: Subversion stores all versioned data in a central repository. To begin, create a new repository:
ja: Subversion はすべてのバージョン化されたデータを中心的なリポジトリに格納します。最初に新しいリポジトリを作りましょう:

note: Tag: para
en: This command creates a new directory <filename>/path/to/repos</filename> which contains a Subversion repository. This new directory contains (among other things) a collection of database files. You won't see your versioned files if you peek inside. For more information about repository creation and maintenance, see <xref linkend="svn.reposadmin"/>.
ja: このコマンドはSubversion リポジトリを含む新しいディレクトリ <filename>/path/to/repos</filename>を作ります。 この新しいディレクトリには(他のファイルに混じって)データベースファイルの 集まりを含んでいます。内部を詳細に知る必要がないのであれば このバージョン化されたファイルを見る必要はないでしょう。 リポジトリ生成と保守についてのより詳しい情報は <xref linkend="svn.reposadmin"/>を見てください。

note: Tag: para
en: Subversion has no concept of a <quote>project</quote>. The repository is just a virtual versioned filesystem, a large tree that can hold anything you wish. Some administrators prefer to store only one project in a repository, and others prefer to store multiple projects in a repository by placing them into separate directories. The merits of each approach are discussed in <xref linkend="svn.reposadmin.projects.chooselayout"/>. Either way, the repository only manages files and directories, so it's up to humans to interpret particular directories as <quote>projects</quote>. So while you might see references to projects throughout this book, keep in mind that we're only ever talking about some directory (or collection of directories) in the repository.
ja: Subversion には<quote>プロジェクト</quote>という概念はありません。 リポジトリは単なる仮想的にバージョン化されたファイルシステム であり、どんなデータも含むことのできる大きなツリー構造です。 管理者によってはひとつのリポジトリにひとつのプロジェクトだけを 入れることを好みますが、他の管理者はディレクトリを分割した形で 複数のプロジェクトを格納することを好みます。両者のメリット、 デメリットについては<xref linkend="svn.reposadmin.projects.chooselayout"/> で議論します。どちらの方法でもリポジトリは単にファイルとディレクトリ を管理するだけなので、特定のディレクトリを<quote>プロジェクト</quote> であると解釈するかどうかは人間にまかされています。それでこの本をつうじて プロジェクトを参照するときには、リポジトリに存在する、いま言ったような形 のいくつかのディレクトリ(あるいはディレクトリの集まり)についてだけ話を することに注意してください。

note: Tag: para
en: The <filename>branches</filename>, <filename>tags</filename>, and <filename>trunk</filename> subdirectories aren't actually required by Subversion. They're merely a popular convention that you'll most likely want to use later on.
ja: <filename>branches</filename>, <filename>tags</filename>, <filename>trunk</filename>サブディレクトリは実際には Subversion に 必要なものではありません。後で利用する時におそらくもっとも便利になる ように考えられた、よく利用される命名規約にすぎません。

note: Tag: para
en: Now the repository contains this tree of data. As mentioned earlier, you won't see your files by directly peeking into the repository; they're all stored within a database. But the repository's imaginary filesystem now contains a top-level directory named <filename>myproject</filename>, which in turn contains your data.
ja: これでリポジトリにツリーのデータが入りました。 すでに注意したように、リポジトリ中のファイルやディレクトリを詳しく 調べる必要はありません; すべてはデータベース中に格納されているもの だからです。しかしリポジトリの仮想的なファイルシステムを考えると、 いまの場合、最上位にディレクトリ<filename>myproject</filename>が あり、その下にあなたのデータが含まれている形になります。

note: Tag: para
en: Note that the original <filename>/tmp/myproject</filename> directory is unchanged; Subversion is unaware of it. (In fact, you can even delete that directory if you wish.) In order to start manipulating repository data, you need to create a new <quote>working copy</quote> of the data, a sort of private workspace. Ask Subversion to <quote>check out</quote> a working copy of the <filename>myproject/trunk</filename> directory in the repository:
ja: もとの <filename>/tmp/myproject</filename>にはなにも変更がないことに注意してく ださい。(実際、必要ならこのディレクトリを消してしまうこともできま す)。リポジトリのデータを操作するためには、このデータのために、一種の 個人用の作業領域となる新しい<quote>作業コピー</quote>を作らなくてはな りません。Subversion に、リポジトリの<filename>myproject/trunk</filename>ディレ クトリ用の作業コピーを<quote>チェックアウト</quote>するように指示して みましょう:

note: Tag: para
en: Now you have a personal copy of part of the repository in a new directory named <filename>myproject</filename>. You can edit the files in your working copy and then commit those changes back into the repository.
ja: これで<filename>myproject</filename>という名前の新しい ディレクトリ中にリポジトリのプライベートなコピーを手にしたことに なります。作業コピー中のファイルを編集し、その変更点をリポジトリに 書き戻すためにコミットすることができます。

note: Tag: para
en: Enter your working copy and edit a file's contents.
ja: 作業コピーに行ってファイル内容を修正します。

note: Tag: para
en: Run <command>svn diff</command> to see unified diff output of your changes.
ja: <command>svn diff</command> を実行して 変更点に対する unified diff 出力を確認します。

note: Tag: para
en: Run <command>svn commit</command> to commit the new version of your file to the repository.
ja: <command>svn commit</command> を実行して リポジトリに自分のファイルの新しいバージョンをコミットします。

note: Tag: para
en: Run <command>svn update</command> to bring your working copy <quote>up-to-date</quote> with the repository.
ja: <command>svn update</command> を実行して リポジトリの<quote>最新の</quote>状態を自分の作業コピーに反映します。

note: Tag: para
en: For a full tour of all the things you can do with your working copy, read <xref linkend="svn.tour"/>.
ja: 作業コピーに対してできるすべてのことについての完全な手引き については<xref linkend="svn.tour"/>を読んでください。

note: Tag: para
en: At this point, you have the option of making your repository available to others over a network. See <xref linkend="svn.serverconfig"/> to learn about the different sorts of server processes available and how to configure them.
ja: この時点で、ネットワーク越しに別の人々にリポジトリを 利用可能にすることもできます。<xref linkend="svn.serverconfig"/>を読んで利用可能ないくつかのサーバプロセス の違いについて把握し、どのように設定すれば良いかを理解してください。

note: Tag: title
en: Subversion for CVS Users
ja: CVSユーザのためのSubversion

note: Tag: para
en: This appendix is a guide for CVS users new to Subversion. It's essentially a list of differences between the two systems as <quote>viewed from 10,000 feet</quote>. For each section, we provide backreferences to relevant chapters when possible.
ja: この補遺はSubversionになじみのないCVSユーザへのガイドです。 この章は基本的に、<quote>10キロくらい離れた</quote>二つのシステム間の違い についての一覧です。それぞれの節で、できるだけ関連した章への 参照を用意しました。

note: Tag: para
en: Although the goal of Subversion is to take over the current and future CVS user base, some new features and design changes were required to fix certain <quote>broken</quote> behaviors that CVS had. This means that, as a CVS user, you may need to break habits&mdash;ones that you forgot were odd to begin with.
ja: Subversionの目標は現在と未来のCVSユーザを乗っ取ることですが、 CVSで<quote>問題</quote>となっている振る舞いを改良するために いくつかの新しい機能と、設計の変更が必要でした。これは CVSユーザとしての、いままでの習慣を断ち切る必要があるかも知れない ことを意味します&mdash;それは最初からおかしかったのですから。

note: Tag: title
en: Revision Numbers Are Different Now
ja: リビジョン番号の意味が変わります

note: Tag: para
en: In CVS, revision numbers are per-file. This is because CVS stores its data in RCS files; each file has a corresponding RCS file in the repository, and the repository is roughly laid out according to the structure of your project tree.
ja: CVSでは、リビジョン番号はファイルごとについていました。理由は、CVSはRCS ファイルにデータを格納していたからです。それぞれのファイルは RCSファイルをリポジトリに持ち、そのリポジトリは大雑把に言って、プロジェクト ツリーの構造と一致するようなレイアウトでした。

note: Tag: para
en: In Subversion, the repository looks like a single filesystem. Each commit results in an entirely new filesystem tree; in essence, the repository is an array of trees. Each of these trees is labeled with a single revision number. When someone talks about <quote>revision 54</quote>, they're talking about a particular tree (and indirectly, the way the filesystem looked after the 54th commit).
ja: Subversionでは、リポジトリは一つのファイルシステムのように見えます。 それぞれのコミットはまったく新しいファイルシステムツリーを作ります。 要約して言うと、リポジトリとは、そのようなツリーが一列にたくさん並んだ もののことです。このようなツリーそれぞれは、一つのリビジョン番号でラベル 付けされています。誰かが<quote>リビジョン 54</quote> と言うとき、彼らは特定 のツリー(そして間接的に、54番目のコミット後のファイルシステムの見え方) について語っています。

note: Tag: para
en: Technically, it's not valid to talk about <quote>revision 5 of <filename>foo.c</filename></quote>. Instead, one would say <quote><filename>foo.c</filename> as it appears in revision 5</quote>. Also, be careful when making assumptions about the evolution of a file. In CVS, revisions 5 and 6 of <filename>foo.c</filename> are always different. In Subversion, it's most likely that <filename>foo.c</filename> did <emphasis>not</emphasis> change between revisions 5 and 6.
ja: 技術的には、<quote><filename>foo.c</filename>のリビジョン 5</quote> という言い方は正しくありません。そうではなく、 <quote>リビジョン 5 に出てくる<filename>foo.c</filename></quote> と言うべきです。同様に、ファイルの変化についての前提に気をつけて ください。CVS では、リビジョン 5 とリビジョン 6 の <filename>foo.c</filename> は常に異なっていました。Subversionでは リビジョン 5 と 6 では、たいていの場合<filename>foo.c</filename> は変更されて<emphasis>いません</emphasis> 。

note: Tag: para
en: For more details on this topic, see <xref linkend="svn.basic.in-action.revs"/>.
ja: これについての詳細は<xref linkend="svn.basic.in-action.revs"/>を見てください。

note: Tag: title
en: Directory Versions
ja: ディレクトリのバージョン

note: Tag: para
en: Subversion tracks tree structures, not just file contents. It's one of the biggest reasons Subversion was written to replace CVS.
ja: Subversion はツリーの構造を追いかけるのであって、それはファイルの内容 だけにはとどまりません。これはCVSを置き換えるために Subversionが書かれた 大きな理由の一つです。

note: Tag: para
en: Here's what this means to you, as a former CVS user:
ja: CVSユーザとしてのあなたに、これが何を意味するかをここで挙げておきます:

note: Tag: para
en: The <command>svn add</command> and <command>svn delete</command> commands work on directories now, just as they work on files. So do <command>svn copy</command> and <command>svn move</command>. However, these commands do <emphasis>not</emphasis> cause any kind of immediate change in the repository. Instead, the working items are simply <quote>scheduled</quote> for addition or deletion. No repository changes happen until you run <command>svn commit</command>.
ja: <command>svn add</command> と <command>svn delete</command> コマンドは ファイルだけではなく、ディレクトリに対しても動作します。 <command>svn copy</command> と<command>svn move</command>もそうです。 しかし、これらのコマンドは、リポジトリに対して直接の変更を加える ことはありません。そのかわりに、作業アイテムは単に、追加または削除 の<quote>予告</quote> を受けるだけです。<command>svn commit</command> が実行されるまで、リポジトリはいっさい変更されません。

note: Tag: para
en: Directories aren't dumb containers anymore; they have revision numbers like files. (Or more properly, it's correct to talk about <quote>directory <filename>foo/</filename> in revision 5</quote>.)
ja: ディレクトリはもう、ただの入れ物ではありません。それはファイルと 同じように、リビジョン番号を持っています。(あるいはもっと適切には <quote>リビジョン 5 の中にある、ディレクトリ<filename>foo/</filename> </quote>という言い方が正しいのですが)。

note: Tag: para
en: Let's talk more about that last point. Directory versioning is a hard problem; because we want to allow mixed-revision working copies, there are some limitations on how far we can abuse this model.
ja: 最後の点についてもっと説明します。ディレクトリのバージョン管理は 難しい問題です。それは、混合リビジョンの作業コピーを認めたいので、 このモデルを乱用することに対する制限が必要になります。

note: Tag: para
en: From a theoretical point of view, we define <quote>revision 5 of directory <filename>foo</filename></quote> to mean a specific collection of directory-entries and properties. Now suppose we start adding and removing files from <filename>foo</filename>, and then commit. It would be a lie to say that we still have revision 5 of <filename>foo</filename>. However, if we bumped <filename>foo</filename>'s revision number after the commit, that would be a lie too; there may be other changes to <filename>foo</filename> we haven't yet received, because we haven't updated yet.
ja: 理論的な見地からすると、 <quote> ディレクトリ <filename>foo</filename>の リビジョン 5 </quote> というのは、ディレクトリエントリと属性の、ある特定のあつまりを 意味します。<filename>foo</filename>のファイルを追加したり削除 し、コミットしたとします。リビジョン 5 の<filename>foo</filename> がまだあるといえば嘘になります。しかし、コミット後に <filename>foo</filename>のリビジョン番号を上げたとすれば、 これもやはり嘘になります。まだ更新してはいないので、 <filename>foo</filename> に、まだ受け取っていないほかの人の変更が 加えられたかも知れないからです。

note: Tag: para
en: Subversion deals with this problem by quietly tracking committed adds and deletes in the <filename>.svn</filename> area. When you eventually run <command>svn update</command>, all accounts are settled with the repository, and the directory's new revision number is set correctly. <emphasis>Therefore, only after an update is it truly safe to say that you have a <quote>perfect</quote> revision of a directory.</emphasis> Most of the time, your working copy will contain <quote>imperfect</quote> directory revisions.
ja: Subversion はこの問題を、<filename>.svn</filename>の領域に コミットされた追加と削除を静かに記録することで取り扱います。 <command>svn update</command>を実行すると、 すべての変更点がリポジトリに反映され ディレクトリの新しいリビジョン番号は正しく設定されます。 <emphasis> そのため、更新後においてだけ、ディレクトリの<quote>完全な</quote> リビジョンを手にしている、と安全に言うことができます。 </emphasis> ほとんどの場合、作業コピーは<quote>不完全な</quote> ディレクトリ リビジョンを含んでいます。

note: Tag: para
en: Similarly, a problem arises if you attempt to commit property changes on a directory. Normally, the commit would bump the working directory's local revision number. But again, that would be a lie, because there may be adds or deletes that the directory doesn't yet have, because no update has happened. <emphasis>Therefore, you are not allowed to commit property-changes on a directory unless the directory is up-to-date.</emphasis>
ja: 同様にして、もしディレクトリ上の属性変更をコミットしようとした ときに問題が起こります。普通、コミットは作業ディレクトリの ローカルなリビジョン番号を上げます。しかし、やはり、それは 嘘です。というのは、更新がかかっていないことにより、ディレクトリ がまだ受け取っていない追加や削除があるかも知れないからです。 <emphasis> それで、ディレクトリが最新の状態になければ、ディレクトリ上の 属性変更をコミットすることはできません。 </emphasis>

note: Tag: para
en: For more discussion about the limitations of directory versioning, see <xref linkend="svn.basic.in-action.mixedrevs"/>.
ja: ディレクトリのバージョン管理の制限についての詳細は、 <xref linkend="svn.basic.in-action.mixedrevs"/>を見てください。

note: Tag: title
en: More Disconnected Operations
ja: 切断状態での豊富な操作

note: Tag: para
en: In recent years, disk space has become outrageously cheap and abundant, but network bandwidth has not. Therefore, the Subversion working copy has been optimized around the scarcer resource.
ja: 最近では、ディスク容量は非常に安く豊富になりましたが、ネットワークの 帯域はそうではありません。そのためSubversionの作業コピーはこの貴重な資源に ついて最適化されてきました。

note: Tag: para
en: The <filename>.svn</filename> administrative directory serves the same purpose as the <filename>CVS</filename> directory, except that it also stores read-only, <quote>pristine</quote> copies of your files. This allows you to do many things off-line:
ja: <filename>.svn</filename> 管理ディレクトリは、<filename>CVS</filename> ディレクトリと同じ目的のために用意されていますが、例外は、 ファイルの<quote>修正元コピー</quote>を読み出し専用で保存してある ことです。これを使っていろいろな作業をオフラインでやることができます:

note: Tag: para
en: Shows you any local changes you've made (see <xref linkend="svn.tour.cycle.examine.status"/>)
ja: ローカルに起きたすべての変更点を表示します(<xref linkend="svn.tour.cycle.examine.status"/>参照)

note: Tag: para
en: Shows you the details of your changes (see <xref linkend="svn.tour.cycle.examine.diff"/>)
ja: 変更点の詳細を表示します(<xref linkend="svn.tour.cycle.examine.diff"/>参照)

note: Tag: para
en: Also, the cached pristine files allow the Subversion client to send differences when committing, which CVS cannot do.
ja: さらに、キャッシュされた修正元ファイルを使うと、Subversion クライアントは、コミット時に差分のみを送信することができるよう になります。これはCVSにはできません。

note: Tag: para
en: The last subcommand in the list is new; it will not only remove local changes, but it will un-schedule operations such as adds and deletes. It's the preferred way to revert a file; running <command>rm file; svn update</command> will still work, but it blurs the purpose of updating. And, while we're on this subject&hellip;
ja: このリストの最後のサブコマンドは新しいものです。それは単にローカル の修正を削除するだけではなく、追加や削除の予告操作も取り消すことが できます。ファイルの修正取り消しのためのおすすめの方法です。 <command>rm file; svn update</command> を実行しても動作しますが、 更新の意味をあいまいにしてしまいます。そして、われわれはまだこの 問題と格闘しているのですが&hellip;

note: Tag: title
en: Distinction Between Status and Update
ja: 状態と更新の区別

note: Tag: para
en: In Subversion, we've tried to erase a lot of the confusion between the <command>cvs status</command> and <command>cvs update</command> commands.
ja: Subversionでは、<command>cvs status</command> と <command>cvs update</command> コマンドの間にあるたくさんの混乱 をなくそうとしてきました。

note: Tag: para
en: The <command>cvs status</command> command has two purposes: first, to show the user any local modifications in the working copy, and second, to show the user which files are out-of-date. Unfortunately, because of CVS's hard-to-read status output, many CVS users don't take advantage of this command at all. Instead, they've developed a habit of running <command>cvs update</command> or <command>cvs -n update</command> to quickly see their changes. If users forget to use the <option>-n</option> option, this has the side effect of merging repository changes they may not be ready to deal with.
ja: <command>cvs status</command> コマンドは二つの目的があります: まず、作業コピー中のローカルな変更をユーザに示すこと、二番目に どのファイルが最新ではなくなっているかをユーザに示すこと。 不幸にも、CVSの非常に読みにくい状態表示のために、たくさんのCVSユーザは このコマンドをまったく生かしていません。そのかわりに、変更点を見る のに、<command>cvs update</command>、あるいは <command>cvs -n update</command> を実行する癖をつけてしまいました。<option>-n</option>オプションを忘れ ると、まだ扱う準被ｳ器ｺできていないリポジトリ上の変更もマージしてしまいま す。

note: Tag: para
en: With Subversion, we've tried to remove this muddle by making the output of <command>svn status</command> easy to read for both humans and parsers. Also, <command>svn update</command> only prints information about files that are updated, <emphasis>not</emphasis> local modifications.
ja: Subversion では、<command>svn status</command> の出力を 人間が読むにも、プログラムで扱うにも簡単になるように改良 しました。また、<command>svn update</command>は更新されたファイル についての情報のみを表示し、ローカルの変更は表示 <emphasis>しないように</emphasis> しました。

note: Tag: para
en: <command>svn status</command> prints all files that have local modifications. By default, the repository is not contacted. While this subcommand accepts a fair number of options, the following are the most commonly used ones:
ja: <command>svn status</command> はローカルに修正されたすべての ファイル を表示します。デフォルトではリポジトリにアクセスしません。このコマンド はいろいろなオプションをとりますが、以下は最もよく利用されるものです:

note: Tag: para
en: Contact the repository to determine, and then display, out-of-dateness information.
ja: 過去の情報を取得してから表示するためにリポジトリに アクセスします。

note: Tag: para
en: Show <emphasis>all</emphasis> entries under version control.
ja: バージョン管理下にある<emphasis>すべての</emphasis> 情報を表示します。

note: Tag: para
en: Run non-recursively (do not descend into subdirectories).
ja: 非再帰的に実行します(サブディレクトリに降りていきません)。

note: Tag: para
en: The <command>status</command> command has two output formats. In the default <quote>short</quote> format, local modifications look like this:
ja: <command>status</command>コマンドには二つの出力形式があります。 デフォルトの<quote>短い形式</quote>では、ローカルの変更は以下のように 表示されます:

note: Tag: para
en: In this case, two new columns appear. The second column contains an asterisk if the file or directory is out-of-date. The third column shows the working-copy's revision number of the item. In the example above, the asterisk indicates that <filename>faces.html</filename> would be patched if we updated, and that <filename>bloo.png</filename> is a newly added file in the repository. (The absence of any revision number next to <filename>bloo.png</filename> means that it doesn't yet exist in the working copy.)
ja: この場合、二つの新しいコラムが表示されます。二番目のコラムは ファイルやディレクトリが最新でない場合にはアスタリスク('*')が表示 されます。三番目のコラムはアイテムの作業コピーリビジョン番号です。 上の例では、アスタリスクはもし更新しようとすれば <filename>faces.html</filename> はパッチされ、 <filename>bloo.png</filename> はリポジトリに新規追加されるだろう ことを示しています。(<filename>bloo.png</filename>の前にリビジョン番号が 表示されていないのは、作業コピーにはまだ存在していないからです)

note: Tag: para
en: Subversion has combined the CVS <literal>P</literal> and <literal>U</literal> codes into just <literal>U</literal>. When a merge or conflict occurs, Subversion simply prints <literal>G</literal> or <literal>C</literal>, rather than a whole sentence about it.
ja: Subversion は CVSの<literal>P</literal> と<literal>U</literal> コードを連結し、単に<literal>U</literal> を表示します。 マージや衝突が起こるときには、Subversionはそれに関するすべての 内容を表示するかわりに単に<literal>G</literal> または <literal>C</literal> を表示します。

note: Tag: para
en: For a more detailed discussion of <command>svn update</command>, see <xref linkend="svn.tour.cycle.update"/>.
ja: <command>svn status</command>に関する詳細は<xref linkend="svn.tour.cycle.examine.status"/> を参照してください。

note: Tag: title
en: Branches and Tags
ja: ブランチとタグ

note: Tag: para
en: Subversion doesn't distinguish between filesystem space and <quote>branch</quote> space; branches and tags are ordinary directories within the filesystem. This is probably the single biggest mental hurdle a CVS user will need to climb. Read all about it in <xref linkend="svn.branchmerge"/>.
ja: Subversion はファイルシステムの空間と<quote>ブランチ</quote> の空間を 区別しません。ブランチとタグはファイルシステム中の普通のディレクトリ です。これは多分CVSユーザが乗り越えなくてはならない一番大きい心理的な 障害です。 これについては<xref linkend="svn.branchmerge"/>全体を読んでください。

note: Tag: para
en: Since Subversion treats branches and tags as ordinary directories, always remember to check out the <literal>trunk</literal> (<literal>http://svn.example.com/repos/calc/trunk/</literal>) of your project, and not the project itself (<literal>http://svn.example.com/repos/calc/</literal>). If you make the mistake of checking out the project itself, you'll wind up with a working copy that contains a copy of your project for every branch and tag you have.
ja: Subversion はブランチとタグを通常のディレクトリのように扱うので、 いつもプロジェクトの<literal>trunk</literal> (<literal>http://svn.example.com/repos/calc/trunk/</literal>) をチェックアウトし、プロジェクト自身(<literal>http://svn.example.com/repos/calc/</literal>) をチェックアウトしないように注意してください。プロジェクト自身をチェック アウトすると、作業コピーはすべてのブランチとタグを含むプロジェクト全体 になってしまいます。

note: Tag: para
en: That is, providing you don't run out of disk space before your checkout finishes.
ja: つまり、チェックアウトが終わる前にディスクを食いつぶしてしまうことに なりかねません。

note: Tag: title
en: Metadata Properties
ja: メタデータの属性

note: Tag: para
en: A new feature of Subversion is that you can attach arbitrary metadata (or <quote>properties</quote>) to files and directories. Properties are arbitrary name/value pairs associated with files and directories in your working copy.
ja: Subversionの新しい機能の一つに、ファイルやディレクトリに任意のメタデータ (あるいは <quote>属性</quote>)を結びつけることができます。属性は任意の 名前/値のペアで作業コピーのファイルやディレクトリに結び付いています。

note: Tag: para
en: To set or get a property name, use the <command>svn propset</command> and <command>svn propget</command> subcommands. To list all properties on an object, use <command>svn proplist</command>.
ja: 属性名を設定したり、取得したりするには、 <command>svn propset</command> と <command>svn propget</command> サブコマンドを使ってください。あるオブジェクト上のすべての属性を一覧表示 するには<command>svn proplist</command>を使ってください。

note: Tag: para
en: For more information, see <xref linkend="svn.advanced.props"/>.
ja: より詳しくは<xref linkend="svn.advanced.props"/>を参照してください。

note: Tag: title
en: Conflict Resolution
ja: 衝突の解消

note: Tag: para
en: CVS marks conflicts with in-line <quote>conflict markers</quote>, and prints a <literal>C</literal> during an update. Historically, this has caused problems, because CVS isn't doing enough. Many users forget about (or don't see) the <literal>C</literal> after it whizzes by on their terminal. They often forget that the conflict-markers are even present, and then accidentally commit files containing conflict-markers.
ja: CVS はファイル中の<quote>衝突マーカ</quote>を使って衝突を知らせ、 更新時には<literal>C</literal> を表示します。歴史的にはこれは 問題を起こしてきました。それはCVSが十分に取り扱わなかったからです。 たくさんのユーザは、端末が警告した後に、<literal>C</literal> に ついて忘れてしまいます(あるいは見もしません)。しばしば衝突マーカが 依然として存在していることを忘れてしまい、衝突マーカを含んだファイルを 間違ってコミットしてしまうことがありました。

note: Tag: para
en: Subversion solves this problem by making conflicts more tangible. It remembers that a file is in a state of conflict, and won't allow you to commit your changes until you run <command>svn resolved</command>. See <xref linkend="svn.tour.cycle.resolve"/> for more details.
ja: Subversion はこの問題を、衝突マーカをもっと良く見える形で設定する ことによって解決しています。Subversion はファイルが衝突状態にある ことを憶えていて、<command>svn resolved</command>を実行するまで、 あなたの変更点をコミットすることを許しません。 詳細は <xref linkend="svn.tour.cycle.resolve"/> を見てください。

note: Tag: title
en: Binary Files and Translation
ja: バイナリファイルと変換

note: Tag: para
en: In the most general sense, Subversion handles binary files more gracefully than CVS does. Because CVS uses RCS, it can only store successive full copies of a changing binary file. Subversion, however, expresses differences between files using a binary-differencing algorithm, regardless of whether they contain textual or binary data. That means that all files are stored differentially (compressed) in the repository.
ja: 一番一般的な意味で、Subversion はバイナリファイルを CVS よりももっと 適切に扱います。CVS は RCS を利用するので、変更されたバイナリファイルの 完全なコピーを、常に格納するしかありませんでした。しかし Subversion はバイナリ差分アルゴリズムを使ってファイル間の相違を 表現します。そのファイルがテキストなのかバイナリなのかによらず そうします。これはすべてのファイルがリポジトリ中に差分の形として( 圧縮されて)格納されるということを意味します。

note: Tag: para
en: CVS users have to mark binary files with <option>-kb</option> flags, to prevent data from being garbled (due to keyword expansion and line-ending translations). They sometimes forget to do this.
ja: CVS ユーザは、<option>-kb</option> フラグを使ってバイナリファイルを マークする必要がありましたが、それはデータが文字化けすることを 防ぐためです。(キーワード展開や行末変換によってこのようなことが 起こります)。このことはときどき忘れられてしまいます。

note: Tag: para
en: Subversion takes the more paranoid route&mdash;first, it never performs any kind of keyword or line-ending translation unless you explicitly ask it do so (see <xref linkend="svn.advanced.props.special.keywords"/> and <xref linkend="svn.advanced.props.special.eol-style"/> for more details). By default, Subversion treats all file data as literal byte strings, and files are always stored in the repository in an untranslated state.
ja: Subversion はもっと神経質な方法をとります&mdash;まず、キーワード展開や 行末変換は、明示的にそのような指示を出さなければ実行されません (詳細は<xref linkend="svn.advanced.props.special.keywords"/> と <xref linkend="svn.advanced.props.special.eol-style"/> を見てください)。 デフォルトでは、Subversion はすべてのファイルデータを文字通り 単なるバイトの並びとして扱い、ファイルは常に、無変換の状態で リポジトリに保存されます。

note: Tag: para
en: Second, Subversion maintains an internal notion of whether a file is <quote>text</quote> or <quote>binary</quote> data, but this notion is <emphasis>only</emphasis> extant in the working copy. During an <command>svn update</command>, Subversion will perform contextual merges on locally modified text files, but will not attempt to do so for binary files.
ja: 次に、Subversion はファイルが<quote>テキスト</quote> であるか <quote>バイナリ</quote> であるかの内部的な記録を管理しますが、 この記録は、作業コピー中<emphasis>にしか</emphasis> ありません。 <command>svn update</command>実行中、Subversion は、ローカルに 修正のあったテキストファイルについて文脈マージをやりますが、 バイナリファイルに対してはそうしません。

note: Tag: para
en: To determine whether a contextual merge is possible, Subversion examines the <literal>svn:mime-type</literal> property. If the file has no <literal>svn:mime-type</literal> property, or has a mime-type that is textual (e.g. <literal>text/*</literal>), Subversion assumes it is text. Otherwise, Subversion assumes the file is binary. Subversion also helps users by running a binary-detection algorithm in the <command>svn import</command> and <command>svn add</command> commands. These commands will make a good guess and then (possibly) set a binary <literal>svn:mime-type</literal> property on the file being added. (If Subversion guesses wrong, the user can always remove or hand-edit the property.)
ja: 文脈マージが可能かどうかを決めるのに、Subversion は <literal>svn:mime-type</literal>属性を調べます。もしファイルが <literal>svn:mime-type</literal>属性を持たないか、テキストを 示すような内容であれば(たとえば、<literal>text/*</literal>)、Subversion はそれを テキストであると判断します。それ以外の場合、ファイルはバイナリ であるとみなされます。Subversion は<command>svn import</command> と<command>svn add</command> 実行時に、バイナリ検出アルゴリズムを 実行することでユーザを助けます。これらのコマンドは、良い推測を 行い、(可能なら)バイナリの<literal>svn:mime-type</literal> 属性 を追加されるファイルに設定します。(もし Subversion の推測が間違って いた場合は、ユーザはいつでも手でその属性を削除することができます)

note: Tag: title
en: Versioned Modules
ja: バージョン管理されたモジュール

note: Tag: para
en: Unlike CVS, a Subversion working copy is aware that it has checked out a module. That means that if somebody changes the definition of a module (e.g. adds or removes components), then a call to <command>svn update</command> will update the working copy appropriately, adding and removing components.
ja: CVSとは違い、Subversionの作業コピーはモジュールとしてチェックアウトされた ことを記録しています。これは誰かがモジュールの定義を(たとえば、部品を 追加したり削除することで)変更してから <command>svn update</command>を呼び出した場合、部品を追加したり削除す ることで、作業コピーを正しく更新することを意味します。

note: Tag: para
en: Subversion defines modules as a list of directories within a directory property: see <xref linkend="svn.advanced.externals"/>.
ja: Subversion はモジュールをあるディレクトリ属性のあるディレクトリ の集まりとして定義します。<xref linkend="svn.advanced.externals"/>を見てください。

note: Tag: title
en: Authentication
ja: 認証

note: Tag: title
en: Converting a Repository from CVS to Subversion
ja: CVS から Subversion へのリポジトリ変換

note: Tag: para
en: Perhaps the most important way to familiarize CVS users with Subversion is to let them continue to work on their projects using the new system. And while that can be somewhat accomplished using a flat import into a Subversion repository of an exported CVS repository, the more thorough solution involves transferring not just the latest snapshot of their data, but all the history behind it as well, from one system to another. This is an extremely difficult problem to solve that involves deducing changesets in the absence of atomicity, and translating between the systems' completely orthogonal branching policies, among other complications. Still, there are a handful of tools claiming to at least partially support the ability to convert existing CVS repositories into Subversion ones.
ja: おそらく CVS ユーザが Subversion に慣れる一番重要な方法は既存の プロジェクトを新しいシステムを使って継続することです。これには 抽出した CVS リポジトリを Subversion リポジトリに単にインポート することでもある程度達成できますが、さらに徹底した方法としては データの最新の状態だけではなく、それ以前の履歴全体を旧システムから 新システムに移すことになります。これは解くのが極端に難しい問題です が、それは不分割の性質を持たない CVS データの変更からチェンジセット を求めること、ブランチについて全く別の考え方を持っている両システム 間でデータ変換すること、その他の複雑な問題があるためです。それでも 少なくとも部分的には既存の CVS リポジトリを Subversion リポジトリ に変換するためのツールがあります。

note: Tag: para
en: The most popular (and likely the most mature) conversion tool is cvs2svn (<ulink url="http://cvs2svn.tigris.org/"></ulink>), a Python script originally created by members of Subversion's own development community. This tool is meant to run exactly once: it scans your CVS repository multiple times and attempts to deduce commits, branches, and tags as best it can. When it finishes, the result is a either a Subversion repository or a portable Subversion dumpfile representing your code's history. See the website for detailed instructions and caveats.
ja: もっとも人気のある( そしてもっとも成熟した) 変換ツールは cvs2svn (<ulink url="http://cvs2svn.tigris.org/"></ulink>) です。このスクリプトは、Subversion 開発チームのメンバーによって作成された Python スクリプトです。このツールは、たった一度だけ使われます。何度もCVS リポジトリを走査して、スクリプトが最善と考えるコミット、ブランチ、タグを推測しようと試みます。変換が終わると、Subversion リポジトリかポータブルな Subversion ダンプファイルの形式で出力されます。詳細な手順や注意事項はウェブサイトを見てください。

note: Tag: title
en: WebDAV and Autoversioning
ja: WebDAV と、自動バージョン化

note: Tag: para
en: WebDAV is an extension to HTTP, and is growing more and more popular as a standard for file-sharing. Today's operating systems are becoming extremely Web-aware, and many now have built-in support for mounting <quote>shares</quote> exported by WebDAV servers.
ja: WebDAV はHTTPの拡張で、ファイル共有のための標準として ますます一般的なものになっていっています。今日のオペレーティング システムは極端に Webを意識していて、多くのOSはWebDAVサーバによって 公開された<quote>共有</quote> をマウントするための仕組みを組み込みで サポートしています。

note: Tag: title
en: What is WebDAV?
ja: WebDAVって何?

note: Tag: para
en: What does this mean, then?
ja: それで、どういう意味?

note: Tag: title
en: Autoversioning
ja: 自動バージョン化

note: Tag: para
en: While the Subversion client is not a full DeltaV client, nor the Subversion server a full DeltaV server, there's still a glimmer of WebDAV interoperability to be happy about: it's called autoversioning.
ja: Subversion クライアントはまだ完全な DeltaV クライアントではありませんし Subversion サーバも完全な DeltaV サーバではありませんが、 WebDAV 協調動作できるうれしい機能があります: それは自動バージョン化と 呼ばれるものです。

note: Tag: para
en: When SVNAutoversioning is active, write requests from WebDAV clients result in automatic commits. A generic log message is auto-generated and attached to each revision.
ja: SVNAutoversioning が有効な場合には WebDAV クライアントからの要求は 不分割なコミットとなります。一般的なログメッセージが自動生成され それぞれのリビジョンにつけられます。

note: Tag: para
en: If you have a post-commit hook program that sends email, you may want to disable email generation either altogether, or on certain sections of the repository; it depends on whether you think the influx of emails will still prove to be valuable notifications or not. Also, a smart post-commit hook program can distinguish between a transaction created via autoversioning and one created through a normal <command>svn commit</command>. The trick is to look for a revision property named <literal>svn:autoversioned</literal>. If present, the commit was made by a generic WebDAV client.
ja: たとえばメールを送信するようなpost-commitのフックプログラムがある 場合、email 生成を完全に禁止したいと思うか、リポジトリの特定の部分に 関して禁止したいと思うかも知れません; それは email の流入量が 意味のある通知と考えられるかどうかにかかっています。さらに、賢い post-commitフックプログラムは自動バージョン化機能によって発生した トランザクションと通常の <command>svn commit</command>によって発生したトランザクションとを区別する ことができます。これには <literal>svn:autoversioned</literal>という 名前のリビジョンプロパティーを見るとうまくいきます。もし存在して いればそのコミットは一般的な WebDAV クライアントによるものです。

note: Tag: title
en: Client Interoperability
ja: クライアントの協調動作

note: Tag: para
en: All WebDAV clients fall into one of three categories&mdash;standalone applications, file-explorer extensions, or filesystem implementations. These categories broadly define the types of WebDAV functionality available to users. <xref linkend="svn.webdav.clients.tbl-1"/> gives our categorization and a quick description of some common pieces of WebDAV-enabled software. More details about these software offerings, as well as their general category, can be found in the sections that follow.
ja: すべての WebDAV クライアントは三つのどれかに分類されます&mdash; スタンドアロン・アプリケーション、ファイルエクスプローラ拡張、そして ファイルシステムの実装です。これらの分類はおおざっぱに言ってユーザに 対して提供できる WebDAV の機能の種類を決めます。 <xref linkend="svn.webdav.clients.tbl-1"/> はその分類と、WebDAV が利用可能な ソフトウェアの共通部品の簡単な説明です。これらのソフトウェアが提供する機能の 詳細と一般的な分類についてはその後の節で見ることができます。

note: Tag: title
en: Common WebDAV Clients
ja: よく利用される WebDAV クライアント

note: Tag: entry
en: Software
ja: ソフトウェア

note: Tag: entry
en: Image editing software, allowing direct opening from, and writing to, WebDAV URLs
ja: 画像編集ソフトで、WebDAV URL を直接開いたり書き込んだりすることができます。

note: Tag: entry
en: Command-line WebDAV client supporting file transfer, tree, and locking operations
ja: コマンドライン WebDAV クライアントで、ファイル転送、ツリー、排他操作をサポートしています。

note: Tag: entry
en: Web production software able to directly read from and write to WebDAV URLs
ja: WebDAV URL に対して直接の読み書き可能な Web ページ作成ツール。

note: Tag: entry
en: Office productivity suite with several components able to directly read from and write to WebDAV URLs
ja: オフィスの生産性を高めるさまざまなコンポーネントからなる製品 で、WebDAV URL に対して直接読み書きすることが可能です。

note: Tag: entry
en: <entry>Microsoft Web Folders</entry>
ja: <entry>Microsoft Webfolders</entry>

note: Tag: entry
en: GUI file explorer program able to perform tree operations on a WebDAV share
ja: WebDAV 共有上のツリー操作を可能にする GUI のファイルエクスプローラ・プラグラムす。

note: Tag: entry
en: GUI file explorer able to perform tree operations on a WebDAV share
ja: WebDAV 共有上のツリー操作を可能にする GUI のファイルエクスプローラです。

note: Tag: entry
en: <entry>WebDAV filesystem implementation</entry>
ja: <entry>WebDAV のファイルシステム実装</entry>

note: Tag: entry
en: Drive-mapping program for assigning Windows drive letters to a mounted remote WebDAV share
ja: Windows のドライブ識別文字をマウントされたリモート WebDAV 共有に 割り当てるための、ドライブマッピング・プログラムです。

note: Tag: entry
en: File transfer software which, among other things, allows the assignment of Windows drive letters to a mounted remote WebDAV share
ja: 機能の一部として、Windows のドライブ識別文字を マウントされたリモート WebDAV 共有に割り当てることも可能な、ファイル転送ソフトウェアです。

note: Tag: entry
en: Linux file system driver that allows you to mount a WebDAV share
ja: Linux ファイルシステムドライバで、WebDAV 共有をマウントできます。

note: Tag: para
en: On Windows, there are several well-known applications that contain integrated WebDAV client functionality, such as Microsoft's Office, <footnote> <para>WebDAV support was removed from Microsoft Access for some reason, but exists in the rest of the Office suite.</para> </footnote> Adobe's Photoshop, and Macromedia's Dreamweaver programs. They're able to directly open and save to URLs, and tend to make heavy use of WebDAV locks when editing a file.
ja: Windows 上では Microsoft Office のような、WebDAV のクライアント機能を 統合した有名なアプリケーションがいくつかあります。 <footnote> <para>ある理由で WebDAV のサポートは Microsoft Access からは 削除されましたが、それ以外の Office スイートには存在します。 </para> </footnote> Adobe の Photoshop と Macromedia の Dreamweaver 。 両方とも直接 URL を開いたり保存したりすることができますが ファイルを編集するさい WebDAV の排他制御を頻繁に利用する傾向が あります。

note: Tag: para
en: Note that while many of these programs also exist for the Mac OS X, they do not appear to support WebDAV directly on that platform. In fact, on Mac OS X, the <guimenu>File-&gt;Open</guimenu> dialog box doesn't allow one to type a path or URL at all. It's likely that the WebDAV features were deliberately left out of Macintosh versions of these programs, since OS X already provides such excellent low-level filesystem support for WebDAV.
ja: Mac OS X 上にも同じようなたくさんのプログラムが存在しますが、 それらのプログラム上では直接 WebDAV がサポートされているようには見えません。じっさい Mac OS X 上では、<guimenu>File-&gt;Open</guimenu>ダイアログは パスや URL の入力がまったく許されてはいません。これらのプログラムの Macintosh バージョンでは WebDAV の機能はわざと実装されていない ように見えますが、それは OS X 自身がすでに WebDAV 用のすばらしい 低レベルファイルシステムを提供しているからです。

note: Tag: title
en: <title>Microsoft Web Folders</title>
ja: <title>Microsoft Webfolders</title>

note: Tag: para
en: Microsoft was one of the original backers of the WebDAV specification, and first started shipping a client in Windows 98, known as <quote>Web Folders</quote>. This client was also shipped in Windows NT4 and 2000.
ja: Microsoft は WebDAV 仕様の元来の支援者の一つであり、Windows 98 で最初の クライアントを出荷し始めました。これは<quote>Webfolders</quote>と言う 名前で知られています。このクライアントはまた Windows NT4 と 2000 でも 出荷されました。

note: Tag: para
en: The original Web Folders client was an extension to Explorer, the main GUI program used to browse filesystems. It works well enough. In Windows 98, the feature might need to be explicitly installed if Web Folders aren't already visible inside <quote>My Computer</quote>. In Windows 2000, simply add a new <quote>network place</quote>, enter the URL, and the WebDAV share will pop up for browsing.
ja: もともとの Webfolder クライアントはエクスプローラの拡張であり、これは ファイルシステムを閲覧する際の主要な GUI プログラムでした。これはとても うまく動作しています。Windows 98 では <quote>マイコンピュータ</quote> の中に Webfolder がない場合には明示的にインストールする必要がありました。 Windows 2000 では単に新しい <quote>ネットワークプレース</quote>を追加 し、URL を入力すれば WebDAV 共有が閲覧用にポップアップします。

note: Tag: para
en: With the release of Windows XP, Microsoft started shipping a new implementation of Web Folders, known as the <quote>WebDAV mini-redirector</quote>. The new implementation is a filesystem-level client, allowing WebDAV shares to be mounted as drive letters. Unfortunately, this implementation is incredibly buggy. The client usually tries to convert http URLs (<literal>http://host/repos</literal>) into UNC share notation (<literal>\\host\repos</literal>); it also often tries to use Windows Domain authentication to respond to basic-auth HTTP challenges, sending usernames as <literal>HOST\username</literal>. These interoperability problems are severe and documented in numerous places around the web, to the frustration of many users. Even Greg Stein, the original author of Apache's WebDAV module, recommends against trying to use XP Web Folders against an Apache server.
ja: Windows XP のリリースで、Microsoft は Webfolder の新しい実装を出荷し 始めましたが、これは <quote>WebDAV mini-redirector</quote>という名前で 知られています。新しい実装はファイルシステムレベルのクライアントであり WebDAV 共有をドライブ文字をつけてマウントできるようにしたものです。 残念なことにこの実装はかなりバグがあります。クライアントは通常 http URL (<literal>http://host/repos</literal>) を UNC 共有記法 (<literal>¥¥host¥repos</literal>)に変換しようとします; また Windows ドメイン認証を使ってHTTP 基本認証要求に応答しますが、このとき ユーザ名には <literal>HOST¥username</literal>が利用されます。 このような協調動作の問題は深刻なもので、多くのユーザに対する不満を 解消するための数えきれないくらいのドキュメントがネット上に存在して います。Apache の WebDAV モジュールを最初に設計した Greg Stein で すら Apache サーバに対して XP Webfolder を利用することを推奨 していません。

note: Tag: para
en: It turns out that the original <quote>Explorer-only</quote> Web Folders implementation isn't dead in XP, it's just buried. It's still possible to find it by using this technique:
ja: 最初の <quote>エクスプローラ機能のみの</quote> Webfolder の実装は XP でもなくなってはいませんが、埋もれてしまっています。以下のような 方法を使っていまでも探すことはできます:

note: Tag: para
en: Go to 'Network Places'.
ja: 'ネットワークプレース' を選択します。

note: Tag: para
en: Add a new network place.
ja: 新しいネットワークプレースを追加します。

note: Tag: para
en: When prompted, enter the URL of the repository, but <emphasis>include a port number</emphasis> in the URL. For example, <literal>http://host/repos</literal> would be entered as <literal>http://host:80/repos</literal> instead.
ja: プロンプトが出たらリポジトリの URL を入力しますが URL には <emphasis>ポート番号</emphasis>を含めます。例えば <literal>http://host/repos</literal>は、かわりに <literal>http://host:80/repos</literal>と指定します。

note: Tag: para
en: Respond to any authentication prompts.
ja: 認証要求に正しく答えます。

note: Tag: para
en: In GNOME's Nautilus, from the <guimenu>File menu</guimenu>, select <guimenuitem>Open location</guimenuitem> and enter the URL. The repository should then be displayed like any other filesystem.
ja: GNOME の Nautilus の場合、<guimenu>ファイルメニュー</guimenu>で <guimenuitem>Open location</guimenuitem>を 選択し、URL を入力します。これでリポジトリは他のファイルシステムと同じように 見えるはずです。

note: Tag: title
en: <title>WebDAV filesystem implementation</title>
ja: <title>WebDAV ファイルシステムの実装</title>

note: Tag: para
en: One more word of warning: OS X's WebDAV client can sometimes be overly sensitive to HTTP redirects. If OS X is unable to mount the repository at all, you may need to enable the BrowserMatch directive in the Apache server's <filename>httpd.conf</filename>:
ja: もう一点だけ: OS X の WebDAV クライアントは HTTP のリダイレクトに 対して必要以上に神経質に動作することがあります。リポジトリをまったく マウントできない場合には、Apache サーバの <filename>httpd.conf</filename> ファイルの、BrowserMatch ディレクティブを有効にする必要があるかも 知れません:

note: Tag: para
en: Linux davfs2 is a filesystem module for the Linux kernel, whose development is located at <ulink url="http://dav.sourceforge.net/"></ulink>. Once installed, a WebDAV network share can be mounted with the usual Linux mount command:
ja: Linux davfs2 は Linux カーネル用のファイルシステムモジュールで <ulink url="http://dav.sourceforge.net/"></ulink> で開発されています。 一度インストールしてしまえば WebDAV ネットワーク共有は通常の Linux の mount コマンドによってマウントできます:

note: Tag: title
en: Third Party Tools
ja: サードパーティー製ツール

note: Tag: para
en: Subversion's modular design (covered in <xref linkend="svn.developer.layerlib"/>) and the availability of language bindings (as described in <xref linkend="svn.developer.usingapi.otherlangs"/>) make it a likely candidate for use as an extension or backend to other pieces of software. For a listing of many third-party tools that are using Subversion functionality under-the-hood, check out the Links page on the Subversion website (<ulink url="http://subversion.tigris.org/project_links.html"></ulink>).
ja: Subversion のモジュール化された設計(<xref linkend="svn.developer.layerlib"/>で議論しました)と可能な言語連係 (<xref linkend="svn.developer.usingapi.otherlangs"/>に記述があります)は他のソフトウェア の拡張やバックエンドとして利用することのできる選択子になります。 Subversion の機能を後ろで使うようなサードパーティー製のツール の一覧は、Subversion ウェブサイト (<ulink url="http://subversion.tigris.org/project_links.html"></ulink>) のリンクページにあります。

note: Tag: title
en: Version Control with Subversion
ja: Subversion によるバージョン管理

note: Tag: title
en: Preface
ja: 序

note: Tag: title
en: Audience
ja: 対象読者

note: Tag: title
en: How to Read this Book
ja: この本の読み方

note: Tag: term
en: Experienced System Administrators
ja: 経験を積んだシステム管理者

note: Tag: term
en: New users
ja: 初心者

note: Tag: term
en: Advanced users
ja: より進んだユーザ

note: Tag: term
en: Developers
ja: 開発者

note: Tag: para
en: Presumably, you're already familiar with Subversion, and now want to either extend it or build new software on top of its many APIs. <xref linkend="svn.developer"/> is just for you.
ja: おそらくあなたは既に Subversion になじんでいて、どうやってそれを拡張するか、 あるいは Subversion のたくさんある API を使ってどうやって新しいソフトウェア を作るかに興味があるでしょう。<xref linkend="svn.developer"/>はまさにそんな人に うってつけです。

note: Tag: para
en: The book ends with reference material&mdash;<xref linkend="svn.ref"/> is a reference guide for all Subversion commands, and the appendices cover a number of useful topics. These are the chapters you're mostly likely to come back to after you've finished the book.
ja: この本のしめくくりはリファレンス情報です&mdash;<xref linkend="svn.ref"/>は、 すべてのSubversionコマンドのリファレンスガイドと、いろいろな役に立つトピック に関する補足情報です。この本全体を一度読み終えたあとで戻ってくる のはきっとこの章でしょう。

note: Tag: title
en: Conventions Used in This Book
ja: この本での約束ごと

note: Tag: para
en: This section covers the various conventions used in this book.
ja: ここではこの本で利用されるさまざまな規約について触れます。

note: Tag: title
en: Typographic Conventions
ja: 印刷上の規約

note: Tag: command
en: Constant width
ja: 固定幅

note: Tag: para
en: Used for commands, command output, and options
ja: コマンド、コマンド出力、スイッチに使います

note: Tag: replaceable
en: Constant width italic
ja: イタリックな固定幅

note: Tag: para
en: Used for replaceable items in code and text
ja: プログラムやテキスト中で置き換え可能なアイテムに対して使います

note: Tag: filename
en: Italic
ja: イタリック

note: Tag: para
en: Used for file and directory names
ja: ファイルやディレクトリの名前に使います

note: Tag: title
en: Icons
ja: アイコン

note: Tag: para
en: This icon designates a note relating to the surrounding text.
ja: このアイコンは周りにあるテキストに関連した注意を 表します。

note: Tag: para
en: This icon designates a helpful tip relating to the surrounding text.
ja: このアイコンは周りにあるテキストに関連したヘルプ 情報を表します。

note: Tag: para
en: This icon designates a warning relating to the surrounding text.
ja: このアイコンは回りにあるテキストに関連した警告を 表します。

note: Tag: title
en: Organization of This Book
ja: この本の構成

note: Tag: para
en: The chapters that follow and their contents are listed here:
ja: 以下の章とその内容をここで一覧にしておきます:

note: Tag: para
en: Covers the history of Subversion as well as its features, architecture, and components.
ja: Subversionの歴史、その機能、構造、 構成要素を説明します

note: Tag: para
en: Explains the basics of version control and different versioning models, along with Subversion's repository, working copies, and revisions.
ja: バージョン管理の基礎と異なるバージョン管理モデルを、Subversion の リポジトリ、作業コピー、リビジョンとの関連で説明します。

note: Tag: para
en: Covers more complex features that regular users will eventually come into contact with, such as versioned metadata, file locking, and peg revisions.
ja: もっと複雑な機能、例えばバージョン管理されたメタデータやファイルロック、そしてペグリビジョンを扱います。一般的なユーザーも結局は使用することになるでしょう。

note: Tag: para
en: Discusses branches, merges, and tagging, including best practices for branching and merging, common use cases, how to undo changes, and how to easily swing from one branch to the next.
ja: ブランチ、マージ、そしてタグについて議論しますが、これにはブランチと マージの最良の方法、一般的な利用例、変更をどうやって取り消すか、 そしてあるブランチから別ブランチにどうやって簡単に乗り換えるかなども 含まれます。

note: Tag: para
en: Describes the basics of the Subversion repository, how to create, configure, and maintain a repository, and the tools you can use to do all of this.
ja: Subversion リポジトリの基本について議論します。どうやってリポジトリを 作成し、設定し、管理するかについて、また、そのためにどんなツールを 利用できるかについても議論します。

note: Tag: para
en: Explains how to configure your Subversion server and different ways to access your repository: <literal>HTTP</literal>, the <literal>svn</literal> protocol, and local disk access. It also covers the details of authentication, authorization and anonymous access.
ja: Subversion サーバの設定方法と、リポジトリへのアクセス方法について説明します: <literal>HTTP</literal>、<literal>svn</literal> プロトコル、そしてローカルアクセスです。また認証、認可、匿名アクセス についての詳細にも触れます。

note: Tag: para
en: Describes the internals of Subversion, the Subversion filesystem, and the working copy administrative areas from a programmer's point of view. Demonstrates how to use the public APIs to write a program that uses Subversion, and most importantly, how to contribute to the development of Subversion.
ja: Subversion の内部構造、Subversion ファイルシステム、そして作業コピー の管理領域についてプログラマーの視点から説明します。 Subversion を利用するプログラムを書くために公開された API を使う 例をあげ、そして最も大切なことですが、どうやって Subversion の開発に 貢献するかを示します。

note: Tag: para
en: Explains in great detail every subcommand of <command>svn</command>, <command>svnadmin</command>, and <command>svnlook</command> with plenty of examples for the whole family!
ja: <command>svn</command>、<command>svnadmin</command>、そして<command>svnlook</command> のそれぞれのサブコマンドについてすべてのケースでの豊富な例をまじえながら詳細に 説明します。

note: Tag: para
en: Covers the similarities and differences between Subversion and CVS, with numerous suggestions on how to break all the bad habits you picked up from years of using CVS. Included are descriptions of Subversion revision numbers, versioned directories, offline operations, <command>update</command> vs. <command>status</command>, branches, tags, metadata, conflict resolution, and authentication.
ja: Subversion と CVS の間の類似点と相違点に触れ、CVS を長年使ってきたことによる 悪い習慣からどうやって抜け出すかについてのさまざまなアドバイスをします。 具体的には Subversion のリビジョン番号、バージョン化されたディレクトリ、 オフラインでの操作、<command>update</command>と<command>status</command> の違い、ブランチ、タグ、メタデータ、衝突の解消、そして認証です。

note: Tag: para
en: Describes the details of WebDAV and DeltaV, and how you can configure your Subversion repository to be mounted read/write as a DAV share.
ja: WebDAVとDeltaVの詳細と、DAV共有を読み書き可能な形にマウントするために どうやってSubversion リポジトリを設定するかを説明します。

note: Tag: para
en: Discusses tools that support or use Subversion, including alternative client programs, repository browser tools, and so on.
ja: Subversion を支援したり利用したりするツールについて議論します。これには 別のクライアントプログラム、リポジトリ参照ツール、などが含まれます。

note: Tag: title
en: This Book is Free
ja: この本はフリーです

note: Tag: para
en: You will always find the latest version of this book in the book's own Subversion repository.
ja: この本の最新版は、この本専用のSubversionリポジトリにあります。

note: Tag: title
en: Acknowledgments
ja: 謝辞

note: Tag: para
en: This book would not be possible (nor very useful) if Subversion did not exist. For that, the authors would like to thank Brian Behlendorf and CollabNet for the vision to fund such a risky and ambitious new Open Source project; Jim Blandy for the original Subversion name and design&mdash;we love you, Jim; Karl Fogel for being such a good friend and a great community leader, in that order.
ja: この本は Subversion が存在しなければ不可能でした(し、役に立つものに なることもありませんでした)。そういうわけで、著者はこのようなハイリスク で野心的な新しいオープンソースプロジェクトを支援してくれたBrian Behlendorf とCollabNetにまず感謝します; 次にSubversion の名称とその原型を設計したJim Blandy に対して感謝します&mdash; Jim、みな君を愛しているよ; そして最後に 良き友であると同時に偉大なコミュニティー指導者であるKarl Fogelに感謝します。

note: Tag: para
en: Oh, and thanks, Karl, for being too overworked to write this book yourself.
ja: そして、そうだ Karl、君にはこの本のことで、ずいぶん仕事させてしまったね。

note: Tag: para
en: Thanks to O'Reilly and our editors, Linda Mui and Tatiana Diaz for their patience and support.
ja: O'Reilly と我々の編集者であるLinda Muiと、Tatiana Diaz の忍耐と支援にたいして感謝します。

note: Tag: title
en: From Ben Collins-Sussman
ja: Ben Collins-Sussmanより

note: Tag: title
en: From Brian W. Fitzpatrick
ja: Brian W. Fitzpatrickより

note: Tag: title
en: From C. Michael Pilato
ja: C. Michael Pilatoより

note: Tag: title
en: What is Subversion?
ja: Subversionって何?

note: Tag: para
en: Some version control systems are also software configuration management (SCM) systems. These systems are specifically tailored to manage trees of source code, and have many features that are specific to software development&mdash;such as natively understanding programming languages, or supplying tools for building software. Subversion, however, is not one of these systems. It is a general system that can be used to manage <emphasis>any</emphasis> collection of files. For you, those files might be source code&mdash;for others, anything from grocery shopping lists to digital video mixdowns and beyond.
ja: バージョン管理システムのいくつかは、ソフトウェア構成管理システム(SCM) でもあります。そういうシステムは、ソースコードのツリーを管理するために 特別便利に作られています&mdash;たとえばプログラム言語をじかに理解する ことができたり、ソフトウェアを構成するのに必要なツールが付属していたり といった具合です。しかし Subversion はそのような種類のシステムでは ありません。 Subversionは<emphasis>どのような</emphasis> タイプのファイルの集合も管理できる一般的なシステムです。あなたにとって それはプログラムのソースコードかも知れません&mdash;しかし別の人にとっては 食料品の買い物リストから、デジタルビデオの編集、そしてもっと他のもの ですらあるでしょう。

note: Tag: title
en: Subversion's History
ja: Subversionの歴史

note: Tag: para
en: The original design team settled on some simple goals. They didn't want to break new ground in version control methodology, they just wanted to fix CVS. They decided that Subversion would match CVS's features, and preserve the same development model, but not duplicate CVS's most obvious flaws. And although it did not need to be a drop-in replacement for CVS, it should be similar enough that any CVS user could make the switch with little effort.
ja: 最初の設計チームはいくつかのシンプルな目標を決めました。それはバージョン 管理手法の新しい地平を切り開くようなことを目的とはせず、単に CVS の 不具合を修正するものであるとされました。Subversion は CVS の機能に合致し、 同じ開発モデルを踏襲するが、CVS のほとんどの明らかな不具合については 繰り返さないと決められました。そしてそれは CVS を単純な置き換えである必要 はないにせよ、CVS ユーザがわずかな労力によって移行できる程度には十分 似ているべきであるとされました。

note: Tag: para
en: After fourteen months of coding, Subversion became <quote>self-hosting</quote> on August 31, 2001. That is, Subversion developers stopped using CVS to manage Subversion's own source code, and started using Subversion instead.
ja: 14ヶ月のコーディングの後、Subversion は 2001/8/31 に <quote>自分で自分自身のソースコード管理</quote>が できるようになりました。Subversion開発者は、Subversionの自身のソースコード 管理にCVSを使うのをやめてSubversion自身を使えるようになったということです。

note: Tag: para
en: While CollabNet started the project, and still funds a large chunk of the work (it pays the salaries of a few full-time Subversion developers), Subversion is run like most open-source projects, governed by a loose, transparent set of rules that encourage meritocracy. CollabNet's copyright license is fully compliant with the Debian Free Software Guidelines. In other words, anyone is free to download, modify, and redistribute Subversion as he pleases; no permission from CollabNet or anyone else is required.
ja: CollabNet がこのプロジェクトを始め、いまだに作業の大部分に出資している わけです(Subversion のフルタイム開発者の給料を払っています)が、Subverion は大部分のオープンソースプロジェクトのように実力主義を促進するような緩やかで オープンないくつかの規則によって成り立っています。CollabNet のコピーライト ライセンスは Debian Free Software Guidelines に完全に合致したものです。 言い換えると、 誰でも自由にSubversionをダウンロードし、修正し、再配布できるということです。 CollabNet や他の誰かの許可を得る必要はありません。

note: Tag: title
en: Subversion's Features
ja: Subversionの機能

note: Tag: para
en: Subversion provides:
ja: Subversion は以下の機能を提供します:

note: Tag: term
en: Directory versioning
ja: ディレクトリのバージョン化

note: Tag: para
en: CVS only tracks the history of individual files, but Subversion implements a <quote>virtual</quote> versioned filesystem that tracks changes to whole directory trees over time. Files <emphasis>and</emphasis> directories are versioned.
ja: CVS は個々のファイルの履歴を追うことができるだけですが、 Subversion は時間とともにディレクトリツリー全体の変化も追うことのできる、 <quote>仮想的な</quote>バージョン化ファイルシステムを実装しています。 ファイル<emphasis>と、さらに</emphasis> ディレクトリもバージョン付け します。

note: Tag: term
en: True version history
ja: 真のバージョン履歴機能

note: Tag: para
en: Since CVS is limited to file versioning, operations such as copies and renames&mdash;which might happen to files, but which are really changes to the contents of some containing directory&mdash;aren't supported in CVS. Additionally, in CVS you cannot replace a versioned file with some new thing of the same name without the new item inheriting the history of the old&mdash;perhaps completely unrelated&mdash;file. With Subversion, you can add, delete, copy, and rename both files and directories. And every newly added file begins with a fresh, clean history all its own.
ja: CVS はファイルのバージョン化に機能が制限されているので、コピー や名称変更&mdash; これはファイルだけではなくディレクトリの内容も 変更する可能性があります&mdash; は CVS ではサポートされていません。 さらに CVS では古い履歴を継承しなければ同じ名前の全く新しい ファイル&mdash; おそらく全く無関係のファイル&mdash;によってすでに バージョン化されているファイルを置き換えることはできません。 Subversion ではファイルとディレクトリの両者に対して追加、削除、 コピー、名称変更をすることができます。そして新規追加されるすべての ファイルは、そこから新しく始まるきれいな履歴を持つことになります。

note: Tag: term
en: Atomic commits
ja: 不分割(Atomic)なコミット

note: Tag: para
en: A collection of modifications either goes into the repository completely, or not at all. This allows developers to construct and commit changes as logical chunks, and prevents problems that can occur when only a portion of a set of changes is successfully sent to the repository.
ja: 変更点の集まりは、それ全体がリポジトリに完全に反映されるか、 まったく反映されないかのどちらかです。これにより開発者は 論理的にひとまとまりの変更を作りコミットすることができ、 一部だけがリポジトリに反映されてしまうような問題を回避する ことができます。

note: Tag: term
en: Versioned metadata
ja: バージョン化されたメタデータ

note: Tag: para
en: Each file and directory has a set of properties&mdash;keys and their values&mdash;associated with it. You can create and store any arbitrary key/value pairs you wish. Properties are versioned over time, just like file contents.
ja: ファイルとディレクトリはそれぞれ関連した属性&mdash; キーと 値の組のことです&mdash; を持つことができます。任意の キー/値の組を生成し保存することができます。属性もファイルの内容と 同じようにバージョン化されます。

note: Tag: term
en: Choice of network layers
ja: ネットワーク層の選択

note: Tag: para
en: Subversion has an abstracted notion of repository access, making it easy for people to implement new network mechanisms. Subversion can plug into the Apache HTTP Server as an extension module. This gives Subversion a big advantage in stability and interoperability, and instant access to existing features provided by that server&mdash;authentication, authorization, wire compression, and so on. A more lightweight, standalone Subversion server process is also available. This server speaks a custom protocol which can be easily tunneled over SSH.
ja: Subversion はリポジトリアクセス用の抽象レイアがあり、新しい ネットワークプログラムを簡単に実装できるようになっています。 Subversion は HTTP サーバの拡張モジュールとして組み込むことも できます。こうすると Subversion は信頼性や相互連携性において 非常に有利になりサーバが提供している既存の機能をすぐに利用 できるようになります&mdash;認証、認可、データ圧縮、などです。 より簡易なスタンドアロンの Subversion プロセスも利用できます。 このサーバは独自のプロトコルによって SSH を利用したトンネル 通信を簡単に実行できます。

note: Tag: term
en: Consistent data handling
ja: データ処理の一貫性

note: Tag: para
en: Subversion expresses file differences using a binary differencing algorithm, which works identically on both text (human-readable) and binary (human-unreadable) files. Both types of files are stored equally compressed in the repository, and differences are transmitted in both directions across the network.
ja: Subversion は、バイナリ差分アルゴリズムを使ってファイルの差分を 表現します。これはテキスト(読むことのできるデータ)にも、バイナリ( 簡単に読むことのできないデータ)に対しても同じ方法で働きます。 どちらのタイプのデータもリポジトリ中に同じ形式で圧縮されて格納され、 差分はネットワーク上どちらの方向にも転送されます。

note: Tag: term
en: Efficient branching and tagging
ja: 効率的なブランチ、タグの作成

note: Tag: para
en: The cost of branching and tagging need not be proportional to the project size. Subversion creates branches and tags by simply copying the project, using a mechanism similar to a hard-link. Thus these operations take only a very small, constant amount of time.
ja: ブランチとタグを作成するコストはプロジェクトのサイズに比例するわけでは ありません。Subversionはハードリンクとして知られている方法とよく似た方法を使って、 単にプロジェクトをコピーすることでブランチとタグを作ります。そのため ブランチ、タグの作成は非常に短い、一定の時間しかかかりません。

note: Tag: term
en: Hackability
ja: 拡張しやすさ

note: Tag: para
en: Subversion has no historical baggage; it is implemented as a collection of shared C libraries with well-defined APIs. This makes Subversion extremely maintainable and usable by other applications and languages.
ja: Subversionは歴史的な遺物ではありません。よく設計された APIでできたCの共有ライブラリの集まりとして実装されています。 このことはSubversionの保守をとてもやりやすいものにしますし、 他のアプリケーションや 言語から利用しやすいものにします。

note: Tag: title
en: Subversion's Architecture
ja: Subversion の構成

note: Tag: para
en: On one end is a Subversion repository that holds all of your versioned data. On the other end is your Subversion client program, which manages local reflections of portions of that versioned data (called <quote>working copies</quote>). Between these extremes are multiple routes through various Repository Access (RA) layers. Some of these routes go across computer networks and through network servers which then access the repository. Others bypass the network altogether and access the repository directly.
ja: 一方の端はバージョン化されたすべてのデータがある Subversionリポジトリ です。もう一方はクライアントプログラムで、バージョン化されたデータの ローカルマシン上のコピー(これを<quote>作業コピー</quote>と言います)を 管理します。この二つの間にさまざまなリポジトリアクセス(RA)層を通じた 通信路があります。そのいくつかはコンピュータネットワークをまたいで リポジトリにアクセスするためのネットワークサーバ越しに通信します。 他のものはネットワークを利用せず直接リポジトリにアクセスします。

note: Tag: title
en: Subversion's Components
ja: Subversionの構成要素

note: Tag: para
en: Subversion, once installed, has a number of different pieces. The following is a quick overview of what you get. Don't be alarmed if the brief descriptions leave you scratching your head&mdash;there are <emphasis>plenty</emphasis> more pages in this book devoted to alleviating that confusion.
ja: Subversion はさまざま部品からできています。以下はその簡単な概要です。 ここでの簡単な説明で混乱してもあわてないでください; &mdash;混乱を 減らすために<emphasis>非常に多くの</emphasis>ページがこの後に用意して ありますので。

note: Tag: para
en: The command-line client program.
ja: コマンドラインのクライアントプログラムです。

note: Tag: para
en: A program for reporting the state (in terms of revisions of the items present) of a working copy.
ja: 作業コピーの(アイテムが存在するリビジョンに関係した)状態についての報告をするプログラムです。

note: Tag: para
en: A tool for creating, tweaking or repairing a Subversion repository.
ja: Subversionのリポジトリを調整したり修復するためのプログラムで主 システム管理者によって使われます。

note: Tag: para
en: A program for filtering Subversion repository dump streams.
ja: Subversion リポジトリのダンプファイル形式のデータに対するフィルタプログラムです。

note: Tag: para
en: A plug-in module for the Apache HTTP Server, used to make your repository available to others over a network.
ja: Apache HTTP サーバ用のプラグインモジュールです。リポジトリをネットワーク上の別のユーザが利用できるようにするものです。

note: Tag: para
en: A custom standalone server program, runnable as a daemon process or invokable by SSH; another way to make your repository available to others over a network.
ja: デーモンとして、またはSSHから起動されるスタンドアロンのサーバプログラムです。ネットワーク越しにリポジトリを使えるようにする別の方法です。

note: Tag: para
en: Assuming you have Subversion installed correctly, you should be ready to start. The next two chapters will walk you through the use of <command>svn</command>, Subversion's command-line client program.
ja: Subversionが正しくインストールされていれば、これで利用できるようになっているはずです。次の二つの章では、コマンドラインクライアントプログラム、 <command>svn</command>の使い方を説明します。

note: Tag: title
en: Fundamental Concepts
ja: 根本的な概念

note: Tag: para
en: This chapter is a short, casual introduction to Subversion. If you're new to version control, this chapter is definitely for you. We begin with a discussion of general version control concepts, work our way into the specific ideas behind Subversion, and show some simple examples of Subversion in use.
ja: この章ではSubversionの概要を説明します。 バージョン管理システムの利用が初めての人は、必ずこの章を読んでください。 一般的なバージョン管理の概念から始めて、Subversionの背後にあるアイディア を説明し、Subversionの使い方の簡単な例をお見せします。

note: Tag: para
en: Even though the examples in this chapter show people sharing collections of program source code, keep in mind that Subversion can manage any sort of file collection&mdash;it's not limited to helping computer programmers.
ja: この章の例では複数のプログラムソースコードの共有を扱いますが、Subversion はどのようなファイルの集まりも管理できることに注意してください&mdash; コンピュータプログラマだけを助けるものではないのです。

note: Tag: title
en: The Repository
ja: リポジトリ

note: Tag: para
en: Subversion is a centralized system for sharing information. At its core is a repository, which is a central store of data. The repository stores information in the form of a <firstterm>filesystem tree</firstterm>&mdash;a typical hierarchy of files and directories. Any number of <firstterm>clients</firstterm> connect to the repository, and then read or write to these files. By writing data, a client makes the information available to others; by reading data, the client receives information from others. <xref linkend="svn.basic.repository.dia-1"/> illustrates this.
ja: Subversion は共有情報の一元管理システムです。最も重要なのは リポジトリと呼ばれる、データの格納庫 です。リポジトリは情報を<firstterm>ファイルシステムツリー</firstterm> &mdash;一般的なファイルとディレクトリの階層構造&mdash;の形で格納します。 任意の数の<firstterm>クライアント</firstterm>がリポジトリにアクセスし このようなファイルの読み書きをします。データを書き込むことでクライアントは 他の人たちがその情報を使えるようにします。データを読み出すことでクライアントは 他の人たちの情報を受け取ります。<xref linkend="svn.basic.repository.dia-1"/>はこれ を表したものです。

note: Tag: title
en: A typical client/server system
ja: 典型的なクライアント/サーバシステム

note: Tag: para
en: So why is this interesting? So far, this sounds like the definition of a typical file server. And indeed, the repository <emphasis>is</emphasis> a kind of file server, but it's not your usual breed. What makes the Subversion repository special is that <emphasis>it remembers every change</emphasis> ever written to it: every change to every file, and even changes to the directory tree itself, such as the addition, deletion, and rearrangement of files and directories.
ja: どうしてこんなことが興味深いのか? ここまでのところでは、典型的なファイルサーバの 定義にすぎないように思います。そして実際、リポジトリはファイルサーバの <emphasis>一種</emphasis>です。が、普通言うようなものとは少し 違います。Subversionのリポジトリの特徴はそれまで書き込まれた <emphasis>すべての修正をすべて憶えている</emphasis>ところ です。すべてのファイル変更についても、また、ディレクトリツリーの自身の変更に ついてもそうです。このような変更は、ファイルやディレクトリの追加、削除、 再配置、などによって起こります。

note: Tag: title
en: Versioning Models
ja: バージョン管理モデル

note: Tag: para
en: The core mission of a version control system is to enable collaborative editing and sharing of data. But different systems use different strategies to achieve this. It's important to understand these different strategies for a couple of reasons. First, it will help you compare and contrast existing version control systems, in case you encounter other systems similar to Subversion. Beyond that, it will also help you make more effective use of Subversion, since Subversion itself supports a couple of different ways of working.
ja: バージョン管理システムの主要な任務は、協調的な編集とデータの共有を可能にすることです。しかし異なるシステムでは、これを実現するために異なる戦略をとっています。2つの理由からこれらの異なる戦略を理解することが重要です。第一に、Subversion ににている他のバージョン管理に出会った場合に、既存のバージョン管理システムと比較し、対照するのに役立ちます。さらに、Subversion をもっと効率的に利用することに役立ちます。なぜなら、Subversion 自身も2つの異なった作業方法に対応しているからです。

note: Tag: title
en: The Problem of File-Sharing
ja: ファイル共有の問題

note: Tag: para
en: All version control systems have to solve the same fundamental problem: how will the system allow users to share information, but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.
ja: あらゆるバージョン管理システムはどれも基本的な一つの問題を解かなくてはなりません: どうやってユーザに情報を共有させつつ、お互いの変更点が重ならないようにするか、です。 リポジトリ上の別の人の変更を間違って上書きしてしまうことは簡単に 起こりえます。

note: Tag: para
en: Consider the scenario shown in <xref linkend="svn.basic.vsn-models.problem-sharing.dia-1"/>. Suppose we have two co-workers, Harry and Sally. They each decide to edit the same repository file at the same time. If Harry saves his changes to the repository first, then it's possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file. While Harry's version of the file won't be lost forever (because the system remembers every change), any changes Harry made <emphasis>won't</emphasis> be present in Sally's newer version of the file, because she never saw Harry's changes to begin with. Harry's work is still effectively lost&mdash;or at least missing from the latest version of the file&mdash;and probably by accident. This is definitely a situation we want to avoid!
ja: に示したこんな状況を考えてみてください: 二人の同僚、Harry と Sally がいます。 二人は同時に同じリポジトリ内のファイルを編集することにしました。 もし Harry が先に彼の変更をリポジトリに書き込めば、多分、(その少し あとで) Sally は間違って彼女の新しいバージョンでそれを上書きしてしまう でしょう。Harry のバージョンは永久に失われることはありません(と、いうのは バージョン管理システムはすべての変更を記録しているため)が、 Harry がやった修正は、どれも Sally の新しいバージョンには <emphasis>現れることがありません</emphasis>。編集時には 彼女は Harry の変更を見ることはできないからです。Harry の作業は、 実質的には失われてしまい、&mdash;あるいは少なくとも最新のバージョンからは 失われてしまい、&mdash; しかもおそらくそれは二人が意図したことではないで しょう。これこそわれわれが避けなくてはならない状況です。

note: Tag: title
en: The problem to avoid
ja: 避けなくてはならない問題

note: Tag: title
en: The Lock-Modify-Unlock Solution
ja: ロック・修正・ロック解除の解法

note: Tag: para
en: Many version control systems use a <firstterm>lock-modify-unlock</firstterm> model to address the problem of many authors clobbering each other's work. In this model, the repository allows only one person to change a file at a time. This exclusivity policy is managed using locks. Harry must <quote>lock</quote> a file before he can begin making changes to it. If Harry has locked a file, then Sally cannot also lock it, and therefore cannot make any changes to that file. All she can do is read the file, and wait for Harry to finish his changes and release his lock. After Harry unlocks the file, Sally can take her turn by locking and editing the file. <xref linkend="svn.basic.vsn-models.lock-unlock.dia-1"/> demonstrates this simple solution.
ja: 多くのバージョン管理システムでは、 <firstterm>ロック・修正・ロック解除</firstterm>のモデルを使ってこの問題 を扱います。そのようなシステムでは リポジトリ中のファイルを変更できるのは一度に一人だけです。 最初 Harry はファイルに変更を加える前に、<quote>ロック</quote>しなくては なりません。ファイルのロックは、図書館から本を借りるのにいろんな意味で よく似ています。もし Harry がファイルをロックすると、Sally は同じ ファイルに変更することができなくなります。ロックしようとすれば、 リポジトリはその要求を拒否します。彼女ができるのはそのファイルを 読むことと、Harryが仕事を終えてロック解除してくれるのを待つことだけ です。Harry がロックを解除したあと、彼の番は終わり、今度はSallyが ロックして編集することができる番になります。<xref linkend="svn.basic.vsn-models.lock-unlock.dia-1"/>はこの単純な解法の例です。

note: Tag: title
en: The lock-modify-unlock solution
ja: ロック・修正・ロック解除の解法

note: Tag: para
en: The problem with the lock-modify-unlock model is that it's a bit restrictive, and often becomes a roadblock for users:
ja: ロック・修正・ロック解除のモデルの問題は、ファイル管理が少し厳しすぎる ことで、しばしば、ユーザとって作業の障害になります:

note: Tag: para
en: <emphasis>Locking may cause administrative problems.</emphasis> Sometimes Harry will lock a file and then forget about it. Meanwhile, because Sally is still waiting to edit the file, her hands are tied. And then Harry goes on vacation. Now Sally has to get an administrator to release Harry's lock. The situation ends up causing a lot of unnecessary delay and wasted time.
ja: <emphasis>ロックすることは管理上の問題を起こすかも知れません。</emphasis> ときどきHarryはファイルをロックしたあとでそのことを忘れてしまいます。 いっぽう Sally はずっと自分の番を待っているので、その間何もすることが できません。そしてHarryはそのままバカンスに行ってしまい、Sallyとしては 管理者に対してHarryのロックを解除してもらうように頼まなくてはならなく なります。この状況は不要な遅れと、時間の無駄を起こします。

note: Tag: para
en: <emphasis>Locking may cause unnecessary serialization.</emphasis> What if Harry is editing the beginning of a text file, and Sally simply wants to edit the end of the same file? These changes don't overlap at all. They could easily edit the file simultaneously, and no great harm would come, assuming the changes were properly merged together. There's no need for them to take turns in this situation.
ja: <emphasis>ロックは不要な直列化を起こすかも知れません。</emphasis> Harryはそのテキストファイルの先頭の部分を修正して、Sally は同じファイルの 最後の部分を修正したいだけだとしたら? 二人の修正はまったく重なって いません。適当な形でマージされることさえ保証できれば、二人は同じファイル を同時に編集することができ、それが大きな問題にはならないでしょう。

note: Tag: title
en: The Copy-Modify-Merge Solution
ja: コピー・修正・マージの解法

note: Tag: para
en: Here's an example. Say that Harry and Sally each create working copies of the same project, copied from the repository. They work concurrently, and make changes to the same file A within their copies. Sally saves her changes to the repository first. When Harry attempts to save his changes later, the repository informs him that his file A is <firstterm>out-of-date</firstterm>. In other words, that file A in the repository has somehow changed since he last copied it. So Harry asks his client to <firstterm>merge</firstterm> any new changes from the repository into his working copy of file A. Chances are that Sally's changes don't overlap with his own; so once he has both sets of changes integrated, he saves his working copy back to the repository. <xref linkend="svn.basic.vsn-models.copy-merge.dia-1"/> and <xref linkend="svn.basic.vsn-models.copy-merge.dia-2"/> show this process.
ja: 例をあげます。 Harry とSally が同じプロジェクトに対するそれぞれの作業コピーをリポジトリ の内容をコピーして作ったとします。 彼らは平行して作業し、変更をまずは自分の作業コピーの同じファイルAに対して 行います。Sally は自分の変更を先にリポジトリに保存します。 Harry が変更をあとで保存したいと思ったとき、リポジトリは、彼に対して Aは既に<firstterm>最新ではない</firstterm>ことを伝えます。 言い換えると、リポジトリにあるファイルAは彼がそれをコピーした後で 別の人によって修正されていることを伝えます。そこで Harry は、Subversion のクライアントプログラムに、自分の作業コピーAに対して、リポジトリにある 新しい変更点を<firstterm>マージ</firstterm>するように要求します。 Sally の変更が彼のもので上書きされることはありえません。ひとたび彼が 両方の変更を統合してしまえば、自分の作業コピーをリポジトリに書き戻す ことができます。<xref linkend="svn.basic.vsn-models.copy-merge.dia-1"/>と <xref linkend="svn.basic.vsn-models.copy-merge.dia-2"/> はこの処理を示しています。

note: Tag: title
en: The copy-modify-merge solution
ja: コピー・修正・マージの解法

note: Tag: title
en: The copy-modify-merge solution (continued)
ja: コピー・修正・マージの解法(続き)

note: Tag: para
en: But what if Sally's changes <emphasis>do</emphasis> overlap with Harry's changes? What then? This situation is called a <firstterm>conflict</firstterm>, and it's usually not much of a problem. When Harry asks his client to merge the latest repository changes into his working copy, his copy of file A is somehow flagged as being in a state of conflict: he'll be able to see both sets of conflicting changes, and manually choose between them. Note that software can't automatically resolve conflicts; only humans are capable of understanding and making the necessary intelligent choices. Once Harry has manually resolved the overlapping changes&mdash;perhaps after a discussion with Sally&mdash;he can safely save the merged file back to the repository.
ja: しかし、Sallyの変更点がHarryのと<emphasis>重なって</emphasis> いたら? そのときはどうなるのでしょう? この状況は<firstterm>衝突</firstterm>と 呼ばれ、普通はあまり大きな問題にはなりません。 Harry がSubversionクライアントプログラムにリポジトリの最新の変更を 自分の作業コピーにマージするように要求したとき、彼のAファイルの作業 コピーは、衝突の状態としてマークされます。彼は両方の変更の衝突した 部分を見ることができ、どちらを選ぶかを選択します。ソフトウェア自体が 自動的に衝突を解決することはできないのに注意してください; 人間だけが 理解し、正しく選択する力を持っています。Harry がいったん重なっている 部分の修正を手で解消したら&mdash;たぶんSallyと衝突について話し合った あと&mdash;マージされたファイルをリポジトリに安全に書き戻すことが できます。

note: Tag: title
en: When Locking is Necessary
ja: ロックが必要な場合

note: Tag: para
en: While the lock-modify-unlock model is considered generally harmful to collaboration, there are still times when locking is appropriate.
ja: ロック・修正・ロック解除のモデルは一般的には複数で協力して作業する場合には 有害だと考えられていますが、場合によってはロックが有効なこともあります。

note: Tag: para
en: The copy-modify-merge model is based on the assumption that files are contextually mergeable: that is, that the majority of the files in the repository are line-based text files (such as program source code). But for files with binary formats, such as artwork or sound, it's often impossible to merge conflicting changes. In these situations, it really is necessary to users to take strict turns when changing the file. Without serialized access, somebody ends up wasting time on changes that are ultimately discarded.
ja: コピー・修正・マージモデルはファイルが文脈を考慮した上でマージ可能である という前提に基づいています: つまり、リポジトリ中の大部分のファイルが 行単位のテキストファイルである場合を想定しています(プログラムのソース コードなどがその典型です)。しかしバイナリ形式のファイル、たとえば画像や 音声などの場合、衝突した部分の変更点をマージすることは不可能なのが 普通です。そのような場合に必要なのは、ユーザはファイルを変更する上で、 厳密に自分の順番を確保したいということです。順序性を保った形でのアクセス がなければ、最終的には捨ててしまうことになるある人の修正によって時間が 無駄になってしまいます。

note: Tag: title
en: Subversion in Action
ja: 実行中のSubversion

note: Tag: para
en: It's time to move from the abstract to the concrete. In this section, we'll show real examples of Subversion being used.
ja: そろそろ抽象論から具体的な議論に移るときがきました。この章で はSubversion が利用される実際の例をお見せします。

note: Tag: title
en: Subversion Repository URLs
ja: Subversion リポジトリの URL

note: Tag: screen
en: C:\&gt; svn checkout file:///X:/path/to/repos
    &hellip;
    C:\&gt; svn checkout "file:///X|/path/to/repos"
    &hellip;
ja: C:¥&gt; svn checkout file:///X:/path/to/repos
    &hellip;
    C:¥&gt; svn checkout "file:///X|/path/to/repos"
    &hellip;

note: Tag: para
en: Finally, it should be noted that the Subversion client will automatically encode URLs as necessary, just like a web browser does. For example, if a URL contains a space or upper-ASCII character:
ja: 最後に、Subversion クライアントは必要に応じてちょうど Web ブラウザがや るような具合に自動的に URL をエンコードすることにも注意してください。 たとえば、 URL が空白あるいは上位の ASCII 文字が含まれている場合:

note: Tag: screen
en: $ svn checkout "http://host/path with space/project/españa"
ja: $ svn checkout "http://host/path with space/project/espa単a"

note: Tag: para
en: &hellip;then Subversion will escape the unsafe characters and behave as if you had typed:
ja: &hellip; Subversion は安全に表示できる文字に変換して、あなた自身がそのように 入力したかのように動作します:

note: Tag: para
en: If the URL contains spaces, be sure to place it within quote marks, so that your shell treats the whole thing as a single argument to the <command>svn</command> program.
ja: URL が空白を含む場合、引用符の中にあることを確認してください。これでシェ ルは <command>svn</command>プログラムに対してその文字列全体が単一の引 数であるものとして扱うことができるようになります。

note: Tag: title
en: Working Copies
ja: 作業コピー

note: Tag: para
en: You've already read about working copies; now we'll demonstrate how the Subversion client creates and uses them.
ja: 既に作業コピーについて読んできたことと思いますので、Subversionのクライアント プログラムが作業コピーを作ったり使ったりする様子を見てみます。

note: Tag: para
en: A Subversion working copy is an ordinary directory tree on your local system, containing a collection of files. You can edit these files however you wish, and if they're source code files, you can compile your program from them in the usual way. Your working copy is your own private work area: Subversion will never incorporate other people's changes, nor make your own changes available to others, until you explicitly tell it to do so. You can even have multiple working copies of the same project.
ja: Subversion 作業コピーは、自分のローカルシステム上の普通の ディレクトリツリーで、その中には複数のファイルがあります。あなたは 望むファイルを編集することができ、ソースコードファイルなら、それを 普通にコンパイルすることができます。作業コピーは自分だけの作業領域 です: Subversion はほかの人の変更を持ち込んだりしませんし、明示的に そうしてくれと言うまで、自分の変更を他の人に見せたりすることも ありません。同じプロジェクト用に一人で複数の作業コピーを持つことさえできます。

note: Tag: para
en: After you've made some changes to the files in your working copy and verified that they work properly, Subversion provides you with commands to <quote>publish</quote> your changes to the other people working with you on your project (by writing to the repository). If other people publish their own changes, Subversion provides you with commands to merge those changes into your working directory (by reading from the repository).
ja: 作業コピーのファイルに変更を加え、それがうまく動作することを 確認したあとで、Subversion はその変更を同じプロジェクトであなたと一緒に 作業しているほかの人に<quote>公開</quote>するためのコマンドを(リポジトリに 書き込むことで)用意します。もし他の人が自分自身の変更を公開したとき にはSubversionはその変更を自分の作業コピーにマージするコマンドを用意します。 (リポジトリの内容を読み出すことで。)

note: Tag: para
en: A working copy also contains some extra files, created and maintained by Subversion, to help it carry out these commands. In particular, each directory in your working copy contains a subdirectory named <filename>.svn</filename>, also known as the working copy <firstterm>administrative directory</firstterm>. The files in each administrative directory help Subversion recognize which files contain unpublished changes, and which files are out-of-date with respect to others' work.
ja: 作業コピーには、Subversionによって管理される、いくつかの特殊な ファイルもあり、その助けによって(読み出し、書き込みなどの)コマンドを 実行します。特に作業コピー中のディレクトリには<filename>.svn</filename> という名前の、<firstterm>管理ディレクトリ</firstterm>として知られる サブディレクトリがあります。管理ディレクトリのそれぞれのファイルは Subversionがどのファイルにまだ公開していない変更があるか、どのファイルが 他の人の作業によって最新でなくなっているか理解するのを助けるものです。

note: Tag: para
en: A typical Subversion repository often holds the files (or source code) for several projects; usually, each project is a subdirectory in the repository's filesystem tree. In this arrangement, a user's working copy will usually correspond to a particular subtree of the repository.
ja: 典型的な Subversion リポジトリは複数のプロジェクトのファイル (またはソースコード)をつかんでいます。普通、それぞれのプロジェクトは リポジトリのファイルシステムツリー中のサブディレクトリになっています。 この構成によって、ユーザの作業コピーは普通、リポジトリの特定の 部分木に対応しています。

note: Tag: para
en: For example, suppose you have a repository that contains two software projects, <literal>paint</literal> and <literal>calc</literal>. Each project lives in its own top-level subdirectory, as shown in <xref linkend="svn.basic.in-action.wc.dia-1"/>.
ja: たとえば二つのソフトウェアプロジェクト、<literal>paint</literal>と <literal>calc</literal>を含むリポジトリが あるとします。それぞれのプロジェクトはそれぞれの最上位サブディレクトリ にあります。<xref linkend="svn.basic.in-action.wc.dia-1"/>のような状況です。

note: Tag: title
en: The repository's filesystem
ja: リポジトリのファイルシステム

note: Tag: para
en: To get a working copy, you must <firstterm>check out</firstterm> some subtree of the repository. (The term <quote>check out</quote> may sound like it has something to do with locking or reserving resources, but it doesn't; it simply creates a private copy of the project for you.) For example, if you check out <filename>/calc</filename>, you will get a working copy like this:
ja: 作業コピーを持ってくるため、リポジトリ中のどれかのサブツリーを <firstterm>チェックアウト</firstterm>しなくてはなりません。 (<quote>check out</quote> という言葉は何かをロックしたり保護したり するような響きがありますがそうではありません; それは単に自分のための プロジェクトのコピーを作るだけです。) たとえば<filename>/calc</filename>をチェックアウトするとこんな 感じで作業コピーを手に入れることができます:

note: Tag: para
en: Suppose you have a collaborator, Sally, who checked out a working copy of <filename>/calc</filename> at the same time you did. When you commit your change to <filename>button.c</filename>, Sally's working copy is left unchanged; Subversion only modifies working copies at the user's request.
ja: 一緒に作業している Sally が、あなたがチェックアウトしたのと同じ時刻に <filename>/calc</filename> の作業コピーを自分用にチェックアウト したとしましょう。あなたが<filename>button.c</filename>への自分の 変更をコミットしても、Sallyの作業コピーは変更されない状態のままです。 Subversionはユーザの要求によって初めて作業コピーの内容を変更します。

note: Tag: para
en: To bring her project up to date, Sally can ask Subversion to <firstterm>update</firstterm> her working copy, by using the Subversion <command>update</command> command. This will incorporate your changes into her working copy, as well as any others that have been committed since she checked it out.
ja: 作業内容をプロジェクトの最新の状態にするには、SallyはSubversionに 自分の作業コピーを<firstterm>更新</firstterm> するように依頼しなくては なりません。これには<command>update</command> コマンドを使います。 これはあなたの変更を彼女の作業コピーにマージしますし、彼女がチェック アウトしたあとで他の人がコミットしたすべての部分についてもマージします。

note: Tag: para
en: The output from the <command>svn update</command> command indicates that Subversion updated the contents of <filename>button.c</filename>. Note that Sally didn't need to specify which files to update; Subversion uses the information in the <filename>.svn</filename> directory, and further information in the repository, to decide which files need to be brought up to date.
ja: <command>svn update</command>コマンドからの出力は Subversionが<filename>button.c</filename>の内容を 更新したことを示しています。Sally はどのファイルを更新 するかを指定する必要がないのに注意してください。Subversion は <filename>.svn</filename>ディレクトリの情報と リポジトリの情報を使って、どのファイルを更新しなくてはならないか を決定します。

note: Tag: title
en: Repository URLs
ja: リポジトリのURL

note: Tag: title
en: Repository Access URLs
ja: リポジトリにアクセスするためのURL

note: Tag: entry
en: Access Method
ja: アクセス方法

note: Tag: entry
en: direct repository access (on local disk)
ja: リポジトリへの直接アクセス (ローカルディスク上)

note: Tag: entry
en: access via WebDAV protocol to Subversion-aware Apache server
ja: Subversionを考慮したApacheサーバへのWebDAVプロトコル経由でのアクセス

note: Tag: entry
en: same as <literal>http://</literal>, but with SSL encryption.
ja: <literal>http://</literal>と同じだが、SSLによる暗号化

note: Tag: entry
en: access via custom protocol to an <literal>svnserve</literal> server
ja: <literal>svnserve</literal> サーバに対する独自TCP/IPプロトコル経由での アクセス

note: Tag: entry
en: same as <literal>svn://</literal>, but through an SSH tunnel.
ja: <literal>svn://</literal>と同じですが、SSH トンネルを利用します。

note: Tag: title
en: Revisions
ja: リビジョン

note: Tag: para
en: Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a <firstterm>revision</firstterm>. Each revision is assigned a unique natural number, one greater than the number of the previous revision. The initial revision of a freshly created repository is numbered zero, and consists of nothing but an empty root directory.
ja: リポジトリがコミットを受け付けるときは常に <firstterm>リビジョン</firstterm>と呼ばれるファイルシステム ツリーの新しい状態を作ります。それぞれのリビジョンには 一意な自然数が割り当てられます。前のバージョンよりも 後のバージョンのほうが数が大きくなります。 リポジトリ新規作成時の最初のバージョンはゼロで、ルートディレクトリ 以外には何も含まれていません。

note: Tag: para
en: illustrates a nice way to visualize the repository. Imagine an array of revision numbers, starting at 0, stretching from left to right. Each revision number has a filesystem tree hanging below it, and each tree is a <quote>snapshot</quote> of the way the repository looked after a commit.
ja: はリポジトリを視覚化するうまい方法 を示しています。0から始まるリビジョン番号が、左から右に追加されていく 状況を想像してください。それぞれのリビジョン番号には対応した ファイルシステム木があり、それぞれの木はコミット 後のリポジトリの状態を示す<quote>スナップショット</quote> です。

note: Tag: title
en: The repository
ja: リポジトリ

note: Tag: title
en: Global Revision Numbers
ja: グローバルリビジョン番号

note: Tag: para
en: It's important to note that working copies do not always correspond to any single revision in the repository; they may contain files from several different revisions. For example, suppose you check out a working copy from a repository whose most recent revision is 4:
ja: 作業コピーは常にリポジトリのどれか一つのリビジョン対応しているとは 限らないことに注意してください。複数の異なるリビジョンのファイル を含んでいるかも知れません。たとえば、最新リビジョン番号が4である リポジトリから作業コピーをチェックアウトしたとします:

note: Tag: para
en: At the moment, this working directory corresponds exactly to revision 4 in the repository. However, suppose you make a change to <filename>button.c</filename>, and commit that change. Assuming no other commits have taken place, your commit will create revision 5 of the repository, and your working copy will now look like this:
ja: この時点では、作業コピーはリポジトリのリビジョン4と完全に一致しています。 しかし、ここで <filename>button.c</filename>に変更を加え その変更をコミットしたとします。他にコミットした人がいない場合、 今回のコミットはリポジトリのバージョンを5にあげ、作業コピーの内容は 以下のようになります:

note: Tag: para
en: Suppose that, at this point, Sally commits a change to <filename>integer.c</filename>, creating revision 6. If you use <command>svn update</command> to bring your working copy up to date, then it will look like this:
ja: この時点でSallyが<filename>integer.c</filename>に対する修正を コミットし、リビジョンを6にあげたとします。ここでもし、<command>svn update</command> コマンドであなたの作業コピーを更新すると、次のようになるでしょう:

note: Tag: para
en: Sally's change to <filename>integer.c</filename> will appear in your working copy, and your change will still be present in <filename>button.c</filename>. In this example, the text of <filename>Makefile</filename> is identical in revisions 4, 5, and 6, but Subversion will mark your working copy of <filename>Makefile</filename> with revision 6 to indicate that it is still current. So, after you do a clean update at the top of your working copy, it will generally correspond to exactly one revision in the repository.
ja: Sallyの<filename>integer.c</filename>への変更は あなたの作業コピーに現れますが、<filename>button.c</filename> に対するあなたの変更はそのままです。この例では、 <filename>Makefile</filename>のテキストは、リビジョン4,5,6で まったく同一のものですが、Subversionはあなたの作業コピー中の <filename>Makefile</filename>のリビジョンを6として、 それが最新であることを表現します。それで自分の作業コピーに きれいなアップデートをかけたときには、一般に作業コピーは リポジトリのある特定のバージョンと完全に一致します。

note: Tag: title
en: How Working Copies Track the Repository
ja: 作業コピーはどのようにリポジトリを追いかけるか

note: Tag: para
en: For each file in a working directory, Subversion records two essential pieces of information in the <filename>.svn/</filename> administrative area:
ja: 作業コピー中のそれぞれのファイルについて、Subversionは 二つの本質的な情報を<filename>.svn/</filename>管理領域に 記録します:

note: Tag: para
en: what revision your working file is based on (this is called the file's <firstterm>working revision</firstterm>), and
ja: あなたの作業ファイルは、どのリビジョンに基づいているか (これはファイルの<firstterm>作業リビジョン</firstterm>と呼ばれます)、 そして

note: Tag: para
en: a timestamp recording when the local copy was last updated by the repository.
ja: リポジトリとの対話によって作業コピーが最後に更新された時刻

note: Tag: para
en: Given this information, by talking to the repository, Subversion can tell which of the following four states a working file is in:
ja: これらの情報とリポジトリとの対話によって、Subversionは作業ファイルの それぞれが、以下の四つの状態のどれにあるかを見分けることができます:

note: Tag: term
en: Unchanged, and current
ja: 変更なし、かつ最新

note: Tag: para
en: The file is unchanged in the working directory, and no changes to that file have been committed to the repository since its working revision. An <command>svn commit</command> of the file will do nothing, and an <command>svn update</command> of the file will do nothing.
ja: 作業コピーのファイルは変更されていないし、その作業リビジョン 以降に起きたリポジトリに対するコミットでもそのファイルに対する変更が ない状態。 そのファイルに対する<command>svn commit</command>は何も実行しませんし、 <command>svn update</command>も何もしません。

note: Tag: term
en: Locally changed, and current
ja: ローカルで変更あり、かつ最新

note: Tag: term
en: Unchanged, and out-of-date
ja: 変更なし、かつ、最新ではない

note: Tag: term
en: Locally changed, and out-of-date
ja: ローカルで変更あり、かつ最新ではない

note: Tag: para
en: The file has been changed both in the working directory, and in the repository. An <command>svn commit</command> of the file will fail with an <quote>out-of-date</quote> error. The file should be updated first; an <command>svn update</command> command will attempt to merge the public changes with the local changes. If Subversion can't complete the merge in a plausible way automatically, it leaves it to the user to resolve the conflict.
ja: ファイルは作業コピーでも、リポジトリでも変更されています。 ファイルに対する<command>svn commit</command>は<quote>out-of-date</quote> エラーになります。そのファイルはまず更新しなくてはなりません。 ファイルに対する<command>svn update</command>は公開されている変更点 を作業コピーの変更にマージしようとします。これが自動的にできないような 状況の場合、Subversionはユーザに衝突の解消をさせるためそのままにして おきます。

note: Tag: para
en: This may sound like a lot to keep track of, but the <command>svn status</command> command will show you the state of any item in your working copy. For more information on that command, see <xref linkend="svn.tour.cycle.examine.status"/>.
ja: これにはいろいろな情報の変化を追う必要があるように思いますが、 <command>svn status</command> コマンドを使えば、あなたの作業コピーの どのファイルの状態も表示できます。このコマンドについてのより詳しい情報は <xref linkend="svn.tour.cycle.examine.status"/> を見てください。

note: Tag: title
en: Mixed Revision Working Copies
ja: 混合リビジョン状態の作業コピー

note: Tag: para
en: As a general principle, Subversion tries to be as flexible as possible. One special kind of flexibility is the ability to have a working copy containing files and directories with a mix of different working revision numbers. Unfortunately, this flexibility tends to confuse a number of new users. If the earlier example showing mixed revisions perplexed you, here's a primer on both why the feature exists and how to make use of it.
ja: 原則として、Subversionはできる限り柔軟であろうとします。 この特別な例として、作業コピーに、いろいろな異なる作業リビジョン番号を もったファイルとディレクトリを共存させることが できます。前の例での混合リビジョンに戸惑っている人のために、 なぜこのような機能が必要で、どのように利用したらよいかを以下に示します。

note: Tag: title
en: Updates and Commits are Separate
ja: 更新とコミットは別の処理です

note: Tag: para
en: One of the fundamental rules of Subversion is that a <quote>push</quote> action does not cause a <quote>pull</quote>, nor the other way around. Just because you're ready to submit new changes to the repository doesn't mean you're ready to receive changes from other people. And if you have new changes still in progress, then <command>svn update</command> should gracefully merge repository changes into your own, rather than forcing you to publish them.
ja: Subversion での基本的な原則の一つは、<quote>作業コピーへの取得(push)</quote>の動作 が<quote>リポジトリへの反映(pull)</quote>動作を自動的に引き起こすことは ないし、逆もないということです。これは、あなたがリポジトリへの新しい変更点を 送信する用意ができているということが、他の人たちの変更点を受け取る用意が できていることを意味していることはないという、当たり前の理由によります。 そして自分がまだ引き続き新しい修正を加えている場合、 <command>svn update</command> は自分自身の作業コピー中にリポジトリの内容をうまく反映してくれるはずで、 このさい、あなたの側の変更点を強制的に他の人々に公開する必要はありません。

note: Tag: para
en: The main side-effect of this rule is that it means a working copy has to do extra bookkeeping to track mixed revisions, and be tolerant of the mixture as well. It's made more complicated by the fact that directories themselves are versioned.
ja: この規則はまた副次的に、作業コピーには混合リビジョンの状態を記録する ための特殊な仕組みが必要になり、またその状態に対して寛容でなければならない ことを意味しています。これはディレクトリ自身もバージョン管理できる ためさらに複雑な話になります。

note: Tag: para
en: For example, suppose you have a working copy entirely at revision 10. You edit the file <filename>foo.html</filename> and then perform an <command>svn commit</command>, which creates revision 15 in the repository. After the commit succeeds, many new users would expect the working copy to be entirely at revision 15, but that's not the case! Any number of changes might have happened in the repository between revisions 10 and 15. The client knows nothing of those changes in the repository, since you haven't yet run <command>svn update</command>, and <command>svn commit</command> doesn't pull down new changes. If, on the other hand, <command>svn commit</command> <emphasis>were</emphasis> to automatically download the newest changes, then it would be possible to set the entire working copy to revision 15&mdash;but then we'd be breaking the fundamental rule of <quote>push</quote> and <quote>pull</quote> remaining separate actions. Therefore the only safe thing the Subversion client can do is mark the one file&mdash;<filename>foo.html</filename>&mdash;as being at revision 15. The rest of the working copy remains at revision 10. Only by running <command>svn update</command> can the latest changes be downloaded, and the whole working copy be marked as revision 15.
ja: たとえば、作業コピーが完全にリビジョン 10 にあるとします。<filename>foo.html</filename> を編集して<command>svn commit</command>を実行した結果、リポジトリにリビジョン 15 ができたとします。このコミットが成醐ｻ駈ｵた直後では、多くの不慣れなユーザは 作業コピーは完全にリビジョン 15 にあるだろうと期待するかも知れませんがそうでは ないのです!。リビジョン10 とりビジョン15 までの間にリポジトリに対していろいろな変更が 起こったかも知れないのです。クライアント側ではリポジトリに起きたこの変更については 何も知りません。まだ <command>svn update</command> を実行していませんし、 <command>svn commit</command> は新しい変更点をリポジトリから取得したりはしないからです。 一方、もしかりに<command>svn commit</command>が自動的に最新の変更点をダウンロード <emphasis>するとすれば</emphasis>、作業コピー全体を完全にリビジョン 15 に設定することも可能 でしょう&mdash;しかしこれでは<quote>push</quote>と<quote>pull</quote> が独立した処理であるという基本的な原則を侵すことになります。 このため Subversion クライアントができる唯一の安全な方法は、ある特定の ファイル&mdash;<filename>foo.html</filename>&mdash;がリビジョン 15 にある という印をつけることだけです。作業コピーの残りのファイルはリビジョン 10 の ままなのです。<command>svn update</command>を実行することだけが、最新の変更点 をダウンロードする方法であり、これで作業コピー全体にリビジョン 15 の印がつきます。

note: Tag: title
en: Mixed revisions are normal
ja: 混合リビジョンは正常な状態です

note: Tag: para
en: The fact is, <emphasis>every time</emphasis> you run <command>svn commit</command>, your working copy ends up with some mixture of revisions. The things you just committed are marked as having larger working revisions than everything else. After several commits (with no updates in-between) your working copy will contain a whole mixture of revisions. Even if you're the only person using the repository, you will still see this phenomenon. To examine your mixture of working revisions, use the <command>svn status --verbose</command> command (see <xref linkend="svn.tour.cycle.examine.status"/> for more information.)
ja: 事実として、<command>svn commit</command>を実行するときは <emphasis>常に</emphasis>、あなたの作業コピーはあるいくつかのリビジョンの 混合状態となります。コミット対象となったファイルだけは、それ以外のファイル よりも新しい作業リビジョンになります。何度かのコミットの後で( その間に update を含めなければ)、作業コピーはいくつかのリビジョンの 混合状態になります。あなたがリポジトリを利用している唯一のユーザであったと してもやはりこの現象に出会うでしょう。作業リビジョンの混合状況を見る には<command>svn status --verbose</command>コマンドを利用して ください(さらに詳しい情報については <xref linkend="svn.tour.cycle.examine.status"/>を見てください)。

note: Tag: para
en: Often, new users are completely unaware that their working copy contains mixed revisions. This can be confusing, because many client commands are sensitive to the working revision of the item they're examining. For example, the <command>svn log</command> command is used to display the history of changes to a file or directory (see <xref linkend="svn.tour.history.log"/>). When the user invokes this command on a working copy object, they expect to see the entire history of the object. But if the object's working revision is quite old (often because <command>svn update</command> hasn't been run in a long time), then the history of the <emphasis>older</emphasis> version of the object is shown.
ja: 不慣れなユーザは自分の作業コピーが混合リビジョンになっていることには まったく気づかないことがよくあります。多くのクライアントコマンドは 処理対象となるアイテムの作業コピー上でのリビジョンが問題になるので 混乱することになります。例えば<command>svn log</command>コマンドは ファイルあるいはディレクトリの変更履歴を表示するために利用されます (<xref linkend="svn.tour.history.log"/>参照)。ユーザがこのコマンド を作業コピー上野オブジェクトに対して実行するとき、そのオブジェクト の完全な履歴を見れるものだと考えるでしょう。しかしそのオブジェクトの 作業コピー上のりビジョンが非常に古いものであった場合(これは <command>svn update</command>が長い期間にわたって実行されなかったような 場合におこります)、そのオブジェクトの <emphasis>より古い</emphasis> バージョン履歴が表示されるでしょう。

note: Tag: title
en: Mixed revisions are useful
ja: 混合リビジョンは役にたつものです

note: Tag: title
en: Mixed revisions have limitations
ja: 混合リビジョンには制約があります

note: Tag: para
en: However you make use of mixed revisions in your working copy, there are limitations to this flexibility.
ja: 作業コピー中を混合リビジョン状態に置くことはできますが、 この柔軟性には制約があります。

note: Tag: para
en: First, you cannot commit the deletion of a file or directory which isn't fully up-to-date. If a newer version of the item exists in the repository, your attempt to delete will be rejected, to prevent you from accidentally destroying changes you've not yet seen.
ja: まず、完全に最新状態ではないファイルやディレクトリの削除を コミットすることができません。より新しいバージョンのアイテムが リポジトリに存在する場合、この試みは拒否されます。まだあなたが 見ていない変更点を間違って消してしまうことを防ぐためです。

note: Tag: para
en: We've covered a number of fundamental Subversion concepts in this chapter:
ja: この章では、さまざまなSubversionの基本的な概念を扱いました:

note: Tag: para
en: We've introduced the notions of the central repository, the client working copy, and the array of repository revision trees.
ja: 中心となるリポジトリ、クライアント作業コピー、リポジトリリビジョンツリーの 並び、といった概念を導入しました。

note: Tag: para
en: We've seen some simple examples of how two collaborators can use Subversion to publish and receive changes from one another, using the <quote>copy-modify-merge</quote> model.
ja: どのように二人の共同作業者がSubversionを利用してお互いの修正点を公開したり 受け取ったりするかの簡単な例を見てきました。これには、<quote>コピー・修正・マージ</quote> のモデルを利用するのでした。

note: Tag: para
en: We've talked a bit about the way Subversion tracks and manages information in a working copy.
ja: Subversionが作業コピー内の情報をたどったり管理したりする方法について 少し触れました。

note: Tag: title
en: Basic Usage
ja: 基本的な使い方

note: Tag: para
en: Note that this chapter is not meant to be an exhaustive list of all Subversion's commands&mdash;rather, it's a conversational introduction to the most common Subversion tasks you'll encounter. This chapter assumes that you've read and understood <xref linkend="svn.basic"/> and are familiar with the general model of Subversion. For a complete reference of all commands, see <xref linkend="svn.ref"/>.
ja: この章は、Subversionコマンドの全体を列挙するのではないのに注意してください。 &mdash;そうではなく、普段一番よく利用するSubversionの操作についての対話的な手引き にしてあります。この章は、 <xref linkend="svn.basic"/> を読み、理解していることと、Subversionの一般的モデルをよく知っていることを前提 としています。コマンドの完全なリファレンスは、 <xref linkend="svn.ref"/> を見てください。

note: Tag: screen
en: $ svnadmin create /usr/local/svn/newrepos
    $ svn import mytree file:///usr/local/svn/newrepos/some/project \
                 -m "Initial import"
    Adding         mytree/foo.c
    Adding         mytree/bar.c
    Adding         mytree/subdir
    Adding         mytree/subdir/quux.h
    
    Committed revision 1.
ja: $ svnadmin create /usr/local/svn/newrepos
    $ svn import mytree file:///usr/local/svn/newrepos/some/project ¥
                 -m "Initial import"
    Adding         mytree/foo.c
    Adding         mytree/bar.c
    Adding         mytree/subdir
    Adding         mytree/subdir/quux.h
    
    Committed revision 1.

note: Tag: para
en: The previous example copied the contents of directory <filename>mytree</filename> under the directory <filename>some/project</filename> in the repository:
ja: 上の例はディレクトリ<filename>mytree</filename> の内容を リポジトリ中の<filename>some/project</filename> ディレクトリの下に コピーしています:

note: Tag: para
en: Note that after the import is finished, the original tree is <emphasis>not</emphasis> converted into a working copy. To start working, you still need to <command>svn checkout</command> a fresh working copy of the tree.
ja: インポートが終わった後で、もとのツリーが作業コピーに変換さ れたわけではないのに注意してください。作業を始めるには、さらにこのツリー のための最初の作業コピーを<command>svn checkout</command>する 必要があります。

note: Tag: title
en: Initial Checkout
ja: 最初のチェックアウト

note: Tag: para
en: While you can certainly check out a working copy with the URL of the repository as the only argument, you can also specify a directory after your repository URL. This places your working copy in the new directory that you name. For example:
ja: リポジトリのURLを唯一の引数として作業コピーをチェックアウトする こともできますが、リポジトリURLの後に、ディレクトリを指定することも できます。この場合、指定した新規のディレクトリ中に作業コピーを作ろうとします。 たとえば:

note: Tag: title
en: Basic Work Cycle
ja: 基本的な作業サイクル

note: Tag: para
en: Subversion has numerous features, options, bells and whistles, but on a day-to-day basis, odds are that you will only use a few of them. In this section we'll run through the most common things that you might find yourself doing with Subversion in the course of a day's work.
ja: Subversionはたくさんの機能、オプション、おまけが付いていますが、 日々の作業では、おそらくその中のいくつかを使うだけでしょう。 この章では一番よく起こることを説明します。

note: Tag: para
en: The typical work cycle looks like this:
ja: 典型的な作業サイクルは次のようなものです:

note: Tag: para
en: Update your working copy
ja: 作業コピーの更新

note: Tag: para
en: Make changes
ja: 変更

note: Tag: para
en: Examine your changes
ja: 自分の変更点の確認

note: Tag: para
en: Commit your changes
ja: 自分の変更のコミット

note: Tag: title
en: Update Your Working Copy
ja: 作業コピーの更新

note: Tag: para
en: When working on a project with a team, you'll want to update your working copy to receive any changes made since your last update by other developers on the project. Use <command>svn update</command> to bring your working copy into sync with the latest revision in the repository.
ja: チームを作って作業してるプロジェクトでは、自分の作業コピーを <firstterm>更新</firstterm>してプロジェクトの他のメンバーが自分の 更新処理後に加えた変更点をすべて受け取りたくなるでしょう。 <command>svn update</command>を使って自分の作業コピーを リポジトリの最新バージョンにあわせてください。

note: Tag: para
en: In this case, someone else checked in modifications to both <filename>foo.c</filename> and <filename>bar.c</filename> since the last time you updated, and Subversion has updated your working copy to include those changes.
ja: この場合、あなたが最後に更新してから、誰か別の人が <filename>foo.c</filename> と <filename>bar.c</filename> の両方に加えた変更をコミットし、Subversionはこの変更をあなたの 作業コピーに加えるために更新しました。

note: Tag: title
en: Make Changes to Your Working Copy
ja: 作業コピーに変更を加えること

note: Tag: title
en: Examine Your Changes
ja: 自分の変更点の調査

note: Tag: title
en: Look Ma! No Network!
ja: ママ見て、ネットワークが使えないの!

note: Tag: title
en: CVS Users: Hold That Update!
ja: CVS ユーザに告ぐ: 更新するのは、ちょっと待った!

note: Tag: para
en: You're probably used to using <command>cvs update</command> to see what changes you've made to your working copy. <command>svn status</command> will give you all the information you need regarding what has changed in your working copy&mdash;without accessing the repository or potentially incorporating new changes published by other users.
ja: 作業コピーにどのような変更を行ったかを確認するために、多分、 <command>cvs update</command>を使っていることでしょう。 <command>svn status</command> は、作業コピーに対して行われた 変更について、すべての必要な情報を提供してくれます &mdash; しかも、リポジトリに アクセスしませんし、他の人の行った変更が取り込まれる可能性もありません。

note: Tag: screen
en: A       stuff/loot/bloo.h   # file is scheduled for addition
    C       stuff/loot/lump.c   # file has textual conflicts from an update
    D       stuff/fish.c        # file is scheduled for deletion
    M       bar.c               # the content in bar.c has local modifications
ja: A       stuff/loot/bloo.h   # ファイルは追加予定
    C       stuff/loot/lump.c   # ファイルは更新によって競合している
    D       stuff/fish.c        # ファイルは削除予定
    M       bar.c               # bar.c は作業コピーで変更されている

note: Tag: para
en: The file, directory, or symbolic link <filename>item</filename> has been scheduled for addition into the repository.
ja: 通常ファイル、ディレクトリ、シンボリックリンクのいずれかである <filename>item</filename> はリポジトリに追加予告されています。

note: Tag: para
en: The file <filename>item</filename> is in a state of conflict. That is, changes received from the server during an update overlap with local changes that you have in your working copy. You must resolve this conflict before committing your changes to the repository.
ja: ファイル<filename>item</filename> は衝突の状態にあります。つまり、自分の作業コピーにあるローカルな変更が 更新時にサーバから受け取った変更部分と重なっています。リポジトリに 自分の変更点をコミットする前にこの衝突を解決しなくてはなりません。

note: Tag: para
en: The file, directory, or symbolic link <filename>item</filename> has been scheduled for deletion from the repository.
ja: 通常ファイル、ディレクトリ、シンボリックリンクのいずれかである <filename>item</filename> は リポジトリからの削除予告をされています。

note: Tag: para
en: The contents of the file <filename>item</filename> have been modified.
ja: ファイル<filename>item</filename>の内容は 修正されています。

note: Tag: para
en: Notice the two asterisks: if you were to run <command>svn update</command> at this point, you would receive changes to <filename>README</filename> and <filename>trout.c</filename>. This tells you some very useful information&mdash;you'll need to update and get the server changes on <filename>README</filename> before you commit, or the repository will reject your commit for being out-of-date. (More on this subject later.)
ja: 二つのアスタリスク ('*') に注意してください:この状態で <command>svn update</command> を実行すると <filename>README</filename>と<filename>trout.c</filename> の変更点を受け取ることになります。 これは非常に役に立つ情報です&mdash;コミットする前には更新して <filename>README</filename> に関するサーバ上の変更点を取得 しなくてはなりません。さもなければ、最新でないという理由で コミットは失敗するでしょう(詳しくは後で述べます)。

note: Tag: para
en: The <command>svn diff</command> command produces this output by comparing your working files against the cached <quote>pristine</quote> copies within the <filename>.svn</filename> area. Files scheduled for addition are displayed as all added-text, and files scheduled for deletion are displayed as all deleted text.
ja: <command>svn diff</command> コマンドは<filename>.svn</filename> 領域 にある、<quote>修正元リビジョン</quote> のコピーに対して作業コピー 中のファイルを比較した結果を出力します。 追加予告ファイルはすべて追加されたテキストとして表示され 削除予告されているファイルはすべて削除されたファイルとして表示 されます。

note: Tag: para
en: You could, for example, email the patch file to another developer for review or testing prior to commit.
ja: たとえば、パッチファイルを別の開発者に送り、コミット前に再検討や テストをすることができます。

note: Tag: para
en: Subversion reverts the file to its pre-modified state by overwriting it with the cached <quote>pristine</quote> copy from the <filename>.svn</filename> area. But also note that <command>svn revert</command> can undo <emphasis>any</emphasis> scheduled operations&mdash;for example, you might decide that you don't want to add a new file after all:
ja: Subversion はそのファイルを<filename>.svn</filename> 領域に ある<quote>修正元リビジョン</quote>のコピーを上書きすることに よって、修正以前の状態に戻します。 しかし、<command>svn revert</command> は<emphasis>どのような</emphasis> 予告操作も取り消すことができるのに注意してください&mdash;たとえば 最終的に新しいファイルを追加することをやめることができます:

note: Tag: para
en: <command>svn revert</command> <replaceable>ITEM</replaceable> has exactly the same effect as deleting <replaceable>ITEM</replaceable> from your working copy and then running <command>svn update -r BASE</command> <replaceable>ITEM</replaceable>. However, if you're reverting a file, <command>svn revert</command> has one very noticeable difference&mdash;it doesn't have to communicate with the repository to restore your file.
ja: <command>svn revert</command> <replaceable>ITEM</replaceable> は、作業コピーから <replaceable>ITEM</replaceable>を削除し、それから<command>svn update -r BASE</command> <replaceable>ITEM</replaceable>を実行したのとまったく同じ効果があります。 しかし、もしファイルをもとに戻そうとしているのなら、 <command>svn revert</command>には一つ重要な違いがあります&mdash;それはファイル を元に戻すにあたってリポジトリと通信する必要がないのです。

note: Tag: para
en: Or perhaps you mistakenly removed a file from version control:
ja: あるいは間違ってバージョン管理からファイルを消して しまったのかも知れません:

note: Tag: title
en: Resolve Conflicts (Merging Others' Changes)
ja: 衝突の解消(他の人の変更点のマージ)

note: Tag: para
en: We've already seen how <command>svn status -u</command> can predict conflicts. Suppose you run <command>svn update</command> and some interesting things occur:
ja: いままでで、<command>svn status -u</command>がどうやって衝突を 予告できたかを知っています。<command>svn update</command> を実行して、面白いことが起こったとします:

note: Tag: para
en: The <computeroutput>U</computeroutput> and <computeroutput>G</computeroutput> codes are no cause for concern; those files cleanly absorbed changes from the repository. The files marked with <computeroutput>U</computeroutput> contained no local changes but were <computeroutput>U</computeroutput>pdated with changes from the repository. The <computeroutput>G</computeroutput> stands for mer<computeroutput>G</computeroutput>ed, which means that the file had local changes to begin with, but the changes coming from the repository didn't overlap with the local changes.
ja: <computeroutput>U</computeroutput> と <computeroutput>G</computeroutput> のコードは考える ことはありません。この二つはリポジトリからの変更を きれいに吸収することができました。 <computeroutput>U</computeroutput> でマークされたファイルは ローカルでは何の変更もありませんでしたが、リポジトリからの 修正分で更新(<computeroutput>U</computeroutput>pdated)されました。 <computeroutput>G</computeroutput>はマージ( mer<computeroutput>G</computeroutput>ed)されたことを意味して いますが、これは、ファイルはローカルで変更されていたが、 リポジトリからの変更部分とまったく重ならなかったことを意味 しています。

note: Tag: para
en: Whenever a conflict occurs, three things typically occur to assist you in noticing and resolving that conflict:
ja: 衝突が起こると、普通はその衝突を知らせて解決することができるように 三つのことが起こります:

note: Tag: para
en: Subversion prints a <computeroutput>C</computeroutput> during the update, and remembers that the file is in a state of conflict.
ja: そのファイルがマージ可能なタイプのときには Subversion は更新処理中に<computeroutput>C</computeroutput> を 表示して、そのファイルが<quote>衝突している</quote>ことを知らせます。 (行番号に基づいた文脈マージ可能なファイルかどうかは <literal>svn:mime-type</literal>属性によって決まります。 詳しくは<xref linkend="svn.advanced.props.special.mime-type"/>を見てください。)

note: Tag: para
en: This is the file that was the <literal>BASE</literal> revision before you updated your working copy. That is, the file that you checked out before you made your latest edits.
ja: これは、作業コピーを更新する前の<literal>BASE</literal>リビジョンにあったファイル の内容です。つまり、そのファイルは最後にした編集の直前にした チェックアウト時点でのファイルです。

note: Tag: para
en: This is the file that your Subversion client just received from the server when you updated your working copy. This file corresponds to the <literal>HEAD</literal> revision of the repository.
ja: これは Subversionクライアントプログラムが作業コピーを更新したときに サーバから受け取ったファイルです。これは、リポジトリの<literal>HEAD</literal> リビジョンに対応しています。

note: Tag: para
en: Here <literal>OLDREV</literal> is the revision number of the file in your <filename>.svn</filename> directory and <literal>NEWREV</literal> is the revision number of the repository <literal>HEAD</literal>.
ja: ここで <literal>OLDREV</literal> は <filename>.svn</filename> ディレクトリにあるファイルのリビジョン番号で、<literal>NEWREV</literal>は <literal>HEAD</literal> リポジトリのリビジョン番号です。

note: Tag: para
en: For example, Sally makes changes to the file <filename>sandwich.txt</filename> in the repository. Harry has just changed the file in his working copy and checked it in. Sally updates her working copy before checking in and she gets a conflict:
ja: たとえば Sally がリポジトリにある<filename>sandwich.txt</filename> に変更を加えるとします。たった今、Harryは自分の作業コピーのそのファイルを変更 してコミットしました。Sally は自分が加えた変更をコミットする前に 作業コピーを更新しますが、そのとき衝突の報告を受けます:

note: Tag: screen
en: $ svn update
    C  sandwich.txt
    Updated to revision 2.
    $ ls -1
    sandwich.txt
    sandwich.txt.mine
    sandwich.txt.r1
    sandwich.txt.r2
ja: $ svn update
    C  sandwich.txt
    Updated to revision 2.
    $ ls -1
    sandwich.txt                       
    sandwich.txt.mine
    sandwich.txt.r1
    sandwich.txt.r2

note: Tag: para
en: At this point, Subversion will <emphasis>not</emphasis> allow you to commit the file <filename>sandwich.txt</filename> until the three temporary files are removed.
ja: このときSubversionは三つの一時ファイルが削除されるまで <filename>sandwich.txt</filename>のコミットを許可 <emphasis>しません</emphasis>。

note: Tag: para
en: If you get a conflict, you need to do one of three things:
ja: もし衝突があった場合は、三つのうちのどれかを する必要があります:

note: Tag: para
en: Merge the conflicted text <quote>by hand</quote> (by examining and editing the conflict markers within the file).
ja: <quote>手で</quote> 衝突テキストをマージします。( ファイル中の衝突マーカを調べ編集することによって)。

note: Tag: para
en: Copy one of the temporary files on top of your working file.
ja: 作業ファイルに、一時ファイルのどれかを上書きします。

note: Tag: para
en: Run <command>svn revert &lt;filename&gt;</command> to throw away all of your local changes.
ja: <command>svn revert &lt;filename&gt;</command>を 実行して、ローカルでしたすべての変更を捨てます。

note: Tag: para
en: Once you've resolved the conflict, you need to let Subversion know by running <command>svn resolved</command>. This removes the three temporary files and Subversion no longer considers the file to be in a state of conflict.
ja: ひとたび衝突を解消したら、<command>svn resolved</command>を実行 してSubversionにそのことを伝えます。これは三つの一時ファイルを 削除して、Subversionはもうそのファイルが衝突の状態にあるとは 考えなくなります。

note: Tag: para
en: You can always remove the temporary files yourself, but would you really want to do that when Subversion can do it for you? We didn't think so.
ja: 一時的なファイルは常に自分で削除することができます が、Subversionがせっかくコマンドを用意しているのに本当にそうしたい のでしょうか? そうは思えませんが。

note: Tag: title
en: Merging Conflicts by Hand
ja: 衝突を手でマージすること

note: Tag: para
en: Merging conflicts by hand can be quite intimidating the first time you attempt it, but with a little practice, it can become as easy as falling off a bike.
ja: 手で衝突をマージするのは最初とても嫌なものですが、 少し練習すればバイクから降りるのと同じくらい簡単に できるようになります。

note: Tag: para
en: The strings of less-than signs, equal signs, and greater-than signs are conflict markers, and are not part of the actual data in conflict. You generally want to ensure that those are removed from the file before your next commit. The text between the first two sets of markers is composed of the changes you made in the conflicting area:
ja: 小なり記号の文字列、イコールサイン、そして 大なり記号の文字列を衝突マーカと呼びますが、これは実際の 衝突を起こしたデータの一部ではありません。一般的には次のコミットの 前に取り除く必要があります。最初の二つのマーカの間のテキストは衝突領域に あなた自身がした変更です:

note: Tag: para
en: The text between the second and third sets of conflict markers is the text from Sally's commit:
ja: 二番目と三番目の衝突マーカの間のテキストは、 Sallyのコミットからのテキストです:

note: Tag: para
en: Usually you won't want to just delete the conflict markers and Sally's changes&mdash;she's going to be awfully surprised when the sandwich arrives and it's not what she wanted. So this is where you pick up the phone or walk across the office and explain to Sally that you can't get sauerkraut from an Italian deli.<footnote><para>And if you ask them for it, they may very well ride you out of town on a rail.</para></footnote> Once you've agreed on the changes you will check in, edit your file and remove the conflict markers.
ja: 通常、衝突マーカとSally の変更部分を単に削除するわけには いきません&mdash;そのようなことをするとSallyはsandwichを 受け取ったときにびっくりしますし、それは彼女が望んでいる ものではないでしょう。あなたは電話をかけるか、オフィスを またいで、Sallyに、二人の変更が衝突していることを説明 します。 <footnote><para> そして、あなたが頼めば、彼らは電車で町の外まであなたを つれていってくれるかも知れませんよ。 </para></footnote> ひとたびコミットする変更内容について合意がとれたら、 ファイルを編集し衝突マーカを削除します。

note: Tag: para
en: Now run <command>svn resolved</command>, and you're ready to commit your changes:
ja: これで、<command>svn resolved</command> を実行し 自分の変更をコミットする用意ができました:

note: Tag: title
en: Copying a File Onto Your Working File
ja: 作業ファイルの上にファイルをコピーすること

note: Tag: para
en: If you get a conflict and decide that you want to throw out your changes, you can merely copy one of the temporary files created by Subversion over the file in your working copy:
ja: 衝突が起こり、自分のした変更を捨てようとするときにはSubversionが作った 一時ファイルのどれかを単に作業コピー上に上書きすることができます:

note: Tag: title
en: Punting: Using <command>svn revert</command>
ja: Punting: <command>svn revert</command>の利用

note: Tag: para
en: If you get a conflict, and upon examination decide that you want to throw out your changes and start your edits again, just revert your changes:
ja: 衝突が起こり、調査の結果、自分の変更を捨てて編集をやり直す場合は 単に変更を revert することができます:

note: Tag: para
en: Note that when you revert a conflicted file, you don't have to run <command>svn resolved</command>.
ja: 衝突ファイルを元に戻すときは<command>svn resolved</command>を 実行する必要はないことに注意してください。

note: Tag: title
en: Commit Your Changes
ja: 変更点のコミット

note: Tag: para
en: Finally! Your edits are finished, you've merged all changes from the server, and you're ready to commit your changes to the repository.
ja: やっとここまできました。編集は終了し、サーバからの変更を すべてマージしました。これで自分の変更をリポジトリにコミット する準被ｳ器ｺできました。

note: Tag: para
en: The <command>svn commit</command> command sends all of your changes to the repository. When you commit a change, you need to supply a <firstterm>log message</firstterm>, describing your change. Your log message will be attached to the new revision you create. If your log message is brief, you may wish to supply it on the command line using the <option>--message</option> (or <option>-m</option>) option:
ja: <command>svn commit</command> コマンドは自分の変更点の すべてをリポジトリに送ります。変更をコミットするときには 変更点を説明する<firstterm>ログメッセージ</firstterm>を 与えてやる必要があります。ログメッセージは自分が作った 新しいリビジョンに付けられます。ログメッセージが簡単な 場合は<option>--message</option> (あるいは<option>-m</option>) オプションを使ってコマンドライン上で指定することができます:

note: Tag: para
en: The repository doesn't know or care if your changes make any sense as a whole; it only checks to make sure that nobody else has changed any of the same files that you did when you weren't looking. If somebody <emphasis>has</emphasis> done that, the entire commit will fail with a message informing you that one or more of your files is out-of-date:
ja: リポジトリは、変更点の内容に意味があるかどうかはまったく 気にしません。Subversionはあなたが見ていないところで、同じファイルに 他の人が修正していないことだけを確認します。もし他の人がそのような 変更を <emphasis>していたら</emphasis> 、コミットはあなたの変更 したファイルのどれかが最新ではないというメッセージを出して失敗します:

note: Tag: para
en: At this point, you need to run <command>svn update</command>, deal with any merges or conflicts that result, and attempt your commit again.
ja: このような場合は、<command>svn update</command>を実行し その結果のマージや衝突を解消し、もう一度コミットしてください。

note: Tag: title
en: Examining History
ja: 履歴の確認

note: Tag: para
en: Your Subversion repository is like a time machine. It keeps a record of every change ever committed, and allows you to explore this history by examining previous versions of files and directories as well as the metadata that accompanies them. With a single Subversion command, you can check out the repository (or restore an existing working copy) exactly as it was at any date or revision number in the past. However, sometimes you just want to <emphasis>peer into</emphasis> the past instead of <emphasis>going into</emphasis> the past.
ja: リポジトリはタイムマシンのようなところが あります。いままでコミットされたすべての変更を記録し、 ファイルやディレクトリ、それに付随したメタデータの以前のバージョン を見ることによって履歴を調べることができます。一つのSubversion コマンドを使って、過去の任意の日付やリビジョン番号時のリポジトリ の状態をチェックアウト(あるいは既にある作業コピーの復元)すること ができます。しかし、<emphasis>過去に戻る</emphasis> のではなく、 単に<emphasis>過去がどうだったかをちょっと覗いて</emphasis> みたい こともよくあります。

note: Tag: para
en: There are several commands that can provide you with historical data from the repository:
ja: リポジトリからの履歴データをあつかうためのコマンドがいくつか あります:

note: Tag: para
en: Shows you broad information: log messages with date and author information attached to revisions, and which paths changed in each revision.
ja: 全般的な情報を表示します: リビジョンに付随した日付、修正者つきの ログメッセージとそれぞれのリビジョンでどのパスが変更されたかを表示します。

note: Tag: para
en: Shows line-level details of a particular change.
ja: 特定の変更の詳細を行単位で表示する

note: Tag: para
en: Retrieves a file as it existed in a particular revision number and display it on your screen.
ja: 特定のリビジョン番号時点でのファイルを抽出し 画面に表示します。

note: Tag: para
en: Displays the files in a directory for any given revision.
ja: 任意の指定したリビジョンのファイルやディレクトリを一覧 表示します。

note: Tag: title
en: Generating a list of historical changes
ja: 変更履歴のリストを生成

note: Tag: para
en: To find information about the history of a file or directory, use the <command>svn log</command> command. <command>svn log</command> will provide you with a record of who made changes to a file or directory, at what revision it changed, the time and date of that revision, and, if it was provided, the log message that accompanied the commit.
ja: ファイルやディレクトリの履歴に関する情報を見たいときは <command>svn log</command>コマンドを使ってください。 <command>svn log</command> は、あるファイルやディレクトリを 誰が変更したかの記録を表示し、どのリビジョンでそれが変更され たか、そのリビジョンの時刻と日付、さらにもし存在すれば、 コミットに付随したログメッセージを表示します。

note: Tag: screen
en: $ svn log
    ------------------------------------------------------------------------
    r3 | sally | Mon, 15 Jul 2002 18:03:46 -0500 | 1 line
    
    Added include lines and corrected # of cheese slices.
    ------------------------------------------------------------------------
    r2 | harry | Mon, 15 Jul 2002 17:47:57 -0500 | 1 line
    
    Added main() methods.
    ------------------------------------------------------------------------
    r1 | sally | Mon, 15 Jul 2002 17:40:08 -0500 | 1 line
    
    Initial import
    ------------------------------------------------------------------------
ja: $ svn log
    ------------------------------------------------------------------------
    r3 | sally | Mon, 15 Jul 2002 18:03:46 -0500 | 1 line
    
    Added include lines and corrected # of cheese slices.
    ------------------------------------------------------------------------
    r2 | harry | Mon, 15 Jul 2002 17:47:57 -0500 | 1 line
    
    Added main() methods.
    ------------------------------------------------------------------------
    r1 | sally | Mon, 15 Jul 2002 17:40:08 -0500 | 1 lines
    
    Initial import
    ------------------------------------------------------------------------

note: Tag: para
en: Note that the log messages are printed in <emphasis>reverse chronological order</emphasis> by default. If you wish to see a different range of revisions in a particular order, or just a single revision, pass the <option>--revision (-r)</option> option:
ja: ログメッセージはデフォルトでは <emphasis>時間と逆の順序で</emphasis> 表示されることに注意して ください。別の順序で、あるリビジョン範囲を見たい場合や、一つの リビジョンを見たいときには、<option>--revision</option> (<option>-r</option>)スイッチを渡します:

note: Tag: para
en: You can also examine the log history of a single file or directory. For example:
ja: 一つのファイルやディレクトリのログ履歴を見ることもできます。 たとえば:

note: Tag: para
en: These will display log messages <emphasis>only</emphasis> for those revisions in which the working file (or URL) changed.
ja: これは作業ファイルが(またはURLが)変更されたリビジョン <emphasis>だけを</emphasis>表示します。

note: Tag: para
en: If you want even more information about a file or directory, <command>svn log</command> also takes a <option>--verbose (-v)</option> option. Because Subversion allows you to move and copy files and directories, it is important to be able to track path changes in the filesystem, so in verbose mode, <command>svn log</command> will include a list of changed paths in a revision in its output:
ja: もしファイルやディレクトリについてもっと詳細な情報がほしいときには、<command>svn log</command> は <option>--verbose</option> (<option>-v</option>) スイッチを とることもできます。Subversionはファイルやディレクトリの 移動やコピーもできるので、ファイルシステム中のパスの 変化を追えることは重要です。冗長モードでは、 <command>svn log</command> は出力リビジョンの中に 変更されたパス情報の一覧も含めます:

note: Tag: para
en: <command>svn log</command> also takes a <option>--quiet</option> (<option>-q</option>) option, which suppresses the body of the log message. When combined with <option>--verbose</option>, it gives just the names of the changed files.
ja: <command>svn log</command> は <option>--quiet</option> (<option>-q</option>) スイッチも指定でき、これはログメッセージの本文を 表示しません。<option>--verbose</option>と組み合わせて指定すると 変更したファイルの名前だけを表示します。

note: Tag: title
en: Why Does <command>svn log</command> Give Me an Empty Response?
ja: なぜ、<command>svn log</command> の出力が何も ないの?

note: Tag: para
en: After working with Subversion for a bit, most users will come across something like this:
ja: Subversionを使い始めてすぐのとき、たいていのユーザは 以下のようなことに出くわすでしょう:

note: Tag: para
en: At first glance, this seems like an error. But recall that while revisions are repository-wide, <command>svn log</command> operates on a path in the repository. If you supply no path, Subversion uses the current working directory as the default target. As a result, if you're operating in a subdirectory of your working copy and attempt to see the log of a revision in which neither that directory nor any of its children was changed, Subversion will show you an empty log. If you want to see what changed in that revision, try pointing <command>svn log</command> directly at the top-most URL of your repository, as in <command>svn log -r 2 http://svn.collab.net/repos/svn</command>.
ja: 一見エラーのように見えますが、リビジョンがリポジトリ全体に対する ものであるのに対して<command>svn log</command>はリポジトリ中のパスに対して 働くものであるのに注意してください。パスを指定しなければ Subversion は デフォルトの対象として現在の作業ディレクトリを使います。結果として 自分の作業コピーのサブディレクトリで実行し、そのディレクトリにもその 子供のディレクトリ中でも変更がなかったリビジョンに対してのログを見ようと すると、Subversion は空のログを表示するでしょう。そのリビジョンでの変更点 を見たいのならリポジトリの最上位の URL を直接指定して<command>svn log</command> を実行しましょう。こんな感じです。<command>svn log -r 2 http://svn.collab.net/repos/svn</command>。

note: Tag: para
en: We've already seen <command>svn diff</command> before&mdash;it displays file differences in unified diff format; it was used to show the local modifications made to our working copy before committing to the repository.
ja: <command>svn diff</command>は既に見てきました&mdash; unified diff形式でファイルの差分を表示するのでした。 リポジトリにコミットする前に作業コピーにされたローカル 修正点を表示するのに使えます。

note: Tag: para
en: In fact, it turns out that there are <emphasis>three</emphasis> distinct uses of <command>svn diff</command>:
ja: 実際には<command>svn diff</command>には異なる <emphasis>三種類</emphasis> の使い方があります:

note: Tag: para
en: Examining local changes
ja: ローカルの変更内容の確認

note: Tag: para
en: Comparing your working copy to the repository
ja: 作業コピーとリポジトリの比較

note: Tag: para
en: Comparing repository to repository
ja: リポジトリとリポジトリの比較

note: Tag: title
en: Examining Local Changes
ja: ローカルの変更内容の確認

note: Tag: title
en: Comparing Working Copy to Repository
ja: 作業コピーとリポジトリの比較

note: Tag: para
en: If a single <option>--revision</option> (<option>-r</option>) number is passed, then your working copy is compared to the specified revision in the repository.
ja: <option>--revision</option>(<option>-r</option>) を一つ 指定すると、作業コピーはリポジトリの特定のリビジョンと比較 されます。

note: Tag: title
en: Comparing Repository to Repository
ja: リポジトリとリポジトリの比較

note: Tag: para
en: If you want to examine an earlier version of a file and not necessarily the differences between two files, you can use <command>svn cat</command>:
ja: もし、以前のバージョンのファイルを見たいが、二つのファイル間の違い を見る必要はないような場合には、 <command>svn cat</command>が使えます:

note: Tag: para
en: You can also redirect the output directly into a file:
ja: 直接ファイルに出力することもできます:

note: Tag: para
en: The <command>svn list</command> command shows you what files are in a repository directory without actually downloading the files to your local machine:
ja: <command>svn list</command> コマンドはローカルマシンに 実際にファイルをダウンロードすることなしに、リポジトリ にどんなディレクトリがあるかを表示します:

note: Tag: para
en: The columns tell you the revision at which the file or directory was last modified, the user who modified it, the size if it is a file, the date it was last modified, and the item's name.
ja: それぞれの項目の意味は、左から順に、ファイルまたはディレクトリが最後に 更新されたリビジョン、修正した人、ファイルであればそのサイズ、日付、そして そのアイテムの名前になります。

note: Tag: para
en: And this is exactly what <command>svn cleanup</command> does: it searches your working copy and runs any leftover logs, removing working copy locks in the process. If Subversion ever tells you that some part of your working copy is <quote>locked</quote>, then this is the command that you should run. Also, <command>svn status</command> will display an <literal>L</literal> next to locked items:
ja: <command>svn cleanup</command>がやるのは、まさにこのことです。 作業コピーを探して、残ったログを実行し、プロセスのロックを 取り除きます。Subversionに作業コピーのどこかが<quote>ロック</quote> されていると言われたときには、このコマンドを実行してください。 同様に<command>svn status</command> はロックされているアイテム の隣に <literal>L</literal> を表示してそのことを示します:

note: Tag: para
en: Now we've covered most of the Subversion client commands. Notable exceptions are those dealing with branching and merging (see <xref linkend="svn.branchmerge"/>) and properties (see <xref linkend="svn.advanced.props"/>). However, you may want to take a moment to skim through <xref linkend="svn.ref"/> to get an idea of all the many different commands that Subversion has&mdash;and how you can use them to make your work easier.
ja: これで、Subversionクライアントのコマンドの大部分について 説明しました。触れなかったもののうちで重要なのはブランチと マージ (<xref linkend="svn.branchmerge"/>参照) 、そして属性です (<xref linkend="svn.advanced.props"/>参照)。 Subversionが持っているたくさんのコマンドの感じをつかむには <xref linkend="svn.ref"/> をざっと見るのもいいかも知れません &mdash;自分の仕事がどれだけ楽になるか、わかるでしょう。

note: Tag: title
en: Advanced Topics
ja: より進んだ話題

note: Tag: title
en: Revision Keywords
ja: リビジョンキーワード

note: Tag: para
en: The latest (or <quote>youngest</quote>) revision in the repository.
ja: リポジトリにある最新のリビジョンです。

note: Tag: para
en: The revision number of an item in a working copy. If the item has been locally modified, the <quote>BASE version</quote> refers to the way the item appears without those local modifications.
ja: 作業コピーにあるファイル、ディレクトリの、<quote>修正元</quote>リビジョン です。

note: Tag: para
en: The most recent revision prior to, or equal to, <literal>BASE</literal>, in which an item changed.
ja: ファイル、ディレクトリが変更された<literal>BASE</literal>以前の(または <literal>BASE</literal>リビジョンを含む)最後のリビジョンです。

note: Tag: title
en: Revision Dates
ja: リビジョン日付

note: Tag: secondary
en: specified as dates
ja: 日付で指定する

note: Tag: title
en: Is Subversion a Day Early?
ja: Subversion の日付は早くないですか?

note: Tag: para
en: You can also use a range of dates. Subversion will find all revisions between both dates, inclusive:
ja: 日付範囲を使うこともできます。 Subversionは両方の日付の間にあるすべてのリビジョンを検索対象と します。両端の日付は検索に含みます:

note: Tag: title
en: Properties
ja: 属性

note: Tag: para
en: Subversion has reserved the set of properties whose names begin with <literal>svn:</literal> as its own. While there are only a handful of such properties in use today, you should avoid creating custom properties for your own needs whose names begin with this prefix. Otherwise, you run the risk that a future release of Subversion will grow support for a feature or behavior driven by a property of the same name but with perhaps an entirely different interpretation.
ja: Subversion は、<literal>svn:</literal> で始まる名前の属性を自分自身で利用するために予約しています。現在利用されている予約属性はほんの一握りですが、あなた自身のために、このプレフィクスで始まるカスタム属性を作成するのはさけたほうがいいです。さもなければ将来のバージョンで新機能のサポートのために Subversion が同じ名前の属性を全く異なって意味で使用するようになるかもしれないというリスクを負ってしまいます。

note: Tag: title
en: Why Properties?
ja: なぜ属性なんてものが?

note: Tag: title
en: Manipulating Properties
ja: 属性の操作

note: Tag: para
en: There are some restrictions on the names you can use for properties. A property name must start with a letter, a colon (<literal>:</literal>), or an underscore (<literal>_</literal>); after that, you can also use digits, hyphens (<literal>-</literal>), and periods (<literal>.</literal>).
ja: 属性で利用できる名前にはいくつかの制限があります。属性の名前は 文字、コロン(<literal>:</literal>) あるいはアンダースコア(<literal>_</literal>) で始まり、その後では数字、ハイフン(<literal>-</literal>)、ピリオド(<literal>.</literal>) も使えます。

note: Tag: para
en: If you're familiar with XML, this is pretty much the ASCII subset of the syntax for XML "Name".
ja: XML に詳しいのであれば、これは XML "名称" の ASCII サブセットな構文 に近いものです。

note: Tag: para
en: We should note that, as with other <command>svn</command> subcommands, those related to properties can act on multiple paths at once. This enables you to modify properties on whole sets of files with a single command. For example, we could have done:
ja: 他の<command>svn</command>コマンドと同様に、属性に関するこれらの コマンドも複数パスに対して一度に実行することができます。これは 一つのコマンドで複数のファイル上の属性を修正することを可能にします。 たとえば、以下のようなことができます:

note: Tag: para
en: There's even a variation of the <command>proplist</command> command that will list both the name and value of all of the properties. Simply supply the <option>--verbose</option> (<option>-v</option>) option.
ja: <command>proplist</command> コマンドの変種として、すべての属性の 名前と値の両方をリストするものがあります。これには単に、 <option>--verbose</option>(<option>-v</option>) オプションを指定すればOKです。

note: Tag: para
en: The last property-related subcommand is <command>propdel</command>. Since Subversion allows you to store properties with empty values, you can't remove a property altogether using <command>propedit</command> or <command>propset</command>. For example, this command will <emphasis>not</emphasis> yield the desired effect:
ja: 最後の属性関連サブコマンドは <command>propdel</command>です。Subversionは空の値を持つ属性を 格納することを許すので、<command>propedit</command> や <command>propset</command>を使うだけでは、属性を削除することが できません。たとえばこのコマンドは期待される結果には<emphasis>なりません</emphasis> :

note: Tag: title
en: Automatic Property Setting
ja: 属性の自動設定

note: Tag: title
en: Identifying File Types
ja: ファイルタイプを指定する

note: Tag: para
en: Various programs on most modern operating systems make assumptions about the type and format of the contents of a file by the file's name, specifically its file extension. For example, files whose names end in <filename>.txt</filename> are generally assumed to be human-readable, able to be understood by simple perusal rather than requiring complex processing to decipher. Files whose names end in <filename>.png</filename>, on the other hand, are assumed to be of the Portable Network Graphics type&mdash;not human-readable at all, and sensible only when interpreted by software which understands the PNG format and can render the information in that format as a raster image.
ja: ほとんどの近代的なオペレーティングシステムで動作する多くのプログラムではファイル名、特にファイル拡張子に基づいてファイルタイプやファイルフォーマットに関して仮定します。例えば、<filename>.txt</filename> で終わるファイル名のファイルは、一般に人が読める形式であって、解読のために複雑な処理を必要とせずに理解できると想定できます。一方<filename>.png</filename> で終わるファイル名のファイルは、Portable Network Graphics のデータであると想定されます。type&mdash; そして人は全く理解できません。ソフトウェアで解釈されて始めてそれが PNG フォーマットであるとわかります。そして、ラスタ画像としてその情報をレンダリングすることができます。

note: Tag: para
en: This property has no effect on filesystems that have no concept of an executable permission bit, such as FAT32 and NTFS. <footnote> <para>The Windows filesystems use file extensions (such as <literal>.EXE</literal>, <literal>.BAT</literal>, and <literal>.COM</literal>) to denote executable files.</para> </footnote> Also, although it has no defined values, Subversion will force its value to <literal>*</literal> when setting this property. Finally, this property is valid only on files, not on directories.
ja: この属性はFAT32やNTFSのように実行権限ビットの概念を持たないファイルシステム 上では何の効果もありません。 <footnote> <para> Windowsのファイルシステムはファイル拡張を使ってそれが実行ファイルである ことを示します。(<literal>.EXE</literal>, <literal>.BAT</literal>, <literal>.COM</literal>のような拡張子です) </para> </footnote> また、それは定義された値を持ちませんが、Subversionはこの属性が設定される と、強制的にその値を<literal>*</literal>とします。最後に、この属性は ファイルに対してのみ有効で、ディレクトリに対しては意味を持ちません。

note: Tag: para
en: Unless otherwise noted using a versioned file's <literal>svn:mime-type</literal> property, Subversion assumes the file contains human-readable data. Generally speaking, Subversion only uses this knowledge to determine if contextual difference reports for that file are possible. Otherwise, to Subversion, bytes are bytes.
ja: バージョンファイルの<literal>svn:mime-type</literal> 属性で 指定するのでなければ、Subversionはファイルは可読なデータが含まれている と仮定します。一般的に、Subversionはそのファイルに対する文脈差分を 報告することができるかどうかを決めるためにだけ利用します。そうで なければ、Subversionにとって、バイトはただのバイトでしかありません。

note: Tag: para
en: But in practice, many common tools either fail to properly read a file with foreign EOL markers, or they convert the file's line endings to the native style when the file is saved. If the former is true for a developer, he has to use an external conversion utility (such as <command>dos2unix</command> or its companion, <command>unix2dos</command>) to prepare the file for editing. The latter case requires no extra preparation. But both cases result in a file that differs from the original quite literally on every line! Prior to committing his changes, the user has two choices. Either he can use a conversion utility to restore the modified file to the same line ending style that it was in before his edits were made. Or, he can simply commit the file&mdash;new EOL markers and all.
ja: しかし、実際には、たくさんのありふれたツールは別のEOLマーカのファイル を正しく読むことができないか、ファイルが保存されるときに、行末を そのオペレーティングシステム固有のものに変換してしまうかします。 もし開発者に最初のことが起こると、彼は外部の変換ユーティリティー (<command>dos2unix</command> や、それとペアになった <command>unix2dos</command>)を使ってファイル編集の前処理をしなくては なりません。あとの場合には何も特別の用意はいりません。しかし どちらの場合でも、すべての行が、最初のものと違ってしまいます。 変更をコミットする前に、ユーザには二通りの選択があります。 編集する前の行末スタイルと同じスタイルになるように変換ユーティリティー を使って修正したファイルを保存するか、単にそのファイルをコミットするか です&mdash;この場合、行末は新しいEOLマーカがつきます。

note: Tag: para
en: The result of scenarios like these include wasted time and unnecessary modifications to committed files. Wasted time is painful enough. But when commits change every line in a file, this complicates the job of determining which of those lines were changed in a non-trivial way. Where was that bug really fixed? On what line was a syntax error introduced?
ja: このようなシナリオの結果は時間の無駄と、コミットされたファイルに対する 不必要な修正になります。時間の無駄はそれだけで十分な苦痛です。しかし、 コミットがファイルのすべての行を変更するなら、これは、本当に修正された のはどの行なのかを決定する作業を非常に複雑なものにします。バグの修正は いったいどの行でなされたのか? どの行で構文エラーがあったのか?

note: Tag: para
en: The solution to this problem is the <literal>svn:eol-style</literal> property. When this property is set to a valid value, Subversion uses it to determine what special processing to perform on the file so that the file's line ending style isn't flip-flopping with every commit that comes from a different operating system. The valid values are:
ja: この問題の解決は、<literal>svn:eol-style</literal> 属性です。 この属性が正しい値に設定されれば、Subversionはそれを使って、 どのような特殊な処理がファイルに必要であり、その処理をすれば ファイルの行末スタイルが、異なるオぺレーティングシステムからの コミットによって、ばたばた変化したりしないか、を決定します。 設定できる値は:

note: Tag: para
en: This causes the file to contain the EOL markers that are native to the operating system on which Subversion was run. In other words, if a user on a Windows machine checks out a working copy that contains a file with an <literal>svn:eol-style</literal> property set to <literal>native</literal>, that file will contain <literal>CRLF</literal> EOL markers. A Unix user checking out a working copy which contains the same file will see <literal>LF</literal> EOL markers in his copy of the file.
ja: これは、ファイルが、Subversionが実行されているオペレーティング システムの本来のEOLマーカを含むようにします。言い換えると もしWindows上のユーザが作業コピーをチェックアウトして、そこには <literal>svn:eol-style</literal> 属性が<literal>native</literal> に設定されたファイルがある場合、そのファイルは<literal>CRLF</literal> EOLマーカを含むということです。逆にUnix ユーザが作業コピーをチェック アウトし、そこに、その同じファイルがあった場合は、ファイルのコピー には<literal>LF</literal> EOLマーカが含まれることになります。

note: Tag: para
en: Note that Subversion will actually store the file in the repository using normalized <literal>LF</literal> EOL markers regardless of the operating system. This is basically transparent to the user, though.
ja: Subversionは実際にはリポジトリにファイルを格納するときには、 オペレーティングシステムにはよらず、正規化された<literal>LF</literal> EOLマーカを使います。これは基本的にユーザには意識しなくても良いように なっているわけですが。

note: Tag: para
en: This causes the file to contain <literal>CRLF</literal> sequences for EOL markers, regardless of the operating system in use.
ja: これは使っているオペレーティングシステムによらず、ファイルのEOLマーカ に<literal>CRLF</literal> の並びを使います。

note: Tag: para
en: This causes the file to contain <literal>LF</literal> characters for EOL markers, regardless of the operating system in use.
ja: これは使っているオペレーティングシステムによらず、ファイルのEOLマーカ に<literal>LF</literal> 文字を使います。

note: Tag: para
en: This causes the file to contain <literal>CR</literal> characters for EOL markers, regardless of the operating system in use. This line ending style is not very common. It was used on older Macintosh platforms (on which Subversion doesn't even run).
ja: これは使っているオペレーティングシステムによらず、ファイルのEOLマーカ に<literal>CR</literal> 文字を使います。 この行末スタイルはそれほど一般的ではありません。それは古いMacintosh プラットフォームで利用されていました。(その上ではSubversionは実行する ことさえできませんが)

note: Tag: title
en: Ignore Patterns for CVS Users
ja: CVSユーザにとっての無視パターン

note: Tag: para
en: The Subversion <literal>svn:ignore</literal> property is very similar in syntax and function to the CVS <filename>.cvsignore</filename> file. In fact, if you are migrating a CVS working copy to Subversion, you can directly migrate the ignore patterns by using the <filename>.cvsignore</filename> file as input file to the <command>svn propset</command> command:
ja: Subversionの<literal>svn:ignore</literal> 属性は CVS の <filename>.cvsignore</filename> ファイルに構文も機能も とてもよく似ています。実際、CVS作業コピーをSubversion に移行する場合、<filename>.cvsignore</filename> の 無視パターンを直接 <command>svn propset</command> コマンド の入力ファイルとすることができます:

note: Tag: para
en: There are, however, some differences in the ways that CVS and Subversion handle ignore patterns. The two systems use the ignore patterns at some different times, and there are slight discrepancies in what the ignore patterns apply to. Also, Subversion does not recognize the use of the <literal>!</literal> pattern as a reset back to having no ignore patterns at all.
ja: しかし、CVS とSubversionがパターンを無視する方法にはいくつかの 違いがあります。二つのシステムは無視パターンを別のタイミングで 利用し、無視パターンが適用される対象にわずかな相違点があります。 さらに、Subversionは無視パターンが何もない状態に戻すための <literal>!</literal> パターンは使うことができません。

note: Tag: para
en: After you've added this property, you will now have a local property modification on the <filename>calc</filename> directory. But notice what else is different about your <command>svn status</command> output:
ja: この属性を追加すると、<filename>calc</filename>ディレクトリ上に ローカルな属性変更を手に入れることができます。 しかし、<command>svn status</command> 出力について 何が変わったかに注意してください:

note: Tag: title
en: Keyword Substitution
ja: キーワード展開

note: Tag: para
en: All keywords are case-sensitive where they appear as anchors in files: you must use the correct capitalization in order for the keyword to be expanded. You should consider the value of the <literal>svn:keywords</literal> property to be case-sensitive too&mdash;certain keyword names will be recognized regardless of case, but this behavior is deprecated.
ja: すべてのキーワードは大文字小文字の区別がありファイル中での 目印になります: キーワードが展開されるように大文字小文字を正しく 使う必要があります。 <literal>svn:keywords</literal> 属性の値 についても大文字小文字の区別を考慮すべきです &mdash; ある種の キーワードは大文字小文字を区別せずに解釈されますがこの仕様は 過去のものです。

note: Tag: para
en: Subversion defines the list of keywords available for substitution. That list contains the following five keywords, some of which have aliases that you can also use:
ja: Subversion は、置換可能なキーワードのリストを定義しています。 そのリストは、以下の五つのキーワードで、そのいくつかについては 別名を使うこともできます:

note: Tag: para
en: This keyword describes the last known revision in which this file changed in the repository, and looks something like <literal>$Revision: 144 $</literal>. It may also be specified as <literal>LastChangedRevision</literal> or <literal>Rev</literal>.
ja: このキーワードは、ファイルがリポジトリで変更された最後のリビジョン をあらわし、<literal>$Revision: 144 $</literal>のようなものです。これは <literal>LastChangedRevision</literal>または <literal>Rev</literal>と省略することもできます。

note: Tag: para
en: This keyword describes the last known user to change this file in the repository, and looks something like <literal>$Author: harry $</literal>. It may also be specified as <literal>LastChangedBy</literal>.
ja: このキーワードはリポジトリ中のこのファイルを最後に変更したユーザ をあらわし、<literal>$Author: harry $</literal>のようなものです。これは <literal>LastChangedBy</literal>と省略することもできます。

note: Tag: para
en: This keyword describes the full URL to the latest version of the file in the repository, and looks something like <literal>$HeadURL: http://svn.collab.net/repos/trunk/README $</literal>. It may be abbreviated as <literal>URL</literal>.
ja: このキーワードはリポジトリ中のファイルの最後のバージョン に対する完全なURLをあらわし、 <literal>$HeadURL: http://svn.collab.net/repos/trunk/README $</literal> のようなものです。これは<literal>URL</literal>と省略する こともできます。

note: Tag: para
en: Simply adding keyword anchor text to your file does nothing special. Subversion will never attempt to perform textual substitutions on your file contents unless explicitly asked to do so. After all, you might be writing a document <footnote> <para>&hellip; or maybe even a section of a book &hellip;</para> </footnote> about how to use keywords, and you don't want Subversion to substitute your beautiful examples of un-substituted keyword anchors!
ja: キーワードアンカーテキストをファイルに付け加えただけでは何も 起きません。明示的に要求しなければ Subversion は 決してテキスト置換をやろうとはしません。ようは、 キーワードのそのものの使い方についてのドキュメントを <footnote> <para>&hellip; あるいは、その本の一節を&hellip;</para> </footnote> 書いているときに、そのすばらしい例自身がSubversionに よって置換されてほしくはないでしょう。

note: Tag: para
en: To tell Subversion whether or not to substitute keywords on a particular file, we again turn to the property-related subcommands. The <literal>svn:keywords</literal> property, when set on a versioned file, controls which keywords will be substituted on that file. The value is a space-delimited list of the keyword names or aliases found in the previous table.
ja: Subversionが特定のファイルの上でキーワードを置換するかどうかを設定 するために、属性関連のサブコマンドに戻ります。 <literal>svn:keywords</literal> 属性は、バージョンファイルに設定 された場合は、そのファイルのどのキーワードが置換されるかの制御を します。その値は、空白で区切られたキーワード名称か別名のリストで、 前に書いたテーブルの中にあるもののどれかになります。

note: Tag: para
en: For example, say you have a versioned file named <filename>weather.txt</filename> that looks like this:
ja: たとえば、<filename>weather.txt</filename> という名前の バージョン管理されているファイルがあり、以下のようだとします:

note: Tag: para
en: With no <literal>svn:keywords</literal> property set on that file, Subversion will do nothing special. Now, let's enable substitution of the <literal>LastChangedDate</literal> keyword.
ja: <literal>svn:keywords</literal> 属性がファイルに設定されていなければ Subversionは何も特別なことはしません。さて、 <literal>LastChangedDate</literal> キーワードの置換を有効にして みましょう。

note: Tag: para
en: Now you have made a local property modification on the <filename>weather.txt</filename> file. You will see no changes to the file's contents (unless you made some of your own prior to setting the property). Notice that the file contained a keyword anchor for the <literal>Rev</literal> keyword, yet we did not include that keyword in the property value we set. Subversion will happily ignore requests to substitute keywords that are not present in the file, and will not substitute keywords that are not present in the <literal>svn:keywords</literal> property value.
ja: これで、<filename>weather.txt</filename> のローカル属性を変更しま した。そのファイルの内容には何の変化もないでしょう(属性を設定 する前に変更していなければ)。ファイルはキーワードアンカー <literal>Rev</literal>キーワードを含んでいたとします。私たちはこの キーワードをまだ属性値として設定していません。Subversionはファイル に存在しないキーワードを置換する要求を無視しますし、 <literal>svn:keywords</literal> 属性値に存在しないキーワードを 置換することもありません。

note: Tag: para
en: Immediately after you commit this property change, Subversion will update your working file with the new substitute text. Instead of seeing your keyword anchor <literal>$LastChangedDate$</literal>, you'll see its substituted result. That result also contains the name of the keyword, and continues to be bounded by the dollar sign (<literal>$</literal>) characters. And as we predicted, the <literal>Rev</literal> keyword was not substituted because we didn't ask for it to be.
ja: この属性の変更をコミットした直後、Subversionは作業ファイルを、新しい 置換テキストで更新します。キーワードアンカー <literal>$LastChangedDate$</literal>を見るかわりに、置換結果を 見ることになるでしょう。この結果はキーワードの名前を含み、ドル記号 文字(<literal>$</literal>) でくくられています。そして述べたように、 <literal>Rev</literal> は設定していないので、置換されませんでした。

note: Tag: para
en: Note also that we set the <literal>svn:keywords</literal> property to <quote>Date Author</quote> yet the keyword anchor used the alias <literal>$LastChangedDate$</literal> and still expanded correctly.
ja: <literal>svn:keywords</literal> 属性を<quote>Date Author</quote> に設定してもキーワードの目印は<literal>$LastChangedDate$</literal> の別名を使うのでやはりうまく展開されます。

note: Tag: para
en: If someone else now commits a change to <filename>weather.txt</filename>, your copy of that file will continue to display the same substituted keyword value as before&mdash;until you update your working copy. At that time the keywords in your <filename>weather.txt</filename> file will be re-substituted with information that reflects the most recent known commit to that file.
ja: もし誰か別の人が<filename>weather.txt</filename>に変更点をコミット すれば、ファイルのコピーは前と同じ置換されたキーワード値を表示し続ける でしょう&mdash;作業コピーを更新するまでは。そのとき、 <filename>weather.txt</filename>ファイルのキーワードはそのファイルを コミットした一番最後の状態を反映する情報で置換されるでしょう。

note: Tag: title
en: Where's $GlobalRev$?
ja: $GlobalRev$ はどこ?

note: Tag: para
en: New users are often confused by how the <literal>$Rev$</literal> keyword works. Since the repository has a single, globally increasing revision number, many people assume that it is this number which is reflected by the <literal>$Rev$</literal> keyword's value. But <literal>$Rev$</literal> expands to show the last revision in which the file <emphasis>changed</emphasis>, not the last revision to which it was updated. Understanding this clears the confusion, but frustration often remains&mdash;without the support of a Subversion keyword to do so, how can you automatically get the global revision number into your files?
ja: 新しいユーザーはよく <literal>$Rev$</literal> キーワードがどのように動作するか混乱することがあります。リポジトリは単一で、全体的に増加するリビジョン番号をもっているので、多くのユーザーは、<literal>$Rev$</literal> がこのリビジョン番号だと想定してしまいます。しかし、 <literal>$Rev$</literal> はそのファイルが  <emphasis>変更された</emphasis> 最後のリビジョンを指すように展開されます。最後に更新されたリビジョンではありません。このことを理解すれば混乱は楷書売れさます。しかし、不満は残ります。この機能をサポートする Subversion キーワードなしで、自動的に自分のファイルにこのグローバルリビジョンを取得することができるでしょうか?

note: Tag: para
en: To do this, you need external processing. Subversion ships with a tool called <command>svnversion</command> which was designed for just this purpose. <command>svnversion</command> crawls your working copy and generates as output the revision(s) it finds. You can use this program, plus some additional tooling, to embed that revision information into your files. For more information on <command>svnversion</command>, see <xref linkend="svn.ref.svnversion"/>.
ja: これを実現するためには、外部プログラムによる処理を行う必要があります。Subversion は <command>svnversion</command> と呼ばれるツールを提供しています。このツールはこの目的のために設計されています。 <command>svnversion</command> は作業コピーを探索して、見つけたリビジョン番号を出力として生成します。このツールとリビジョン番号をファイルに埋め込むための追加ツールを使って行うことができます。 <command>svnversion</command> に関するさらなる情報は、 <xref linkend="svn.ref.svnversion"/> を参照してください。

note: Tag: title
en: Locking
ja: ロック

note: Tag: title
en: Creating locks
ja: ロックの作成

note: Tag: title
en: Regarding lock tokens
ja: ロック・トークンに関する注意

note: Tag: para
en: Now that Harry has locked <filename>banana.jpg</filename>, Sally is unable to change or delete that file:
ja: これで Harry は <filename>banana.jpg</filename> をロックし、Sally は そのファイルを修正したり削除したりできなくなりました:

note: Tag: para
en: But Harry, after touching up the banana's shade of yellow, is able to commit his changes to the file. That's because he authenticates as the lock owner, and also because his working copy holds the correct lock token:
ja: しかし Harry は banana の色合いをもう少し黄色くしたあと、その変更点を コミットすることができます。理由はロック所有者としての認可を受けている からであり、彼の作業コピーにはそのための正しいロック・トークンがあるためです:

note: Tag: para
en: Of course, locking a file doesn't oblige one to commit a change to it. The lock can be released at any time with a simple <command>svn unlock</command> command:
ja: もちろんファイルをロックした後、修正を必ずコミットしなくてはならない という義務はありません。ロックは単に<command>svn unlock</command> コマンドを利用していつでも解除することもできます:

note: Tag: title
en: Discovering locks
ja: ロック状況の調査

note: Tag: para
en: When a commit fails due to someone else's locks, it's fairly easy to learn about them. The easiest of these is <command>svn status --show-updates</command>:
ja: 誰かがロックしているせいでコミットに失敗した時には、原因は割と簡単に 調べることができます。一番簡単な方法は <command>svn status --show-updates</command> を実行することです:

note: Tag: para
en: In this example, Sally can see not only that her copy of <filename>foo.h</filename> is out-of-date, but that one of the two modified files she plans to commit is locked in the repository. The <literal>O</literal> symbol stands for <quote>Other</quote>, meaning that a lock exists on the file, and was created by somebody else. If she were to attempt a commit, the lock on <filename>raisin.jpg</filename> would prevent it. Sally is left wondering who made the lock, when, and why. Once again, <command>svn info</command> has the answers:
ja: この例では Sally は自分の作業コピーの <filename>foo.h</filename> が古いだけでなくコミットしようと思っている二つの修正したファイルの 片方はリポジトリ中でロックされていることもわかります。 <literal>O</literal>の記号は <quote>Other(他の)</quote> の意味で ロックがファイル上に存在していてそれをしたのは誰か別の人である という意味になります。彼女がコミットしようとしても<filename>raisin.jpg</filename> 上のロックが邪魔をするでしょう。Sally はさらにロックしたのは誰で、いつ、 どうしてロックしたのかも知りたいとします。今度は <command>svn info</command> が答えを教えてくれます:

note: Tag: para
en: So in this particular example, Sally can see that Harry locked the file on February 16th to <quote>make a quick tweak</quote>. It being June, she suspects that he probably forgot all about the lock. She might phone Harry to complain and ask him to release the lock. If he's unavailable, she might try to forcibly break the lock herself or ask an administrator to do so.
ja: それで今回の具体的な例の場合、Sally は Hally が<quote>ちょっとした 修正</quote>のために 2 月 16 日にそのファイルをロックしたことが わかります。今は 6 月であるので、Sally は多分 Hally は自分がロックしたことを 忘れてしまっているのではないかと考えます。彼女は Harry に電話してロック をはずしてくれるように頼むかも知れません。彼がつかまらなければ彼女は 自分で強制的にロックを解除するか、システム管理者にそうしてもらうように頼む かも知れません。

note: Tag: title
en: Breaking and stealing locks
ja: ロックの解除と横取り(steal)

note: Tag: para
en: From the administrator's chair, it's simple to break locks. The <command>svnlook</command> and <command>svnadmin</command> programs have the ability to display and remove locks directly from the repository. (For more information about these tools, see <xref linkend="svn.reposadmin.maint.tk"/>.)
ja: 管理者にとってはロックを解除するのは簡単です。<command>svnlook</command> と <command>svnadmin</command> プログラムはリポジトリに対して直接 ロック状況を表示したり解除することができます。(これらのツールに関しての より詳しい情報は <xref linkend="svn.reposadmin.maint.tk"/>を見てください。)

note: Tag: para
en: If the repository lock was broken, then <command>svn status --show-updates</command> displays a <literal>B</literal> (Broken) symbol next to the file. If a new lock exists in place of the old one, then a <literal>T</literal> (sTolen) symbol is shown. Finally, <command>svn update</command> notices any defunct lock tokens and removes them from the working copy.
ja: リポジトリロックが解除された場合、 <command>svn status --show-updates</command>はファイルの隣に <literal>B</literal> (Broken の意味)の記号を表示します。 古いトークンに変わって新たしいロックが存在している場合だと <literal>T</literal> (sTolen)の記号を表示します。 また <command>svn update</command> は無効になったすべての ロック・トークンを表示し、作業コピーから取り除きます。

note: Tag: title
en: Locking Policies
ja: ロックのポリシー

note: Tag: title
en: Lock Communication
ja: ロックのコミュニケーション

note: Tag: para
en: We've seen how <command>svn lock</command> and <command>svn unlock</command> can be used to create, release, break, and steal locks. This satisfies the goal of serializing commit access to a file. But what about the larger problem of preventing wasted time?
ja: <command>svn lock</command>と<command>svn unlock</command> がどうやってロックを作ったり解放したり強制解除したり横取りしたりするか を見てきました。これは特定のファイルに対する直列化したコミットをしたい という目標を満足するものです。しかし、作業時間を無駄にしないという、 より大きな問題についてはどうなのでしょうか?

note: Tag: para
en: For example, suppose Harry locks an image file and then begins editing it. Meanwhile, miles away, Sally wants to do the same thing. She doesn't think to run <command>svn status --show-updates</command>, so she has no idea that Harry has already locked the file. She spends hours editing the file, and when she tries to commit her change, she discovers that either the file is locked or that she's out-of-date. Regardless, her changes aren't mergeable with Harry's. One of these two people has to throw away their work, and a lot of time has been wasted.
ja: たとえば Harry がある画像ファイルをロックしてから編集し始めたとしましょう。 いっぽう、かなり離れた場所にいる Sally も同じことがしたかったとします。 彼女は <command>svn status --show-updates</command>を実行することを知らないので Harry が 既にそのファイルをロックしていることを知ることができません。彼女は そのファイルを何時間かかけて編集し、その自分の修正点をコミットしようとして はじめてそのファイルはロックされているか、彼女のファイルが最新ではない ことに気づきます。どうであれ、彼女の変更は Harry のものとマージすることが できません。二人のうちのどちらかが自分の作業を捨てなければならず 多くの時間が無駄になります。

note: Tag: para
en: Note that this property is a communication tool which works independently from the locking system. In other words, any file can be locked, whether or not this property is present. And conversely, the presence of this property doesn't make the repository require a lock when committing.
ja: この属性はロックシステムとは独立して機能するコミュニケーション用の 仕組みであることに注意してください。言いかえるとどのようなファイル も、このプロパティーがあるかどうかにかかわらずロックすることが できます。逆にこの属性の存在だけで、コミット時にリポジトリから常に ロックを要求されるということにはなりません。

note: Tag: title
en: Externals Definitions
ja: 外部定義

note: Tag: para
en: If you need to change the externals definition, you can do so using the regular property modification subcommands. When you commit a change to the <literal>svn:externals</literal> property, Subversion will synchronize the checked-out items against the changed externals definition when you next run <command>svn update</command>. The same thing will happen when others update their working copies and receive your changes to the externals definition.
ja: もし、外部定義を変更する必要がある場合、通常の属性変更 サブコマンドを使ってやることができます。 <literal>svn:externals</literal>属性への変更をコミットするとき、 Subversionは次の<command>svn update</command>を実行するときの 変更された外部定義に対してチェックアウトするアイテムを同期します。 同じことが、他の人が作業コピーを更新し、あなたが変更した外部定義 を受け取るときにも起こります。

note: Tag: para
en: The <command>svn status</command> command also recognizes externals definitions, displaying a status code of <literal>X</literal> for the disjoint subdirectories into which externals are checked out, and then recursing into those subdirectories to display the status of the external items themselves.
ja: <command>svn status</command> コマンドも外部定義がチェックアウトされた サブディレクトリごとに<literal>X</literal>の状態コードを表示する形で 外部定義を認識し、外部アイテムそれ自身の状態を表示するためにそれらの サブディレクトリに再帰的に降りていきます。

note: Tag: title
en: Peg and Operative Revisions
ja: ペグ・リビジョンと操作対象リビジョン

note: Tag: para
en: It's a nice story, really, but it doesn't end there. Entrepreneur that you are, you've already got another think in the tank. So you make a new directory, <filename>concept</filename>, and the cycle begins again. In fact, the cycle begins again many times over the years, each time starting with that old <filename>concept</filename> directory, then sometimes seeing that directory renamed as the idea cures, sometimes seeing it deleted when you scrap the idea. Or, to get really sick, maybe you rename <filename>concept</filename> to something else for a while, but later rename the thing back to <filename>concept</filename> for some reason.
ja: いい話しです。まったく。しかしこれで話しが終わるわけではありません。あ なたは企業家です。すでに次の着想を得ています。あなたは新しいディレクト リ<filename>concept</filename> を作り、次の開発サイクルが始まります。 実際にはこのサイクルは何年にもわたって何度も繰り返し発生します。いつも <filename>concept</filename>ディレクトリから始め、時にはそのアイディア を膨らませるためにディレクトリの名称は変更され、時にはそのアイディアを ボツにするためにディレクトリは削除されます。あるいは、さらにややこしい 場合、いったん <filename>concept</filename> を別の名前に変えた後、何か 理由があって再び<filename>concept</filename> に名前を戻したりすること もあるでしょう。

note: Tag: para
en: But what of the <option>--revision (-r)</option> of which we've spoken so much in this book? That revision (or set of revisions) is called the <firstterm>operative revision</firstterm> (or <firstterm>operative revision range</firstterm>). Once a particular line of history has been identified using a path and peg revision, Subversion performs the requested operation using the operative revision(s). To map this to our Chicagoland streets analogy, if we are told to go to 606 N. Main Street in Wheaton, <footnote> <para>606 N. Main Street, Wheaton, Illinois, is the home of the Wheaton History Center. Get it&mdash;<quote>History Center</quote>? It seemed appropriate&hellip;.</para> </footnote> we can think of <quote>Main Street</quote> as our path and <quote>Wheaton</quote> as our peg revision. These two pieces of information identify a unique path which can travelled (north or south on Main Street), and will keep us from travelling up and down the wrong Main Street in search of our destination. Now we throw in <quote>606 N.</quote> as our operative revision, of sorts, and we know <emphasis>exactly</emphasis> where to go.
ja: ではこの本の中でいつも出てくる <option>--revision (-r)</option>で指定 されるほうのリビジョンは何と言われるのでしょうか ? こちらは<firstterm> 操作対象リビジョン</firstterm>(あるいはリビジョンの範囲を指定する場合 には、<firstterm>操作対象リビジョン範囲</firstterm>) と呼ばれます。いっ たん特定の履歴ラインがパス名とペグ・リビジョンによって指定されると Subversion は操作対象リビジョンに対して要求された操作を実行します。 この話をシカゴの道順のたとえで説明すると、 606 N. Main Street in Wheaton に行きたい場合だと <footnote> <para>606 N. Main Street, Wheaton, Illinois, は Wheaton 歴史センターのある場所です。 たずねてみてください&mdash;<quote>歴史センター</quote>だって? 確かに&hellip;.</para> </footnote> <quote>Main Street</quote>がパス名に、<quote>Wheaton</quote>がペグリビ ジョンにあたるものと考えることができます。この二つの情報によって実際に 行ってほしい道順(メインストリートの北、あるいは南)を特定することができ、 行き先を探すのに、間違った別のメインストリートを右往左往せずにすみます。 そして、操作対象リビジョンにあたる <quote>606 N.</quote> によって実際 に行きたい場所を<emphasis>正確に</emphasis>知ることができるというわけ です。

note: Tag: para
en: Say that long ago we created our repository, and in revision 1 added our first <filename>concept</filename> directory, plus an <filename>IDEA</filename> file in that directory talking about the concept. After several revisions in which real code was added and tweaked, we, in revision 20, renamed this directory to <filename>frabnaggilywort</filename>. By revision 27, we had a new concept, a new <filename>concept</filename> directory to hold it, and a new <filename>IDEA</filename> file to describe it. And then five years and twenty thousand revisions flew by, just like they would in any good romance story.
ja: ずっと以前に作っておいたリポジトリがあって、リビジョン 1 で最初の <filename>concept</filename>ディレクトリとその中にある <filename>IDEA</filename>という名前のファイルを追加したとしましょう。 このファイルは実際のコンセプトについての説明が書いてあります。 実際のソースコードを追加したり修正したりしてたくさんのリビジョンが 追加されたあと、リビジョン 20 でこのディレクトリを <filename>frabnaggilywort</filename>に名称変更したとしましょう。 リビジョン 27 で新しい着想を得たので、新規に<filename>concept</filename> ディレクトリを作り、またその中に新規に <filename>IDEA</filename> ファイルを置いて、その内容を書いておきます。そして良くできたロマンス 小説よろしくその後 5 年間で 20,000 リビジョンにまで達したと しましょう。

note: Tag: para
en: Of course, in this example, the current <filename>IDEA</filename> file didn't exist yet in revision 1, so Subversion gives an error. The command above is shorthand for a longer notation which explicitly lists a peg revision. The expanded notation is:
ja: この例ではもちろん、現在の <filename>IDEA</filename>ファイルは リビジョン 1 では存在しなかったので Subversion はエラーを出します。 上のコマンドはペグ・リビジョンを明示的に指定する、より長い形の形式 の略記法です。長い形式は以下のようになります:

note: Tag: para
en: Let's ask the other question, then&mdash;in revision 1, what were the contents of whatever file occupied the address <filename>concepts/IDEA</filename> at the time? We'll use an explicit peg revision to help us out.
ja: 今度はもう一方の質問をしてみましょう。つまり &mdash;リビジョン 1 の時点で、とにかく <filename>concepts/IDEA</filename>という名前で 存在していたファイルの内容はどんなものでしたか? これを指定する ために明示的なペグ・リビジョンを使います。

note: Tag: para
en: And the peg and operative revisions need not be so trivial, either. For example, say <filename>frabnaggilywort</filename> had been deleted from <literal>HEAD</literal>, but we know it existed in revision 20, and we want to see the diffs for its <filename>IDEA</filename> file between revisions 4 and 10. We can use the peg revision 20 in conjunction with the URL that would have held Frabnaggilywort's <filename>IDEA</filename> file in revision 20, and then use 4 and 10 as our operative revision range.
ja: そして、ペグ・リビジョンも操作対象リビジョンも、時には非常に重要な意味 を持ちます。例えば、 <filename>frabnaggilywort</filename>がリビジョン 20 で <literal>HEAD</literal> から削除されているが、リビジョン 20 では 存在していたことを知っていて、その時の <filename>IDEA</filename> ファイルが、リビジョン 4 と リビジョン 10 の間でどのように変化したか を見たいとします。これには、ペグ・リビジョン 20 を、そのリビジョンで Frabnaggilywort の <filename>IDEA</filename>ファイルを保持していた URL の後につけて指定します。また同時に操作対象リビジョン範囲として 4 と 10 を指定します。

note: Tag: para
en: Fortunately, most folks aren't faced with such complex situations. But when you are, remember that peg revisions are that extra hint Subversion needs to clear up ambiguity.
ja: ありがたいことにほとんどのユーザはこんな複雑な状況に出会うことはありま せん。しかし万一そんなことになった場合には、Subversion がファイル名の あいまいさを解消するにはペグ・リビジョンを追加で指定してやれば良いこと は覚えておいてください。

note: Tag: title
en: Network Model
ja: ネットワークモデル

note: Tag: title
en: Requests and Responses
ja: 要求と応答

note: Tag: title
en: Client Credentials Caching
ja: クライアント証明のキャッシュ

note: Tag: para
en: To disable caching for a single command, pass the <option>--no-auth-cache</option> option:
ja: 単一のコマンド中でキャッシュ を無効にする場合は <option>--no-auth-cache</option>オプションを渡して ください:

note: Tag: para
en: Sometimes users will want to remove specific credentials from the disk cache. To do this, you need to navigate into the <filename>auth/</filename> area and manually delete the appropriate cache file. Credentials are cached in individual files; if you look inside each file, you will see keys and values. The <literal>svn:realmstring</literal> key describes the particular server realm that the file is associated with:
ja: ときどき特定の証明をディスクキャッシュから削除したくなることがあります。 これには<filename>auth/</filename>領域を調べて適当なキャッシュファイルを 手で削除してください。証明は個別のファイルにキャッシュされています; それぞれ のファイルの中にはキーとその値があります。 <literal>svn:realmstring</literal> キーはファイルが関係している特定のサーバの認証範囲を記録しています:

note: Tag: para
en: Once you have located the proper cache file, just delete it.
ja: 適切なキャッシュファイルを特定し、それを削除してください。

note: Tag: para
en: If the client successfully authenticates by any of the methods listed above, it will attempt to cache the credentials on disk (unless the user has disabled this behavior, as mentioned earlier).
ja: クライアントが上記のどれかの方法で認証に成醐ｻ駈ｵた場合はディスク上にその 証明をキャッシュしようとします (既に述べたように、ユーザがこの動作 を無効にしない限り、そうします)。

note: Tag: title
en: Branching and Merging
ja: ブランチとマージ

note: Tag: para
en: Branching, tagging, and merging are concepts common to almost all version control systems. If you're not familiar with these ideas, we provide a good introduction in this chapter. If you are familiar, then hopefully you'll find it interesting to see how Subversion implements these ideas.
ja: ブランチ、タグ、マージはほとんどすべてのバージョン管理システムで 共通の概念です。もしあまりなじみがないのであれば、この章は良い とっかかりになるでしょう。既に詳しいのであれば、これらの概念 をSubversionがどのように実装しているかを知るのに興味深い章である ことがわかるでしょう。

note: Tag: para
en: Branching is a fundamental part of version control. If you're going to allow Subversion to manage your data, then this is a feature you'll eventually come to depend on. This chapter assumes that you're already familiar with Subversion's basic concepts (<xref linkend="svn.basic"/>).
ja: ブランチ化は、バージョン管理の基本にあります。Subversionで自分の データをマージするときには、この機能はときどき必要となる機能です。 この章では、あなたがSubversionの基本コンセプトを既に理解している ことを前提とします(<xref linkend="svn.basic"/>)。

note: Tag: title
en: What's a Branch?
ja: ブランチとは?

note: Tag: para
en: Suppose it's your job to maintain a document for a division in your company, a handbook of some sort. One day a different division asks you for the same handbook, but with a few parts <quote>tweaked</quote> for them, since they do things slightly differently.
ja: あなたの仕事が、何かのハンドブックを扱う企業の一部署で、ドキュメントの 管理をすることだとします。ある日別の部署から同じハンドブックが必要 なのだが、ある部分を<quote>ちょっとだけ</quote>変えたものがほしい、ほんの少しだけ 業務形態に違いがあるから、といわれたとします。

note: Tag: para
en: What do you do in this situation? You do the obvious thing: you make a second copy of your document, and begin maintaining the two copies separately. As each department asks you to make small changes, you incorporate them into one copy or the other.
ja: この状況で、あなたはどうしなくてはならないでしょうか? 答えはあたりまえです: ドキュメントのコピーを作って二つのコピーを 別々に管理することにします。それぞれの部署が小さな変更を依頼して くるたび、一方を修正したり、もう一方を修正したりします。

note: Tag: para
en: You often want to make the same change to both copies. For example, if you discover a typo in the first copy, it's very likely that the same typo exists in the second copy. The two documents are almost the same, after all; they only differ in small, specific ways.
ja: 両方のコピーに同じ修正を加えたいこともよくあります。たとえば 最初のコピーにスペルミスがあったとします。もう一方のコピーにも おそらく同じ間違いがあるでしょう。両方のドキュメントはほとんど同じ なのですから。二つはほんの少し違っているだけです。

note: Tag: para
en: This is the basic concept of a <firstterm>branch</firstterm>&mdash;namely, a line of development that exists independently of another line, yet still shares a common history if you look far enough back in time. A branch always begins life as a copy of something, and moves on from there, generating its own history (see <xref linkend="svn.branchmerge.whatis.dia-1"/>).
ja: これは <firstterm>ブランチ</firstterm>の基本的な概念です&mdash; つまり、一つの開発の流れが、もう一方と独立して存在しているが、 もし過去にさかのぼれば、同じ履歴を共有している、という状況です。 ブランチは必ず、何かのコピーから始まり、枝分かれして、 自分自身の歴史を持っていくようになります(<xref linkend="svn.branchmerge.whatis.dia-1"/>を参照してください)。

note: Tag: title
en: Branches of development
ja: 開発のブランチ

note: Tag: para
en: Subversion has commands to help you maintain parallel branches of your files and directories. It allows you to create branches by copying your data, and remembers that the copies are related to one another. It also helps you duplicate changes from one branch to another. Finally, it can make portions of your working copy reflect different branches, so that you can <quote>mix and match</quote> different lines of development in your daily work.
ja: Subversionはファイルやディレクトリの平行したブランチを管理するのを 手助けするコマンドがあります。データをコピーしてブランチを作ったり、 どのように二つのコピーが関係しているかを記憶しておくことができます。 片方のブランチに対する修正をもう一方にも追加する作業を助けることも できます。最後に、作業コピーの一部だけ別のブランチにすることもできる ので、通常の作業で、別の作業のラインを<quote>混ぜあわせる</quote>こともできます。

note: Tag: title
en: Using Branches
ja: ブランチの利用

note: Tag: para
en: At this point, you should understand how each commit creates an entire new filesystem tree (called a <quote>revision</quote>) in the repository. If not, go back and read about revisions in <xref linkend="svn.basic.in-action.revs"/>.
ja: これまでのところで、それぞれのコミットがどうやってリポジトリに完全に新しい ファイルシステムツリー(<quote>リビジョン</quote>と呼ばれます)を作るかを知っていると思います。 まだ知らないのであれば、戻ってリビジョンに関する<xref linkend="svn.basic.in-action.revs"/>を 読んでください。

note: Tag: title
en: Starting repository layout
ja: リポジトリレイアウトの開始

note: Tag: para
en: As before, assume that Sally and you both have working copies of the <quote>calc</quote> project. Specifically, you each have a working copy of <filename>/calc/trunk</filename>. All the files for the project are in this subdirectory rather than in <filename>/calc</filename> itself, because your team has decided that <filename>/calc/trunk</filename> is where the <quote>main line</quote> of development is going to take place.
ja: 以前と同様、あなたと Sally はそれぞれ <quote>calc</quote> プロジェクトの作業コピーを持っているとします。特に両者はそれぞれ <filename>/calc/trunk</filename>の作業コピーを持っています。 プロジェクトのすべてのファイルは <filename>/calc</filename>に ではなくこのサブディレクトリ中にありますが、それは皆が開発の<quote>主系</quote> を <filename>/calc/trunk</filename>に置くことに決めたからです。

note: Tag: para
en: One strategy is to crawl into a hole: you and Sally can stop sharing information for a week or two. That is, start gutting and reorganizing all the files in your working copy, but don't commit or update until you're completely finished with the task. There are a number of problems with this, though. First, it's not very safe. Most people like to save their work to the repository frequently, should something bad accidentally happen to their working copy. Second, it's not very flexible. If you do your work on different computers (perhaps you have a working copy of <filename>/calc/trunk</filename> on two different machines), you'll need to manually copy your changes back and forth, or just do all the work on a single computer. By that same token, it's difficult to share your changes-in-progress with anyone else. A common software development <quote>best practice</quote> is to allow your peers to review your work as you go. If nobody sees your intermediate commits, you lose potential feedback. Finally, when you're finished with all your changes, you might find it very difficult to re-merge your final work with the rest of the company's main body of code. Sally (or others) may have made many other changes in the repository that are difficult to incorporate into your working copy&mdash;especially if you run <command>svn update</command> after weeks of isolation.
ja: 一つのやり方として、閉じこもってしまう方法があります:あなたと Sallyは1,2週間、情報を共有するのをやめます。つまり、自分の 作業コピー中の全ファイルに対する大手術を始めるのですが、 それが完了するまで、コミットも更新もしないという方法です。 しかしこれにはいろいろな問題があります。まず安全ではありません。 ほとんどの人は、作業コピーにヘンなことが起こらないように、 リポジトリに対してこまめに自分の作業を保存するのを好みます。 次に、まったく柔軟ではありません。もし、あなたがたが別の マシンで仕事をしているなら、(多分二つの別のマシンに <filename>/calc/trunk</filename> の作業コピーがあるのでしょう) 自分の変更を手であちこちにコピーしなくてはならないか、 一つのマシン上に作業全体をフルコピーするかになります。 同じようにして他の誰との間でも自分の進行中の変更部分を共有する ことは困難です。通常のソフトウェア開発で<quote>一番よいやり方</quote> はあなたの作業の進行状況を他の人からも参照できるようにすることです。 もしあなたの中間的なコミットを誰も見ることができないとすると あなたは他の人からフィードバックしてもらうことができなくなって しまいます。 最終的に自分の変更作業が完了したとき、その変更を コミットするのは非常に困難であることに気づくでしょう。Sally(と 他のメンバー)はリポジトリに対してたくさんの別の変更を加えており、 それをあなたの作業コピーにマージするのは困難です&mdash; 何週間も孤立した作業の後に<command>svn update</command>を実行する ような場合には特にそうです。

note: Tag: para
en: The better solution is to create your own branch, or line of development, in the repository. This allows you to save your half-broken work frequently without interfering with others, yet you can still selectively share information with your collaborators. You'll see exactly how this works later on.
ja: もっとましなやり方はリポジトリに自分用のブランチ、あるいは 自分用の作業の別ラインを作ることです。これは他の人に干渉 せずに、自分の中途半端な作業をときどき保存できるように しますが、それでも同僚との間で、一部の情報については共有する ことができます。どうやったらこんなことができるかは後で説明 します。

note: Tag: title
en: Creating a Branch
ja: ブランチの作成

note: Tag: para
en: Creating a branch is very simple&mdash;you make a copy of the project in the repository using the <command>svn copy</command> command. Subversion is not only able to copy single files, but whole directories as well. In this case, you want to make a copy of the <filename>/calc/trunk</filename> directory. Where should the new copy live? Wherever you wish&mdash;it's a matter of project policy. Let's say that your team has a policy of creating branches in the <filename>/calc/branches</filename> area of the repository, and you want to name your branch <literal>my-calc-branch</literal>. You'll want to create a new directory, <filename>/calc/branches/my-calc-branch</filename>, which begins its life as a copy of <filename>/calc/trunk</filename>.
ja: ブランチの作成はとても簡単です &mdash; <command>svn copy</command> コマンドでリポジトリ中のプロジェクトをコピーするだけです。 Subversionでは一つのファイルをコピーするだけでなく、ディレクトリ 全体をコピーすることができます。今回は、<filename>/calc/trunk</filename> ディレクトリのコピーがほしいでしょう。新しいコピーはどこに置けば 良いのでしょう? 好きな場所に置けます &mdash; あとはプロジェクトのポリシーに よります。チームのポリシーは、リポジトリの<filename>/calc/branches</filename> 領域にブランチを作ることで、ブランチ名は <quote>my-calc-branch</quote> としましょう。この場合、<filename>/calc/trunk</filename>のコピーとして、 <filename>/calc/branches/my-calc-branch</filename>という新しいディレクトリ を作る必要があります。

note: Tag: para
en: There are two different ways to make a copy. We'll demonstrate the messy way first, just to make the concept clear. To begin, check out a working copy of the project's root directory, <filename>/calc</filename>:
ja: コピーを作るには、二つの方法があります。面倒な方法を最初に 説明して、概念をはっきりさせます。最初にプロジェクトのルートディレクトリ である <filename>/calc</filename>を作業コピーにチェックアウトします:

note: Tag: para
en: Making a copy is now simply a matter of passing two working-copy paths to the <command>svn copy</command> command:
ja: あとは、 <command>svn copy</command>コマンドに作業コピーパスを 二つ渡すだけでコピーを作れます:

note: Tag: para
en: In this case, the <command>svn copy</command> command recursively copies the <filename>trunk</filename> working directory to a new working directory, <filename>branches/my-calc-branch</filename>. As you can see from the <command>svn status</command> command, the new directory is now scheduled for addition to the repository. But also notice the <quote>+</quote> sign next to the letter A. This indicates that the scheduled addition is a <emphasis>copy</emphasis> of something, not something new. When you commit your changes, Subversion will create <filename>/calc/branches/my-calc-branch</filename> in the repository by copying <filename>/calc/trunk</filename>, rather than resending all of the working copy data over the network:
ja: この場合、<command>svn copy</command> コマンドは再帰的に <filename>trunk</filename>作業ディレクトリの内容を 新しい作業ディレクトリ<filename>branches/my-calc-branch</filename> にコピーします。<command>svn status</command> コマンドで 確認できますが、これで新しいディレクトリはリポジトリへの追加として 予告されます。ただ、Aの後に、<quote>+</quote>サインが表示されるのに注意して ください。これは、追加予告が、新規のものではなく、何かの <emphasis>コピー</emphasis> であることを示しています。 変更をコミットすると、Subversionは、ネットワーク越しに 作業コピーデータの全体を再送信するのではなく、 <filename>/calc/trunk</filename>をコピーすることで リポジトリに <filename>/calc/branches/my-calc-branch</filename> を作ります:

note: Tag: screen
en: $ svn copy http://svn.example.com/repos/calc/trunk \
               http://svn.example.com/repos/calc/branches/my-calc-branch \
          -m "Creating a private branch of /calc/trunk."
    
    Committed revision 341.
ja: $ svn copy http://svn.example.com/repos/calc/trunk ¥
               http://svn.example.com/repos/calc/branches/my-calc-branch ¥
          -m "Creating a private branch of /calc/trunk"
    
    Committed revision 341.

note: Tag: title
en: Repository with new copy
ja: 新しいコピーのあるリポジトリ

note: Tag: title
en: Cheap Copies
ja: 簡易コピー

note: Tag: para
en: This is why you'll often hear Subversion users talk about <quote>cheap copies</quote>. It doesn't matter how large the directory is&mdash;it takes a very tiny, constant amount of time to make a copy of it. In fact, this feature is the basis of how commits work in Subversion: each revision is a <quote>cheap copy</quote> of the previous revision, with a few items lazily changed within. (To read more about this, visit Subversion's website and read about the <quote>bubble up</quote> method in Subversion's design documents.)
ja: これが、Subversionユーザが、<quote>簡易コピー</quote>という言葉をよく聞く 理由です。ディレクトリがどれほど大きいかには無関係なのです &mdash; コピーには非常にわずかな、一定の時間がかかるだけです。 これがSubversionでのコミットのやり方の基本です: それぞれの リビジョンは前のリビジョンの<quote>簡易コピー</quote>で、その中のいくつか のアイテムだけが、実際にコピーされます。(もっと知りたい人は Subversionのウェブサイトに行き、Subversion設計ドキュメント中の <quote>bubble up</quote>方式を読んでください)

note: Tag: title
en: Working with Your Branch
ja: 自分用のブランチでの作業

note: Tag: para
en: Now that you've created a branch of the project, you can check out a new working copy to start using it:
ja: これでプロジェクトにブランチを作ることができたので それを使った新しい作業コピーをチェックアウトできます:

note: Tag: para
en: Let's pretend that a week goes by, and the following commits happen:
ja: 一週間が経過する間に、以下のコミットが起こったとしましょう:

note: Tag: para
en: You make a change to <filename>/calc/branches/my-calc-branch/button.c</filename>, which creates revision 342.
ja: <filename>/calc/branches/my-calc-branch/button.c</filename>, に変更を加え、リビジョン342を作った。

note: Tag: para
en: You make a change to <filename>/calc/branches/my-calc-branch/integer.c</filename>, which creates revision 343.
ja: <filename>/calc/branches/my-calc-branch/integer.c</filename>, に変更を加え、リビジョン343を作った。

note: Tag: para
en: Sally makes a change to <filename>/calc/trunk/integer.c</filename>, which creates revision 344.
ja: Sallyは <filename>/calc/trunk/integer.c</filename>に 修正を加え、リビジョン344を作った。

note: Tag: para
en: There are now two independent lines of development, shown in <xref linkend="svn.branchmerge.using.work.dia-1"/>, happening on <filename>integer.c</filename>.
ja: これで、<xref linkend="svn.branchmerge.using.work.dia-1"/>に示すように <filename>integer.c</filename>に二つの独立した開発ラインができました:

note: Tag: title
en: The branching of one file's history
ja: あるファイルの履歴のブランチ化

note: Tag: para
en: Things get interesting when you look at the history of changes made to your copy of <filename>integer.c</filename>:
ja: <filename>integer.c</filename>のコピーに起きた変更履歴を 見ると面白いことがわかります:

note: Tag: para
en: Notice that Subversion is tracing the history of your branch's <filename>integer.c</filename> all the way back through time, even traversing the point where it was copied. It shows the creation of the branch as an event in the history, because <filename>integer.c</filename> was implicitly copied when all of <filename>/calc/trunk/</filename> was copied. Now look what happens when Sally runs the same command on her copy of the file:
ja: Subversion はブランチにある<filename>integer.c</filename>の履歴を 時間を逆向きにたどり、これにはコピーされた地点も含まれることに注意 してください。それはブランチの生成を履歴上の一つのできごととして 表示しますが、それは<filename>integer.c</filename>も <filename>/calc/trunk/</filename>全体がコピーされたときに暗黙に コピーされたものだからです。今度は Sally が自分のファイルコピー上 で同じコマンドを実行した結果を見てみましょう:

note: Tag: para
en: Sally sees her own revision 344 change, but not the change you made in revision 343. As far as Subversion is concerned, these two commits affected different files in different repository locations. However, Subversion <emphasis>does</emphasis> show that the two files share a common history. Before the branch-copy was made in revision 341, they used to be the same file. That's why you and Sally both see the changes made in revisions 303 and 98.
ja: Sallyは自分のリビジョン344の変更を見ることができますが、あなたが リビジョン343にやった変更は見ることができません。Subversionでは、 この二つのコミットはリポジトリの別の場所にある別のファイルに 対して起こります。しかし、Subversionは、二つのファイルが共通の履歴を 持っていることを<emphasis>示してもいます</emphasis>。リビジョン341 で起きたブランチコピーの前は両者は同じファイルを使っていました。 Sallyとあなたがどちらもリビジョン 303と98での変更を見ることができるのは そのためです。

note: Tag: title
en: The Key Concepts Behind Branches
ja: ブランチの背後にある鍵となる考え方

note: Tag: title
en: Copying Changes Between Branches
ja: ブランチをまたいで変更をコピーすること

note: Tag: para
en: Now you and Sally are working on parallel branches of the project: you're working on a private branch, and Sally is working on the <firstterm>trunk</firstterm>, or main line of development.
ja: さて、あなたとSallyはプロジェクト上の平行したブランチで作業しています。 あなたは自分のプライベートなブランチで作業していて、Sally は <firstterm>trunk</firstterm>、あるいは、開発の主系の上で作業していると します。

note: Tag: para
en: For projects that have a large number of contributors, it's common for most people to have working copies of the trunk. Whenever someone needs to make a long-running change that is likely to disrupt the trunk, a standard procedure is to create a private branch and commit changes there until all the work is complete.
ja: たくさんの貢献者がいるようなプロジェクトでは、ほとんどの人たちは trunkのコピーを持っているのが普通です。trunk を壊してしまうかも知れない ような長い期間をかけての変更を加える必要がある場合は常に、標準的な手続き としてはまずプライベートなブランチを作り、すべての作業が完了するまで変更 点をそのブランチにコミットします。

note: Tag: para
en: So, the good news is that you and Sally aren't interfering with each other. The bad news is that it's very easy to drift <emphasis>too</emphasis> far apart. Remember that one of the problems with the <quote>crawl in a hole</quote> strategy is that by the time you're finished with your branch, it may be near-impossible to merge your changes back into the trunk without a huge number of conflicts.
ja: そのようなやり方の利点としては、二人の作業はお互いに干渉しないところです。 欠点は二人の作業内容はすぐに<emphasis>ひどく</emphasis> 違っていって しまうことです。<quote>引きこもり</quote>戦略の問題の一つは自分のブランチの作業が 完了するときに起こることを思い出してください。恐ろしくたくさんの衝突 なしに、あなたの変更をtrunkにマージするのはほとんど不可能でしょう。

note: Tag: para
en: Instead, you and Sally might continue to share changes as you work. It's up to you to decide which changes are worth sharing; Subversion gives you the ability to selectively <quote>copy</quote> changes between branches. And when you're completely finished with your branch, your entire set of branch changes can be copied back into the trunk.
ja: そのかわりに、作業中に、あなたとSallyは変更を共有し続けるのが良い でしょう。どのような変更が共有する価値があるのかはあなたが決める ことです。Subversionを使うとブランチ間の選択的な<quote>コピー</quote>ができます。 そしてブランチ上での作業が完全に終ったら、ブランチ上にした変更点の 全体をtrunkに書き戻すことができます。

note: Tag: title
en: Copying Specific Changes
ja: 特定の変更点のコピー

note: Tag: para
en: In the previous section, we mentioned that both you and Sally made changes to <filename>integer.c</filename> on different branches. If you look at Sally's log message for revision 344, you can see that she fixed some spelling errors. No doubt, your copy of the same file still has the same spelling errors. It's likely that your future changes to this file will be affecting the same areas that have the spelling errors, so you're in for some potential conflicts when you merge your branch someday. It's better, then, to receive Sally's change now, <emphasis>before</emphasis> you start working too heavily in the same places.
ja: 前の節で、あなたとSallyは別ブランチ上で<filename>integer.c</filename> に変更を加えたと言いました。もしリビジョン344のSallyのログメッセージ を見れば、何かのスペルミスを直したことがわかるかも知れません。 この場合間違いなく、同じファイルのあなたのコピーもやはり同じスペルミスが あるはずです。このファイルに対する今後のあなたの修正はスペルミスのある 場所に影響を与えるかも知れず、自分のブランチをいつかマージするときに は衝突が起こってしまいます。そうなるくらいなら、あまりひどいことになる <emphasis>前に</emphasis>、Sallyの修正をいま受け取ったほうが良いでしょう。

note: Tag: para
en: The <command>svn merge</command> command is almost exactly the same. Instead of printing the differences to your terminal, however, it applies them directly to your working copy as <emphasis>local modifications</emphasis>:
ja: <command>svn merge</command> コマンドもほとんど同じです。差分を 画面に表示するかわりに、それは<emphasis>ローカルな 修正分</emphasis>として直接あなたの作業コピーに適用 します:

note: Tag: para
en: The output of <command>svn merge</command> shows that your copy of <filename>integer.c</filename> was patched. It now contains Sally's change&mdash;the change has been <quote>copied</quote> from the trunk to your working copy of your private branch, and now exists as a local modification. At this point, it's up to you to review the local modification and make sure it works correctly.
ja: <command>svn merge</command> の出力は、あなた用の <filename>integer.c</filename> のコピーがパッチされた 結果です。これでSallyの変更が含まれるようになりました&mdash; それはtrunkからあなたのプライベートなブランチの作業コピーに <quote>コピー</quote>され、ローカルな修正の一部となりました。この修正を再検討し、 正しく動作することを確認するのはあなたの仕事です。

note: Tag: para
en: But assuming that you've reviewed the merged change, you can <command>svn commit</command> the change as usual. At that point, the change has been merged into your repository branch. In version control terminology, this act of copying changes between branches is commonly called <firstterm>porting</firstterm> changes.
ja: しかし、マージされた変更を確認して、<command>svn commit</command> をかけるのが普通です。これで、変更は自分のリポジトリブランチに マージされました。バージョン管理の言い方では、このようなブランチ間の 修正点のコピーを、普通<firstterm>porting</firstterm> による変更と いいます。

note: Tag: para
en: When you commit the local modification, make sure your log message mentions that you're porting a specific change from one branch to another. For example:
ja: ローカルな修正をコミットするときには、あるブランチから別のブランチ に対して特定の変更を移したことを示すようなログメッセージになって いることを確認してください。たとえば:

note: Tag: para
en: As you'll see in the next sections, this is a very important <quote>best practice</quote> to follow.
ja: 次の節で見るように、これは参考にすべき <quote>最善の方法</quote> です。非常に重要です。

note: Tag: title
en: Why Not Use Patches Instead?
ja: どうしてパッチを使わないの?

note: Tag: para
en: A question may be on your mind, especially if you're a Unix user: why bother to use <command>svn merge</command> at all? Why not simply use the operating system's <command>patch</command> command to accomplish the same job? For example:
ja: そう思うかも知れません。特にあなたがUnixユーザならそうでしょう。 なんでわざわざ<command>svn merge</command> みたいなものを使うのか? どうして単にOSについている<command>patch</command> コマンドを 使って同じことをしないのか? たとえば:

note: Tag: para
en: You want to merge directory changes into your current working directory.
ja: 現在の作業ディレクトリ中に、ディレクトリの変更点をマージ しようとしている。

note: Tag: para
en: You want to merge the changes in a specific file into a file by the same name which exists in your current working directory.
ja: 現在の作業ディレクトリ中にある同じ名前のファイルに対して、 ある特定のファイルに起きた修正をマージしようとしている。

note: Tag: para
en: If you are merging a directory and haven't specified a target path, <command>svn merge</command> assumes the first case above and tries to apply the changes into your current directory. If you are merging a file, and that file (or a file by the same name) exists in your current working directory, <command>svn merge</command> assumes the second case and tries to apply the changes to a local file with the same name.
ja: ディレクトリをマージしようとしている場合で、目的のパスを指定しなかった 場合、<command>svn merge</command>は、上にあげた第一の場合であると みなし、現在のディレクトリ中のファイルに対して適用しようとします。 もし、ファイルをマージしようとしている場合で、そのファイル(または 同じ名前のファイル)が作業コピーディレクトリに存在している場合、 <command>svn merge</command>は第二の場合であるとみなし、同じ名前の ローカルファイルに対して変更を適用しようとします。

note: Tag: para
en: If you want changes applied somewhere else, you'll need to say so. For example, if you're sitting in the parent directory of your working copy, you'll have to specify the target directory to receive the changes:
ja: 上記以外の場所に適用したい場合には そのことを明示的に指定する必要があります。たとえば作業コピーの親ディレクトリ にいて、変更を受け取るための対象ディレクトリを指定する必要がある場合なら:

note: Tag: title
en: The Key Concept Behind Merging
ja: マージの基本的な考え方

note: Tag: para
en: You've now seen an example of the <command>svn merge</command> command, and you're about to see several more. If you're feeling confused about exactly how merging works, you're not alone. Many users (especially those new to version control) are initially perplexed about the proper syntax of the command, and about how and when the feature should be used. But fear not, this command is actually much simpler than you think! There's a very easy technique for understanding exactly how <command>svn merge</command> behaves.
ja: ここまでのところで <command>svn merge</command> の例を見てきましたが、さらにいくつかの例を あげます。マージが本当のところどのように機能するかについて何か混乱 した気になるのは何もあなただけではありません。多くのユーザは(特に バージョン管理システムになじみのない人にとっては) まず最初にコマンド の構文に戸惑い、さらにどのようにして、またいつその機能をつかえば良い かということにも戸惑います。しかし怖がることは何もありません。このコマンドは 実際にはあなたが思っているよりずっと単純なものです。<command>svn merge</command> がどのように動作するかを正確に知るためのとても簡単な方法があります。

note: Tag: para
en: The main source of confusion is the <emphasis>name</emphasis> of the command. The term <quote>merge</quote> somehow denotes that branches are combined together, or that there's some sort of mysterious blending of data going on. That's not the case. A better name for the command might have been <command>svn diff-and-apply</command>, because that's all that happens: two repository trees are compared, and the differences are applied to a working copy.
ja: 混乱の一番の原因はこのコマンドの<emphasis>名前</emphasis>です。<quote> マージ(merge)</quote>という言葉は、何か二つのブランチが統合されたり、 データ同士が、何か神秘的な方法で混ぜ合わされてしまったりするような表現 です。しかし、そんなことがおこるわけではありません。多分このコマンドに 対するもっとふさわしい名前は<command>svn diff-and-apply</command>(差分 をとってから、それを適用する)かも知れません。実際、起こることは本当に それだけなのですから: つまり、二つのリポジトリのツリーが比較され、その 差分が、作業コピーに適用されるのです。

note: Tag: para
en: The command takes three arguments:
ja: このコマンドは三つの引数をとります:

note: Tag: para
en: An initial repository tree (often called the <firstterm>left side</firstterm> of the comparison),
ja: 最初の状態を示すリポジトリ・ツリー ( 比較時の<firstterm>左側</firstterm> などとよく言われます),

note: Tag: para
en: A final repository tree (often called the <firstterm>right side</firstterm> of the comparison),
ja: 最終的な状態を示すリポジトリ・ツリー (often called the 比較時の<firstterm>右側</firstterm> などとよく言われます),

note: Tag: para
en: A working copy to accept the differences as local changes (often called the <firstterm>target</firstterm> of the merge).
ja: 上記二つの間の差分をローカルな変更として受け入れる作業コピー (マージの <firstterm>ターゲット</firstterm>などとよく言われます).

note: Tag: para
en: Once these three arguments are specified, the two trees are compared, and the resulting differences are applied to the target working copy as local modifications. When the command is done, the results are no different than if you had hand-edited the files, or run various <command>svn add</command> or <command>svn delete</command> commands yourself. If you like the results, you can commit them. If you don't like the results, you can simply <command>svn revert</command> all of the changes.
ja: この三つの引数が指定されると二つのツリーが比較され、結果の 差分がターゲットの作業コピーに対して、ローカルな修正点の形で反映されま す。この結果はあなた自身が手作業でファイルを編集したり、<command>svn add</command> や <command>svn delete</command>コマンドをいろいろと実行 したのとなんら変わるところはありません。結果の修正内容が満足のいくもの であれば、それをコミットすることができます。気に入らなければ、単に <command>svn revert</command>を実行しさえすればすべての変更は元に戻り ます。

note: Tag: para
en: The syntax of <command>svn merge</command> allows you to specify the three necessary arguments rather flexibly. Here are some examples:
ja: <command>svn merge</command> の構文は必要な三つの引数をある程度 柔軟に指定できるようになっています。以下がその例です:

note: Tag: para
en: The first syntax lays out all three arguments explicitly, naming each tree in the form <emphasis>URL@REV</emphasis> and naming the working copy target. The second syntax can be used as a shorthand for situations when you're comparing two different revisions of the same URL. The last syntax shows how the working-copy argument is optional; if omitted, it defaults to the current directory.
ja: 最初の構文は三つのすべての引数を明示的に指定するもので、ツリーについては それぞれ <emphasis>URL@REV</emphasis> の形で指定し、ターゲットの作業コピー はその名前で示します。二番目の構文は、同じ URL 上にある異なるリビジョンを 比較する場合の略記法です。最後の構文は作業コピーを省略した場合の例です; デフォルトではカレントディレクトリが指定される決まりです。

note: Tag: title
en: Best Practices for Merging
ja: マージの一番うまいやり方

note: Tag: title
en: Tracking Merges Manually
ja: 手でマージする方法

note: Tag: para
en: Merging changes sounds simple enough, but in practice it can become a headache. The problem is that if you repeatedly merge changes from one branch to another, you might accidentally merge the same change <emphasis>twice</emphasis>. When this happens, sometimes things will work fine. When patching a file, Subversion typically notices if the file already has the change, and does nothing. But if the already-existing change has been modified in any way, you'll get a conflict.
ja: 変更のマージは非常に単純なことに思えますが実際には厄介な ものです。問題は、もし一つのブランチを別のブランチに対して 変更点を繰り返しマージすると、間違って同じ変更を <emphasis>二度</emphasis>やってしまうかも知れないということです。 こういうことが起こっても、問題が起こらないこともあります。 ファイルをパッチするとき、Subversion はファイルが既に変更されている 場合にはそれに気がついて、何もしません。しかし、既に存在している 変更が何らかの方法で修正されていた場合、衝突が起こります。

note: Tag: para
en: Ideally, your version control system should prevent the double-application of changes to a branch. It should automatically remember which changes a branch has already received, and be able to list them for you. It should use this information to help automate merges as much as possible.
ja: 理想的には、バージョン管理システムはブランチに対して変更点の重複 した適用を回避すべきです。ブランチが既に受け取った変更点を自動的に 記憶し、その一覧を表示できるようにすべきです。そしてバージョン管理システム は自動マージを支援するために可能な限りこの情報を利用すべきです。

note: Tag: para
en: In the next section, we'll show some examples of this technique in action.
ja: 次の節ではこの技法の例を実際にお見せします。

note: Tag: title
en: Previewing Merges
ja: マージ内容の確認

note: Tag: para
en: In cases like this, people take comfort in being able to predict or examine merges before they happen. One simple way to do that is to run <command>svn diff</command> with the same arguments you plan to pass to <command>svn merge</command>, as we already showed in our first example of merging. Another method of previewing is to pass the <option>--dry-run</option> option to the merge command:
ja: このような場合には、実際にマージする前に、マージしたとしたらどうなるか を調べておくべきです。このための一つの簡単な方法としては<command>svn merge</command>に渡そうとしているのと同じ引数で<command>svn diff</command> を実行する方法があります。それは既にマージの最初の例で見たものです。 もう一つの方法は、マージコマンドに対して <option>--dry-run</option> オプションを渡す方法です:

note: Tag: para
en: The <option>--dry-run</option> option doesn't actually apply any local changes to the working copy. It only shows status codes that <emphasis>would</emphasis> be printed in a real merge. It's useful for getting a <quote>high level</quote> preview of the potential merge, for those times when running <command>svn diff</command> gives too much detail.
ja: <option>--dry-run</option>オプションは、実際には作業コピーに対してローカルな 修正を適用しません。実際のマージで表示されるで<emphasis>あろう</emphasis> 状態コードを表示するだけです。これは<command>svn diff</command>ではあまりにも詳細 な内容が表示されてしまうような場合に、潜在的なマージの概要を確認するための <quote>高度な</quote>方法です。

note: Tag: title
en: Merge Conflicts
ja: マージの衝突

note: Tag: para
en: Just like the <command>svn update</command> command, <command>svn merge</command> applies changes to your working copy. And therefore it's also capable of creating conflicts. The conflicts produced by <command>svn merge</command>, however, are sometimes different, and this section explains those differences.
ja: <command>svn update</command> コマンドと同様 <command>svn merge</command> は変更を作業コピーに対して行うので 衝突を起こすこともあります。しかし <command>svn merge</command>によっておきた衝突については様子が 違うこともあり、以下ではこの違いについて説明します。

note: Tag: para
en: To begin with, assume that your working copy has no local edits. When you <command>svn update</command> to a particular revision, the changes sent by the server will always apply <quote>cleanly</quote> to your working copy. The server produces the delta by comparing two trees: a virtual snapshot of your working copy, and the revision tree you're interested in. Because the left-hand side of the comparison is exactly equal to what you already have, the delta is guaranteed to correctly convert your working copy into the right-hand tree.
ja: まず、作業コピーにはローカルな修正が加えられていないとします。 特定のリビジョンに対して<command>svn update</command>を実行すると サーバから送られてきた変更点は作業コピーに対して常に <quote>きれいに </quote>適用されます。サーバは二つのツリーを比較することで差分を 生成します: 作業コピーの仮想的なスナップショットと、適用しようとして いるリビジョンとの間の差分です。前者は作業コピーと全く同じものなので この差分が作業コピーをきれいに後者に変換することは保証されています。

note: Tag: para
en: Also notice that the previous example shows a conflict happening on <filename>glorb.h</filename>. We already stated that the working copy has no local edits: how can a conflict possibly happen? Again, because the user can use <command>svn merge</command> to define and apply any old delta to the working copy, that delta may contain textual changes that don't cleanly apply to a working file, even if the file has no local modifications.
ja: 前の例では<filename>glorb.h</filename>に衝突が起きたことにも注意 してください。今回の場合作業コピーに対してローカルな修正がされていない ことはすでに述べました: ではなぜ衝突が起きるのでしょうか? この場合 でもやはりユーザは<command>svn merge</command>で古い差分を作ってから 作業コピーに適用することができるので、ローカルな修正がなかったと しても、その差分が作業コピーに対してきれいに適用できないような変更を 含んでしまうことはありうるのです。

note: Tag: para
en: Another small difference between <command>svn update</command> and <command>svn merge</command> are the names of the full-text files created when a conflict happens. In <xref linkend="svn.tour.cycle.resolve"/>, we saw that an update produces files named <filename>filename.mine</filename>, <filename>filename.rOLDREV</filename>, and <filename>filename.rNEWREV</filename>. When <command>svn merge</command> produces a conflict, though, it creates three files named <filename>filename.working</filename>, <filename>filename.left</filename>, and <filename>filename.right</filename>. In this case, the terms <quote>left</quote> and <quote>right</quote> are describing which side of the double-tree comparison the file came from. In any case, these differing names will help you distinguish between conflicts that happened as a result of an update versus ones that happened as a result of a merge.
ja: その他<command>svn update</command> と <command>svn merge</command>の 小さな違いとしては衝突がおきたときにできるテキストファイルの名前です。 <xref linkend="svn.tour.cycle.resolve"/>で見たように、update の場合には <filename>filename.mine</filename>, <filename>filename.rOLDREV</filename>, <filename>filename.rNEWREV</filename>という名前のファイルができます。 これにたいして<command>svn merge</command>の場合には <filename>filename.working</filename>, <filename>filename.left</filename>, <filename>filename.right</filename>という名前になります。 この場合<quote>left</quote> と <quote>right</quote> は、それぞれの ファイルが比較した二つのツリーのどちら側に由来するものかを示しています。 いずれにせよファイル名称の違いは、衝突が update コマンドの結果である のか merge コマンドの結果であるかを区別する助けになるでしょう。

note: Tag: title
en: Noticing or Ignoring Ancestry
ja: 系統(Ancestry)を考慮することと無視すること

note: Tag: para
en: When conversing with a Subversion developer, you might very likely hear reference to the term <firstterm>ancestry</firstterm>. This word is used to describe the relationship between two objects in a repository: if they're related to each other, then one object is said to be an ancestor of the other.
ja: Subversion 開発者と会話するとき<firstterm>系統 </firstterm>(ancestry)という言葉を非常によく耳にするでしょう。 この言葉はリポジトリ中の二つのオブジェクト間の関係を記述するた めに用いられるものです:もし両者が互いに関係している場合、ある オブジェクトはもう一方の祖先(ancestor)といわれます。

note: Tag: para
en: For example, suppose you commit revision 100, which includes a change to a file <filename>foo.c</filename>. Then <filename>foo.c@99</filename> is an <quote>ancestor</quote> of <filename>foo.c@100</filename>. On the other hand, suppose you commit the deletion of <filename>foo.c</filename> in revision 101, and then add a new file by the same name in revision 102. In this case, <filename>foo.c@99</filename> and <filename>foo.c@102</filename> may appear to be related (they have the same path), but in fact are completely different objects in the repository. They share no history or <quote>ancestry</quote>.
ja: 例えば、リビジョン100をコミットし、それが <filename>foo.c</filename>というファイルへの変更を含んでいると します。すると<filename>foo.c@99</filename>は <filename>foo.c@100</filename>の<quote>祖先</quote>ということ になります。一方リビジョン 101 で<filename>foo.c</filename>を 削除するコミットがあり、リビジョン102 で同じ名前の新しいファイ ルを追加したとしましょう。この場合 <filename>foo.c@99</filename>と<filename>foo.c@102</filename> は関係しているように見えます(なぜなら同じファイル名なのですか ら)が、実際にはリポジトリ中ではまったく別のオブジェクトです。 両者は履歴、あるいは<quote>系統</quote>を共有していないからで す。

note: Tag: para
en: The reason for bringing this up is to point out an important difference between <command>svn diff</command> and <command>svn merge</command>. The former command ignores ancestry, while the latter command is quite sensitive to it. For example, if you asked <command>svn diff</command> to compare revisions 99 and 102 of <filename>foo.c</filename>, you would see line-based diffs; the <literal>diff</literal> command is blindly comparing two paths. But if you asked <command>svn merge</command> to compare the same two objects, it would notice that they're unrelated and first attempt to delete the old file, then add the new file; the output would indicate a deletion followed by an add:
ja: ここでこんな話をするのは、<command>svn diff</command>と <command>svn merge</command>の間の重要な違いを指摘したいからです。前者 は系統を無視しますが、後者は系統を非常に慎重に考慮します。例えば <command>svn diff</command>でリビジョン99 と102 の <filename>foo.c</filename>を比較した場合、行単位の差分を見ることになる でしょう; <literal>diff</literal> コマンドは二つのファイル名を無条件に比較するからです。 しかし<command>svn merge</command>を使っていまと同じ二つのオブジェクトを比較す るとそれらが無関係であることを検知し古いファイルをいったん削除し、それ から新しいファイルを追加しようとするでしょう; 出力は追加のあとに削除した ことを示すものとなるでしょう:

note: Tag: title
en: Common Use-Cases
ja: 典型的な利用方法

note: Tag: para
en: There are many different uses for branching and <command>svn merge</command>, and this section describes the most common ones you're likely to run into.
ja: ブランチの作り方と<command>svn merge</command>にはいくつもの異なったやり方があり、この節では あなたが出くわしそうな一番よくあるパターンについて説明します。

note: Tag: title
en: Merging a Whole Branch to Another
ja: ブランチ全体を別の場所にマージすること

note: Tag: para
en: To complete our running example, we'll move forward in time. Suppose several days have passed, and many changes have happened on both the trunk and your private branch. Suppose that you've finished working on your private branch; the feature or bug fix is finally complete, and now you want to merge all of your branch changes back into the trunk for others to enjoy.
ja: いま、考えてきた例を完結させるため、少し時間が経過したとします。何日か 経過し、たくさんの変更がtrunkにもあなたのプライベートなブランチにも 起こったとましす。そしてあなたはプライベートなブランチ上での作業を 終えたとしましょう; 機能追加、またはバグフィッックスが完了し、他の 人がその部分を使えるようにするために、あなたのブランチ上の変更点の すべてを trunk にマージしたいとします。

note: Tag: para
en: So how do we use <command>svn merge</command> in this scenario? Remember that this command compares two trees, and applies the differences to a working copy. So to receive the changes, you need to have a working copy of the trunk. We'll assume that either you still have your original one lying around (fully updated), or that you recently checked out a fresh working copy of <filename>/calc/trunk</filename>.
ja: さて、このような状況では、どのようにして<command>svn merge</command> を使えば良いのでしょうか? このコマンドは二つのツリーを比較し、その差分を 作業コピーに適用するものであったことを思い出してください。変更点 を受け取るためには、あなたはtrunkの作業コピーを手に入れる必要があります。 ここではあなたは(完全に更新された)もともとの作業コピーをまだ持っているか、 <filename>/calc/trunk</filename>の新しい作業コピーをチェックアウトしたもの と仮定します。

note: Tag: para
en: But which two trees should be compared? At first glance, the answer may seem obvious: just compare the latest trunk tree with your latest branch tree. But beware&mdash;this assumption is <emphasis>wrong</emphasis>, and has burned many a new user! Since <command>svn merge</command> operates like <command>svn diff</command>, comparing the latest trunk and branch trees will <emphasis>not</emphasis> merely describe the set of changes you made to your branch. Such a comparison shows too many changes: it would not only show the addition of your branch changes, but also the <emphasis>removal</emphasis> of trunk changes that never happened on your branch.
ja: しかし、どのツリーとどのツリーを比較すれば良いのでしょうか? ちょっと考えると、 その答えは明らかに思えます: 単にtrunkの最新のツリーと、あなたのブランチの最新の ツリーです。しかし、気をつけてください &mdash; この仮定は<emphasis>間違い </emphasis>です。そしてこの間違いに、たいていの初心者はやられてしまいます! <command>svn merge</command>は<command>svn diff</command>のように働くので 最後のトランクとブランチのツリーの比較は単にあなたが自分の ツリーに対して行った変更点のみを示すものでは<emphasis>ない</emphasis> のがわかります。 そのような比較は、非常にたくさんの変更を表示するでしょう: それは、あなたのブランチに対する追加点だけを表示するのではなく、 あなたのブランチでは決して起こらなかった、trunk上の変更点の<emphasis> 取り消し</emphasis>も表示してしまうことでしょう。

note: Tag: para
en: To express only the changes that happened on your branch, you need to compare the initial state of your branch to its final state. Using <command>svn log</command> on your branch, you can see that your branch was created in revision 341. And the final state of your branch is simply a matter of using the <literal>HEAD</literal> revision. That means you want to compare revisions 341 and <literal>HEAD</literal> of your branch directory, and apply those differences to a working copy of the trunk.
ja: あなたのブランチ上に起きた変更のみをあらわすには、あなたのブランチの 初期状態と、最終的な状態を比較する必要があります。 <command>svn log</command>コマンドをあなたのブランチ上で使えば、 そのブランチはリビジョン341で作られたことがわかります。そして、ブランチ の最終的な状態は、単に、<literal>HEAD</literal> リビジョンを指定すればわかります。 これはブランチディレクトリのリビジョン 341 と <literal>HEAD</literal> を比較しその違いを トランクの作業コピーに適用したいと考えていることを意味します。

note: Tag: para
en: A nice way of finding the revision in which a branch was created (the <quote>base</quote> of the branch) is to use the <option>--stop-on-copy</option> option to <command>svn log</command>. The log subcommand will normally show every change ever made to the branch, including tracing back through the copy which created the branch. So normally, you'll see history from the trunk as well. The <option>--stop-on-copy</option> will halt log output as soon as <command>svn log</command> detects that its target was copied or renamed.
ja: ブランチが作成されたリビジョンを見つけるうまい方法は (ブランチの<quote>ベース</quote>リビジョンのことですが)<command>svn log</command>で<option>--stop-on-copy</option>オプションを利用 することです。log サブコマンドは通常ブランチに対するすべての変更を表示 し、それはブランチが作成されたコピーよりも前にさかのぼります。このた め通常トランクの履歴も表示されてしまいます。 <option>--stop-on-copy</option>は、<command>svn log</command>がターゲットのコピーあ るいは名称変更の個所を見つけると直ちにログの出力を中止します。

note: Tag: para
en: So in our continuing example,
ja: それで現在の例で言うと、

note: Tag: para
en: As expected, the final revision printed by this command is the revision in which <filename>my-calc-branch</filename> was created by copying.
ja: 期待したとおり、このコマンドによって表示される最後のリビ ジョンはコピーによって<filename>my-calc-branch</filename>が作成された リビジョンになります。

note: Tag: para
en: Here's the final merging procedure, then:
ja: 結局、最終的なマージ処理は以下のようになります:

note: Tag: para
en: Again, notice that the commit log message very specifically mentions the range of changes that was merged into the trunk. Always remember to do this, because it's critical information you'll need later on.
ja: ここでもトランクにマージされた変更範囲についてコミットログメッセージは 非常に具体的に触れていることに注意してください。このことを常に憶えて おいてください。後になって必要になる非常に重要な情報だからです。

note: Tag: para
en: For example, suppose you decide to keep working on your branch for another week, in order to complete an enhancement to your original feature or bug fix. The repository's <literal>HEAD</literal> revision is now 480, and you're ready to do another merge from your private branch to the trunk. But as discussed in <xref linkend="svn.branchmerge.copychanges.bestprac"/>, you don't want to merge the changes you've already merged before; you only want to merge everything <quote>new</quote> on your branch since the last time you merged. The trick is to figure out what's new.
ja: たとえば、独自の機能拡張やバグフィックスなどのために、もう一週間自分の ブランチ上で作業を続けることにしたとしましょう。リポジトリの <literal>HEAD</literal> リビジョンはいま 480 となり、あなたは自分のプライベートなブランチから トランクに対するマージの用意ができています。しかし<xref linkend="svn.branchmerge.copychanges.bestprac"/>で議論したように既に以前マージした 変更を再びマージしたくはありません; 最後にマージしてからブランチ上に <quote>新しく起きた</quote>変更だけをマージしたいのです。問題はどうやって 新しい部分を見つけるかです。

note: Tag: para
en: The first step is to run <command>svn log</command> on the trunk, and look for a log message about the last time you merged from the branch:
ja: 最初のステップはトランク上で<command>svn log</command>を 実行し最後にブランチからマージしたときのログメッセージを見ます:

note: Tag: para
en: Aha! Since all branch-changes that happened between revisions 341 and 405 were previously merged to the trunk as revision 406, you now know that you want to merge only the branch changes after that&mdash;by comparing revisions 406 and <literal>HEAD</literal>.
ja: ああ、なるほど。341 と 405 の間のリビジョンに起きたすべてのブランチ上での 変更はリビジョン 406 として既にトランクにマージされているので、それ以降にブランチ上で起きた 変更のみをマージすれば良いことがわかります&mdash; つまり、リビジョン 406 から <literal>HEAD</literal> までです。

note: Tag: screen
en: $ cd calc/trunk
    $ svn update
    At revision 480.
    
    # We notice that HEAD is currently 480, so we use it to do the merge:
    
    $ svn merge -r 406:480 http://svn.example.com/repos/calc/branches/my-calc-branch
    U   integer.c
    U   button.c
    U   Makefile
    
    $ svn commit -m "Merged my-calc-branch changes r406:480 into the trunk."
    Sending        integer.c
    Sending        button.c
    Sending        Makefile
    Transmitting file data ...
    Committed revision 481.
ja: $ cd calc/trunk
    $ svn update
    At revision 480.
    
    # 現在の HEAD が 480 であることがわかったので、以下のようにマージすれ
    # ばよいことになります
    
    $ svn merge -r 406:480 http://svn.example.com/repos/calc/branches/my-calc-branch
    U   integer.c
    U   button.c
    U   Makefile
     
    $ svn commit -m "Merged my-calc-branch changes r406:480 into the trunk."
    Sending        integer.c
    Sending        button.c
    Sending        Makefile
    Transmitting file data ...
    Committed revision 481.

note: Tag: para
en: Now the trunk contains the complete second wave of changes made to the branch. At this point, you can either delete your branch (we'll discuss this later on), or continue working on your branch and repeat this procedure for subsequent merges.
ja: これでトランクはブランチに起きた変更の第二波全体を含むことになりました。 この時点でブランチを削除する(これについては後で議論します)ことも、 ブランチ上で引き続き作業し、以降のマージについて上記の手続きを繰り返す こともできます。

note: Tag: title
en: Undoing Changes
ja: 変更の取り消し

note: Tag: title
en: Subversion and Changesets
ja: Subversion とチェンジセット

note: Tag: para
en: Everyone seems to have a slightly different definition of <quote>changeset</quote>, or at least a different expectation of what it means for a version control system to have <quote>changeset features</quote>. For our purpose, let's say that a changeset is just a collection of changes with a unique name. The changes might include textual edits to file contents, modifications to tree structure, or tweaks to metadata. In more common speak, a changeset is just a patch with a name you can refer to.
ja: <quote>チェンジセット</quote>の定義は人によって少しずつ違うか、 少なくともバージョン管理システムが<quote>チェンジセットの機能</quote> を持っているというときに期待するものは異なっています。ここでは チェンジセットは一意の名前がついた変更点の集まりであるとしておきましょう。 この変更はファイル内容の編集、ツリー構造の変形、メタデータの修正などが 含まれています。もっと普通の言い方をすると、チェンジセットとは参照できる ような名前がついたパッチのことです。

note: Tag: para
en: Keep in mind that rolling back a change like this is just like any other <command>svn merge</command> operation, so you should use <command>svn status</command> and <command>svn diff</command> to confirm that your work is in the state you want it to be in, and then use <command>svn commit</command> to send the final version to the repository. After committing, this particular changeset is no longer reflected in the <literal>HEAD</literal> revision.
ja: このような変更の取り消しは、普通の<command>svn merge</command> の操作にすぎないので、作業コピーが望む状態になったかどうかは <command>svn status</command> と<command>svn diff</command> を 使うことができ、その後<command>svn commit</command> でリポジトリに 最終的なバージョンを送ることができるのだ、ということを押さえておいて ください。コミット後はこの特別なチェンジセットはもはや <literal>HEAD</literal>リビジョンには反映されません。

note: Tag: para
en: Again, you may be thinking: well, that really didn't undo the commit, did it? The change still exists in revision 303. If somebody checks out a version of the <filename>calc</filename> project between revisions 303 and 349, they'll still see the bad change, right?
ja: こう思うかも知れません: とすると、それは「取り消し」じゃない じゃないか。変更はまだリビジョン303に存在しているのでは、と。 もし誰かが<filename>calc</filename> プロジェクトのリビジョン303 と 349の間のバージョンをチェックアウトしたとしたら、間違った 変更を受け取るのではないか、違うか、と。

note: Tag: para
en: Yes, that's true. When we talk about <quote>removing</quote> a change, we're really talking about removing it from <literal>HEAD</literal>. The original change still exists in the repository's history. For most situations, this is good enough. Most people are only interested in tracking the <literal>HEAD</literal> of a project anyway. There are special cases, however, where you really might want to destroy all evidence of the commit. (Perhaps somebody accidentally committed a confidential document.) This isn't so easy, it turns out, because Subversion was deliberately designed to never lose information. Revisions are immutable trees which build upon one another. Removing a revision from history would cause a domino effect, creating chaos in all subsequent revisions and possibly invalidating all working copies.
ja: おっしゃる通り。私たちが、変更の<quote>取り消し</quote>について語るとき、 本当は<literal>HEAD</literal>から取り除くことを言っています。もともとの変更は リポジトリの履歴に依然として残っています。ほとんどの状況では これで十分です。とにかくほとんどの人たちはプロジェクトの <literal>HEAD</literal>を追いかける ことだけに興味があるからです。しかし、コミットに関するすべての 情報を削除したいという例外的な状況もあるでしょう。(多分、誰かが 極秘のドキュメントをコミットしてしまった、など) これはそんなに やさしいことではありません。Subversionは意図的に決して情報が 失われないように設計されているからです。履歴からのリビジョンの 削除は、連鎖的な影響を与え、すべての後続リビジョンと、多分 すべての作業コピーに混乱を起こします。

note: Tag: title
en: Resurrecting Deleted Items
ja: 削除されたアイテムの復活

note: Tag: para
en: The great thing about version control systems is that information is never lost. Even when you delete a file or directory, it may be gone from the <literal>HEAD</literal> revision, but the object still exists in earlier revisions. One of the most common questions new users ask is, <quote>How do I get my old file or directory back?</quote>.
ja: バージョン管理システムの偉大なところは情報が決して失われないという ところです。ファイルやディレクトリを削除した場合でもそれは <literal>HEAD</literal> リビジョン から消えただけであり、以前のリビジョン中には依然として存在し続けます。 新規ユーザからの一番よくある質問の一つは: <quote>どうやって古いファイルや ディレクトリを戻せば良いのですか?</quote> というものです。

note: Tag: para
en: In the example, we're assuming that you're looking for a deleted file <filename>real.c</filename>. By looking through the logs of a parent directory, you've spotted that this file was deleted in revision 808. Therefore, the last version of the file to exist was in the revision right before that. Conclusion: you want to resurrect the path <filename>/calc/trunk/real.c</filename> from revision 807.
ja: 例では削除してしまったファイル <filename>real.c</filename>を探している とします。親ディレクトリのログを見ることでこのファイルはリビジョン 808 で削除されたことを突き止めました。それでこのファイルが存在していた 最後のバージョンはそのリビジョンの直前であることになります。結論: リビジョン 807 から <filename>/calc/trunk/real.c</filename>のパスを 復活させれば良いことになります。

note: Tag: para
en: That was the hard part&mdash;the research. Now that you know what you want to restore, you have two different choices.
ja: これが面倒な部分です &mdash; つまりファイルを見つける作業です。 これで復元したいものが何であるか突き止めました。後は二つの方法が あります。

note: Tag: para
en: One option is to use <command>svn merge</command> to apply revision 808 <quote>in reverse</quote>. (We've already discussed how to undo changes, see <xref linkend="svn.branchmerge.commonuses.undo"/>.) This would have the effect of re-adding <filename>real.c</filename> as a local modification. The file would be scheduled for addition, and after a commit, the file would again exist in <literal>HEAD</literal>.
ja: 最初のやり方はリビジョン 808 を <quote>逆向きに</quote> 適用するために <command>svn merge</command>を利用することです。(変更の取り消し の仕方については既に議論しました。 <xref linkend="svn.branchmerge.commonuses.undo"/> を参照してください。) これはローカルな変更として<filename>real.c</filename> をもう一度追加する効果があります。ファイルは追加予告され、コミット後には <literal>HEAD</literal> 上に再び存在するようになります。

note: Tag: para
en: In this particular example, however, this is probably not the best strategy. Reverse-applying revision 808 would not only schedule <filename>real.c</filename> for addition, but the log message indicates that it would also undo certain changes to <filename>integer.c</filename>, which you don't want. Certainly, you could reverse-merge revision 808 and then <command>svn revert</command> the local modifications to <filename>integer.c</filename>, but this technique doesn't scale well. What if there were 90 files changed in revision 808?
ja: しかしこの例は多分最善の方法ではないでしょう。リビジョン 808 の逆向き の適用は<filename>real.c</filename>の追加予告だけではなく、ログメッセージ が示すように、今回必要としない<filename>integer.c</filename>への変更点 も取り消してしまいます。確かにリビジョン 808 を逆向きにマージした後 <filename>integer.c</filename>のローカル変更を <command>svn revert</command> することもできますが、この技法はファイルが多くなるとうまくスケールしません。 リビジョン 808 で 90 個のファイルが変更されていたとしたらどうなりますか?

note: Tag: para
en: A second, more targeted strategy is not to use <command>svn merge</command> at all, but rather the <command>svn copy</command> command. Simply copy the exact revision and path <quote>coordinate pair</quote> from the repository to your working copy:
ja: もっと洗練された二番目の方法は<command>svn merge</command>は利用せず、 そのかわりに<command>svn copy</command>コマンドを使います。正確な リビジョンとパスの <quote>座標の組</quote> を指定してリポジトリから自分の作業コピーに 単にコピーするだけです:

note: Tag: para
en: The plus sign in the status output indicates that the item isn't merely scheduled for addition, but scheduled for addition <quote>with history</quote>. Subversion remembers where it was copied from. In the future, running <command>svn log</command> on this file will traverse back through the file's resurrection and through all the history it had prior to revision 807. In other words, this new <filename>real.c</filename> isn't really new; it's a direct descendant of the original, deleted file.
ja: ステータス表示中のプラス記号はそのアイテムは単に追加予告されただけではなく <quote>履歴と共に</quote> 追加予告されたことを示しています。Subversion はどこからそれが コピーされたかを記憶しています。今後このファイル上に <command>svn log</command>を実行するとファイルの復活についてと、リビジョン 807 以前のすべての履歴をたどることができます。言いかえるとこの新しい <filename>real.c</filename>は本当に新しいわけではありません;それは 削除されたもとのファイルの直接の子孫になっています。

note: Tag: para
en: Although our example shows us resurrecting a file, note that these same techniques work just as well for resurrecting deleted directories.
ja: 私たちの例はファイルの復活でしたが、同じ技法が削除されたディレクトリ の復活についても利用できることに注意してください。

note: Tag: title
en: Common Branching Patterns
ja: ブランチの作り方

note: Tag: para
en: Version control is most often used for software development, so here's a quick peek at two of the most common branching/merging patterns used by teams of programmers. If you're not using Subversion for software development, feel free to skip this section. If you're a software developer using version control for the first time, pay close attention, as these patterns are often considered best practices by experienced folk. These processes aren't specific to Subversion; they're applicable to any version control system. Still, it may help to see them described in Subversion terms.
ja: バージョン管理システムはソフトウェア開発で一番よく使われるので、ここで 何かの開発チームによって利用される典型的なブランチ化/マージのパターン をちょっと見てみましょう。Subversion をソフトウェア開発に使うのでなけ ればこの節は読み飛ばしてもかまいません。ソフトウェア開発にバージョン 管理システムを使うのが初めてなのであれば、よく読んでください。 ここでのパターンは経験を積んだ多くの開発者によって最良の方法だと考えられて いるからです。このようなやり方は Subversion に限った話ではありません; どのようなバージョン管理システムにでも応用できる考え方です。また同時に 他のシステムのユーザに対しては Subversion ではどんな言葉を使ってこの標 準的なやり方を表現するかを理解する手がかりになるでしょう。

note: Tag: title
en: Release Branches
ja: リリースブランチ

note: Tag: para
en: Most software has a typical lifecycle: code, test, release, repeat. There are two problems with this process. First, developers need to keep writing new features while quality-assurance teams take time to test supposedly-stable versions of the software. New work cannot halt while the software is tested. Second, the team almost always needs to support older, released versions of software; if a bug is discovered in the latest code, it most likely exists in released versions as well, and customers will want to get that bugfix without having to wait for a major new release.
ja: ほとんどのソフトウェアは典型的な作業サイクルがあります: コーディング、 テスト、リリース、この繰り返しです。このようなやり方には二つの問題が あります。まず開発者は新しい機能を追加し続けなくてはならない一方で 品質保証チームはそのソフトウェアの安定版だと考えられるバージョンを テストするのに時間をついやさなくてはなりません。テスト途中だからといっ て新しい機能追加を中断することはできません。次に開発チームはほとんど の場合、すでにリリースされた古いバージョンのソフトウェアを保守しなくては なりません; もし最新のコードにバグが見つかった場合、すでにリリースしている バージョンにも同じバグが潜んでいる可能性は高く、利用者は次のリリースを 待たずにこのバグを修正して欲しいと望んでいることでしょう。

note: Tag: para
en: Here's where version control can help. The typical procedure looks like this:
ja: バージョン管理システムの出番です。典型的なやり方は以下のようなものです:

note: Tag: para
en: <emphasis>Developers commit all new work to the trunk.</emphasis> Day-to-day changes are committed to <filename>/trunk</filename>: new features, bugfixes, and so on.
ja: <emphasis> 開発者は新規開発部分をトランクにコミットします。 </emphasis> 日々の変更点は<filename>/trunk</filename>にコミットされます: 新しい機 バグ修正、その他もろもろです。

note: Tag: para
en: <emphasis>The trunk is copied to a <quote>release</quote> branch.</emphasis> When the team thinks the software is ready for release (say, a 1.0 release), then <filename>/trunk</filename> might be copied to <filename>/branches/1.0</filename>.
ja: <emphasis> トランクの内容は<quote>リリース</quote>ブランチにコピーされます。 </emphasis> あるチームが、そのソフトウェアがリリースできる状態になったと考えた 時点で(つまり、1.0 のリリースのような場合)、<filename>/trunk</filename> は<filename>/branches/1.0</filename>のような名前でコピーされる ことになります。

note: Tag: para
en: <emphasis>Teams continue to work in parallel.</emphasis> One team begins rigorous testing of the release branch, while another team continues new work (say, for version 2.0) on <filename>/trunk</filename>. If bugs are discovered in either location, fixes are ported back and forth as necessary. At some point, however, even that process stops. The branch is <quote>frozen</quote> for final testing right before a release.
ja: <emphasis> これと並行して、他のチームが作業を続けます。 </emphasis> あるチームがリリースブランチの内容を徹底的なテストを開始する一方で 他のチームは新規開発分(つまり、バージョン 2.0 に向けた作業)を <filename>/trunk</filename>上で継続して行います。どちらかの場所で バグが見つかれば、必要に応じてその修正がお互いの間を行き来します。 しかしこの作業もやがては終わります。このブランチはリリース直前の 最終的なテストに向けて<quote>凍結</quote>されます。

note: Tag: para
en: <emphasis>The branch is tagged and released.</emphasis> When testing is complete, <filename>/branches/1.0</filename> is copied to <filename>/tags/1.0.0</filename> as a reference snapshot. The tag is packaged and released to customers.
ja: <emphasis>ブランチはタグづけされ、リリースされます。 </emphasis> テストが完了したら<filename>/branches/1.0</filename>は <filename>/tags/1.0.0</filename>にコピーされ、これが参照用のスナップ ショットになります。このタグの内容はパッケージ化され、利用者に対して リリースされます。

note: Tag: para
en: <emphasis>The branch is maintained over time.</emphasis> While work continues on <filename>/trunk</filename> for version 2.0, bugfixes continue to be ported from <filename>/trunk</filename> to <filename>/branches/1.0</filename>. When enough bugfixes have accumulated, management may decide to do a 1.0.1 release: <filename>/branches/1.0</filename> is copied to <filename>/tags/1.0.1</filename>, and the tag is packaged and released.
ja: <emphasis>ブランチはその後も保守されます。</emphasis> バージョン 2.0に向けた作業が<filename>/trunk</filename>上で進む一方、 バグ修正個所については<filename>/trunk</filename>から <filename>/branches/1.0</filename>に引き続き反映されます。 十分なバグ修正が反映されたら、管理者は 1.0.1 をリリースする決断をする かも知れません: <filename>/branches/1.0</filename>は <filename>/tags/1.0.1</filename>にコピーされ、このタグはパッケージ 化されてからリリースされます。

note: Tag: para
en: This entire process repeats as the software matures: when the 2.0 work is complete, a new 2.0 release branch is created, tested, tagged, and eventually released. After some years, the repository ends up with a number of release branches in <quote>maintenance</quote> mode, and a number of tags representing final shipped versions.
ja: このような作業の流れを繰り返すことでソフトウェアは安定していきます: 2.0 の開発が完了したら新しい 2.0 のリリースブランチが作られ、テスト され、タグがつけられ、最終的にリリースされることになります。 何年かしてリポジトリは<quote>保守対象</quote>の状態になったいくつかの リリースブランチと最終的にリリースされたバージョンを示すタグの集まり になるでしょう。

note: Tag: title
en: Feature Branches
ja: (特定機能の)開発用ブランチ

note: Tag: para
en: A <firstterm>feature branch</firstterm> is the sort of branch that's been the dominant example in this chapter, the one you've been working on while Sally continues to work on <filename>/trunk</filename>. It's a temporary branch created to work on a complex change without interfering with the stability of <filename>/trunk</filename>. Unlike release branches (which may need to be supported forever), feature branches are born, used for a while, merged back to the trunk, then ultimately deleted. They have a finite span of usefulness.
ja: <firstterm>開発用ブランチ(feature branch)</firstterm> はこの章での 例として中心的な役割を果たしてきたようなタイプのブランチで、その ブランチ上であなたが作業をするのと同時に並行してSally は <filename>/trunk</filename>上で作業を継続することができるような ものでした。それは一時的なブランチで、安定している <filename>/trunk</filename>に影響を与えることなく複雑な変更をする ためのものです。リリース用ブランチ(これはずっと保守しつづけなければ ならないかも知れません)とは違って、開発用ブランチは作成されたあと ある程度の期間利用され、変更部分がトランクに反映された後で完全に 削除されてしまいます。利用されるのは、ある決まった期間の中だけです。

note: Tag: para
en: Again, project policies vary widely concerning exactly when it's appropriate to create a feature branch. Some projects never use feature branches at all: commits to <filename>/trunk</filename> are a free-for-all. The advantage to this system is that it's simple&mdash;nobody needs to learn about branching or merging. The disadvantage is that the trunk code is often unstable or unusable. Other projects use branches to an extreme: no change is <emphasis>ever</emphasis> committed to the trunk directly. Even the most trivial changes are created on a short-lived branch, carefully reviewed and merged to the trunk. Then the branch is deleted. This system guarantees an exceptionally stable and usable trunk at all times, but at the cost of tremendous process overhead.
ja: プロジェクトの考え方によって、開発用ブランチをいつ作るのが適切である かにはかなりの幅があります。プロジェクトによっては開発用ブランチを 全く使いません: <filename>/trunk</filename>に対するコミットは 全員に許されています。このやり方の長所はその単純さです&mdash;誰も ブランチ化やマージについて理解する必要がありません。欠点はこの方法 だとトランクのソースコードが不安定になったりまったく利用できなく なったりしやすいことです。逆に別のプロジェクトではブランチを極端な 形で使います: <emphasis>どんな変更も</emphasis>トランクに対して直接 コミットすることは認められていません。まったくささいな変更に対しても 短い生存期間をもつブランチを作り、それを注意深く検討し、 トランクに反映させます。それから、そのブランチを削除します。この方法は トランクを常に非常に安定して利用できる状態に置くことができますが それには無視できない処理効率の低下が伴います。

note: Tag: para
en: Most projects take a middle-of-the-road approach. They commonly insist that <filename>/trunk</filename> compile and pass regression tests at all times. A feature branch is only required when a change requires a large number of destabilizing commits. A good rule of thumb is to ask this question: if the developer worked for days in isolation and then committed the large change all at once (so that <filename>/trunk</filename> were never destabilized), would it be too large a change to review? If the answer to that question is <quote>yes</quote>, then the change should be developed on a feature branch. As the developer commits incremental changes to the branch, they can be easily reviewed by peers.
ja: ほとんどのプロジェクトではこの中間のやり方をとります。普通は <filename>/trunk</filename>は常にコンパイル可能な状態であり、 一度フィックスしたバグが元に戻っていないことを保証するためのテスト もクリアした状態にあることを要求します。ある変更をするのに プログラムを不安定にするようなコミットを何度も必要とする場合に だけ開発ブランチが作られます。基本的な方針としては次のようなことを 考えてみることです: もし開発者が孤立した状態で何日も作業した後で 一度に変更点全体をコミットしたとしたら(<filename>/trunk</filename>が 不安定にならないようにするためにそうするのでしょうが)、その変更 内容が正しいかどうかを検討するには大きすぎませんか? もし答えが <quote>イエス</quote>なら、その変更は開発用ブランチでやるべきで しょう。開発者はブランチに対して変更点を少しずつコミットするので 他の人たちはそれぞれの部分について簡単に内容を検証することができ ます。

note: Tag: para
en: Finally, there's the issue of how to best keep a feature branch in <quote>sync</quote> with the trunk as work progresses. As we mentioned earlier, there's a great risk to working on a branch for weeks or months; trunk changes may continue to pour in, to the point where the two lines of development differ so greatly that it may become a nightmare trying to merge the branch back to the trunk.
ja: 最後に、開発用ブランチでの作業が進むにつれて、どうやってそれを トランクの内容に<quote>同期</quote>させるのがよいかについて 考えてみます。すでに注意したようにブランチ上で数週間あるいは数ヶ月 ものあいだ作業しつづけるのには大きなリスクが伴います; トランクへの 変更はその間次々と発生し、ついには二つの開発ラインはあまりにもかけ離れて しまい、ブランチの変更内容をトランクにマージによって戻すのは全く 非現実的な話になってしまうかも知れないのです。

note: Tag: para
en: This situation is best avoided by regularly merging trunk changes to the branch. Make up a policy: once a week, merge the last week's worth of trunk changes to the branch. Take care when doing this; the merging needs to be hand-tracked to avoid the problem of repeated merges (as described in <xref linkend="svn.branchmerge.copychanges.bestprac.track"/>). You'll need to write careful log messages detailing exactly which revision ranges have been merged already (as demonstrated in <xref linkend="svn.branchmerge.commonuses.wholebr"/>). It may sound intimidating, but it's actually pretty easy to do.
ja: この状況を避けるためにはトランクの内容を定期的にブランチにマージする ことです。次のようなルールを決めておきましょう: 一週間に一度、 先週トランク上におきた変更をブランチにマージすること。これは注意して 実行する必要があります; マージは手作業で実行し、繰り返してマージする のを避ける必要があります(これについては <xref linkend="svn.branchmerge.copychanges.bestprac.track"/>で説明しました)。ログメッセージ を書く時には注意して、どの範囲のリビジョンが既にマージされているか を正確に控えておきましょう(これは<xref linkend="svn.branchmerge.commonuses.wholebr"/> でやってみせました)。大変な作業に思えるかも知れませんが、実際には 非常に簡単なことです。

note: Tag: para
en: At some point, you'll be ready to merge the <quote>synchronized</quote> feature branch back to the trunk. To do this, begin by doing a final merge of the latest trunk changes to the branch. When that's done, the latest versions of branch and trunk will be absolutely identical except for your branch changes. So in this special case, you would merge by comparing the branch with the trunk:
ja: あるところまで作業が進んだら、開発用ブランチの内容をトランクに <quote>同期</quote>させるためのマージの準被ｳ器ｺ整います。これには まず、最新のトランクの変更部分をブランチに取り込む最後のマージ 処理を実行することで始めます。この処理の後では、ブランチ上の最後のリビ ジョンとトランク上の最後のリビジョンは、ブランチでの変更部分を のぞけば、完全に同じ状態になります。このような特定の状況下では ブランチとトランクの内容を比較することによってマージすることが できるはずです:

note: Tag: screen
en: $ cd trunk-working-copy
    
    $ svn update
    At revision 1910.
    
    $ svn merge http://svn.example.com/repos/calc/trunk@1910 \
                http://svn.example.com/repos/calc/branches/mybranch@1910
    U  real.c
    U  integer.c
    A  newdirectory
    A  newdirectory/newfile
    &hellip;
ja: $ cd trunk-working-copy
    
    $ svn update
    At revision 1910.
    
    $ svn merge http://svn.example.com/repos/calc/trunk@1910 ¥
                http://svn.example.com/repos/calc/branches/mybranch@1910
    U  real.c
    U  integer.c
    A  newdirectory
    A  newdirectory/newfile
    &hellip;

note: Tag: para
en: By comparing the <literal>HEAD</literal> revision of the trunk with the <literal>HEAD</literal> revision of the branch, you're defining a delta that describes only the changes you made to the branch; both lines of development already have all of the trunk changes.
ja: トランクの<literal>HEAD</literal>リビジョンとブランチの <literal>HEAD</literal>リビジョンを比較することで、ブランチにだけ 加えた修正点を含む差分を作ることができます; 両方の開発ラインとも トランクに起きた修正についてはすでに取り込んでいるからです。

note: Tag: para
en: Another way of thinking about this pattern is that your weekly sync of trunk to branch is analogous to running <command>svn update</command> in a working copy, while the final merge step is analogous to running <command>svn commit</command> from a working copy. After all, what else <emphasis>is</emphasis> a working copy but a very shallow private branch? It's a branch that's only capable of storing one change at a time.
ja: このような作業パターンは、自分のブランチに対して 毎週トランクを同期させる処理は、作業コピーに対して<command>svn update</command> を実行するのとよく似ていて、最後のマージ処理に ついては作業コピーから<command>svn commit</command>を実行するのに よく似ていると考えることができます。結局、作業コピーと、ちょっと作った プライベートなブランチと、他に何が違うと言うのでしょう? 作業コピー とは、一度に一つの変更しか保存できないような単なるブランチにすぎ ません。

note: Tag: para
en: After <quote>switching</quote> to the branch, your working copy is no different than what you would get from doing a fresh checkout of the directory. And it's usually more efficient to use this command, because often branches only differ by a small degree. The server sends only the minimal set of changes necessary to make your working copy reflect the branch directory.
ja: ブランチに<quote>スイッチ</quote>したあとでは、作業コピーの内容はそのディレクトリ を新しくチェックアウトした場合とまったく同じものになります。そして 普通このコマンドを使うほうがより効率的です。というのは、たいてい ブランチはほんの少し内容が違うだけです。サーバはそのブランチディレクトリ を反映させるために作業コピーにしなくてはならない最小限の変更だけを 送信すれば済むのです。

note: Tag: para
en: Of course, most projects are more complicated than our <filename>calc</filename> example, containing multiple subdirectories. Subversion users often follow a specific algorithm when using branches:
ja: もちろん、ほとんどのプロジェクトは<filename>calc</filename>よりは もっと複雑で、複数のサブディレクトリを含んでいます。Subversionユーザは ブランチを利用するときにはよく、特定のやり方をします。:

note: Tag: para
en: Copy the project's entire <quote>trunk</quote> to a new branch directory.
ja: プロジェクトの<quote>幹(trunk)</quote>全体を新しいブランチディレクトリ にコピーする。

note: Tag: para
en: Switch only <emphasis>part</emphasis> of the trunk working copy to mirror the branch.
ja: 幹(trunk)の作業コピーの<emphasis>一部</emphasis>のみを ブランチにミラーする。

note: Tag: para
en: In other words, if a user knows that the branch-work only needs to happen on a specific subdirectory, they use <command>svn switch</command> to move only that subdirectory to the branch. (Or sometimes users will switch just a single working file to the branch!) That way, they can continue to receive normal <quote>trunk</quote> updates to most of their working copy, but the switched portions will remain immune (unless someone commits a change to their branch). This feature adds a whole new dimension to the concept of a <quote>mixed working copy</quote>&mdash;not only can working copies contain a mixture of working revisions, but a mixture of repository locations as well.
ja: 言い換えると、ユーザが特定のサブディレクトリ上でだけブランチの作業が起きる ことを知っている場合には<command>svn switch</command>を使ってブランチに そのサブディレクトリのみを移動します。(あるいは、たった一つの作業ファイル だけをブランチに switch することさえあります!) その方法では、作業コピー のほとんどすべての更新を普通の<quote>幹(trunk)</quote>から従来どおり受け取ることが できますが、切り替えた部分だけは変更されることなく残ります(もしブランチ に対して誰かが変更点をコミットしさえしなければ)。この機能は <quote>混合作業コピー</quote>という概念にまったく新しい次元を付け加える ことになります&mdash;作業コピーは作業リビジョンの混合を含むことができる だけではなく、リポジトリ位置の混合も含むことができます。

note: Tag: para
en: If your working copy contains a number of switched subtrees from different repository locations, it continues to function as normal. When you update, you'll receive patches to each subtree as appropriate. When you commit, your local changes will still be applied as a single, atomic change to the repository.
ja: もし作業コピーが異なるリポジトリ位置からのスイッチされたサブツリー をいくつか含むなら、それは普通に機能し続けます。更新すると、 それぞれのサブツリーのパッチを適切に受け取るでしょう。コミットすると ローカル修正は一つの不可分の変更をリポジトリに適用するでしょう。

note: Tag: title
en: Switches and Updates
ja: スイッチと更新

note: Tag: para
en: Have you noticed that the output of <command>svn switch</command> and <command>svn update</command> look the same? The <literal>switch</literal> command is actually a superset of the update command.
ja: <command>svn switch</command> と <command>svn update</command> の 出力が同じなのに気がつきましたか? <literal>switch</literal>コマンドは実際にはupdate コマンドのスーパーセットになっています。

note: Tag: para
en: When you run <command>svn update</command>, you're asking the repository to compare two trees. The repository does so, and then sends a description of the differences back to the client. The only difference between <command>svn switch</command> and <command>svn update</command> is that the <literal>update</literal> command always compares two identical paths.
ja: <command>svn update</command>を実行するとき、それはリポジトリに対して 二つのツリーを比較するように要求します。リポジトリはその比較を実行 し、クライアントに差分の内容を送信します。 <command>svn switch</command> と <command>svn update</command> の 唯一の違いは <literal>update</literal> コマンドは常に二つの同じパスを比較するという ことです。

note: Tag: para
en: That is, if your working copy is a mirror of <filename>/calc/trunk</filename>, then <command>svn update</command> will automatically compare your working copy of <filename>/calc/trunk</filename> to <filename>/calc/trunk</filename> in the <literal>HEAD</literal> revision. If you're switching your working copy to a branch, then <command>svn switch</command> will compare your working copy of <filename>/calc/trunk</filename> to some <emphasis>other</emphasis> branch-directory in the <literal>HEAD</literal> revision.
ja: つまり、もし作業コピーが <filename>/calc/trunk</filename>のコピーなら <command>svn update</command> は自動的に<filename>/calc/trunk</filename> の作業コピーを <literal>HEAD</literal>リビジョンの<filename>/calc/trunk</filename> と比較 します。もし作業コピーをブランチに移すと、 <command>svn switch</command> は<filename>/calc/trunk</filename> の作業コピーを何か<literal>HEAD</literal>リビジョンの<emphasis>他の</emphasis> ブランチディレクトリと比較します。

note: Tag: para
en: In other words, an update moves your working copy through time. A switch moves your working copy through time <emphasis>and</emphasis> space.
ja: 言い換えると、更新は時間の方向に作業コピーを動かします。 switch は作業コピーを時間<emphasis>と</emphasis> 空間の 両方の方向に動かします。

note: Tag: para
en: Because <command>svn switch</command> is essentially a variant of <command>svn update</command>, it shares the same behaviors; any local modifications in your working copy are preserved when new data arrives from the repository. This allows you to perform all sorts of clever tricks.
ja: <command>svn switch</command> は本質的には<command>svn update</command> の変種なので、同じ動作を共有します。作業コピー中のどのようなローカルの 変更もリポジトリから新しいデータが届くときに保存されます。これで あらゆる利口な小技がきくようになります。

note: Tag: para
en: For example, suppose you have a working copy of <filename>/calc/trunk</filename> and make a number of changes to it. Then you suddenly realize that you meant to make the changes to a branch instead. No problem! When you <command>svn switch</command> your working copy to the branch, the local changes will remain. You can then test and commit them to the branch.
ja: たとえば<filename>/calc/trunk</filename> の作業コピーがありそれにいくつか 変更を加えたとします。それから突然、本当はブランチにやる変更だったことに 気づきます。問題ありません。作業コピーを<command>svn switch</command> でブランチにスイッチしても、ローカルの変更はそのまま残ります。で、 それをブランチに対してテストし、コミットすることができます。

note: Tag: title
en: Tags
ja: タグ

note: Tag: para
en: Another common version control concept is a <firstterm>tag</firstterm>. A tag is just a <quote>snapshot</quote> of a project in time. In Subversion, this idea already seems to be everywhere. Each repository revision is exactly that&mdash;a snapshot of the filesystem after each commit.
ja: 別のバージョン管理の概念に、<firstterm>タグ</firstterm>があります。 タグはある時点でのプロジェクトの<quote>スナップショット</quote>です。Subversion ではこのアイディアは既にさまざまな場所にあるように見えます。それぞれ のリポジトリリビジョンはまさにそれです&mdash;つまり、それはコミット直後の ファイルシステムのスナップショットです。

note: Tag: para
en: However, people often want to give more human-friendly names to tags, like <literal>release-1.0</literal>. And they want to make snapshots of smaller subdirectories of the filesystem. After all, it's not so easy to remember that release-1.0 of a piece of software is a particular subdirectory of revision 4822.
ja: しかし、人はしばしばタグに対して人間になじみのある名前を付けたいと 思うものです。たとえば、<quote>release-1.0</quote>のような。また、ファイルシステム のもっと小さなサブディレクトリのスナップショットがほしいこともあります。 結局、あるソフトの一部のrelease-1.0 がリビジョン4822の特定のサブディレクトリ であることを思い出すのは簡単ではありません。

note: Tag: title
en: Creating a Simple Tag
ja: 簡単なタグの作成

note: Tag: para
en: Once again, <command>svn copy</command> comes to the rescue. If you want to create a snapshot of <filename>/calc/trunk</filename> exactly as it looks in the <literal>HEAD</literal> revision, then make a copy of it:
ja: もう一度、<command>svn copy</command> の助けを借ります。 もし<literal>HEAD</literal>リビジョンの<filename>/calc/trunk</filename> のスナップ ショットを作りたいときには、そのコピーをとればいいのでした:

note: Tag: screen
en: $ svn copy http://svn.example.com/repos/calc/trunk \
               http://svn.example.com/repos/calc/tags/release-1.0 \
          -m "Tagging the 1.0 release of the 'calc' project."
    
    Committed revision 351.
ja: $ svn copy http://svn.example.com/repos/calc/trunk ¥
               http://svn.example.com/repos/calc/tags/release-1.0 ¥
          -m "Tagging the 1.0 release of the 'calc' project."
    
    Committed revision 351.

note: Tag: para
en: But wait a moment: isn't this tag-creation procedure the same procedure we used to create a branch? Yes, in fact, it is. In Subversion, there's no difference between a tag and a branch. Both are just ordinary directories that are created by copying. Just as with branches, the only reason a copied directory is a <quote>tag</quote> is because <emphasis>humans</emphasis> have decided to treat it that way: as long as nobody ever commits to the directory, it forever remains a snapshot. If people start committing to it, it becomes a branch.
ja: でもちょっと待ってください: このタグ作成の手続きはブランチを作る ために使ってきた手続きと同じじゃないの? 実はその通りです。 Subversion ではタグとブランチには違いはありません。両方とも コピーで作られた普通のディレクトリです。ちょうどブランチのように コピーされたディレクトリが<quote>タグ</quote>であるといわれるのは、単に <emphasis>人間が</emphasis>そうやって扱うことに決めたから、ただ それだけです。そのディレクトリに誰もコミットしない限り、それは 永遠にスナップショットとして残ります。もし誰かがそれにコミット し始めると、それはブランチになります。

note: Tag: para
en: If you are administering a repository, there are two approaches you can take to managing tags. The first approach is <quote>hands off</quote>: as a matter of project policy, decide where your tags will live, and make sure all users know how to treat the directories they copy in there. (That is, make sure they know not to commit to them.) The second approach is more paranoid: you can use one of the access-control scripts provided with Subversion to prevent anyone from doing anything but creating new copies in the tags-area (See <xref linkend="svn.serverconfig"/>.) The paranoid approach, however, isn't usually necessary. If a user accidentally commits a change to a tag-directory, you can simply undo the change as discussed in the previous section. This is version control, after all.
ja: もしリポジトリを管理しているなら、タグを管理するには二通りの 方法があります。最初のアプローチは、<quote>ユーザ任せ</quote>です。 プロジェクトポリシーとして、あなたのタグを置く場所を決め、 すべてのユーザにそのディレクトリをコピーするときにはどうやって扱うか を知らせます。(つまり、みんながそこにコミットしないように約束します) 二番目のやり方はもっとガチガチです。Subversionが提供するアクセス 制御スクリプトのどれかを使って、タグ領域には新しいコピーを 作ることだけができて、それ以外の操作を禁止します。 (<xref linkend="svn.serverconfig"/>を参照してください。) ガチガチ方式は、普通は不要です。もしユーザが間違ってタグディレクトリ に自分の変更をコミットしてしまったら、前の章で説明した方法で その変更を取り消せばいいのですから。結局、Subversionはバージョン 管理システムなのです。

note: Tag: title
en: Creating a Complex Tag
ja: 複雑なタグの作成

note: Tag: para
en: Sometimes you may want your <quote>snapshot</quote> to be more complicated than a single directory at a single revision.
ja: ときどき、一つのリビジョンの一つのディレクトリよりも もっと複雑な<quote>スナップショット</quote>がほしいことがあります。

note: Tag: para
en: For example, pretend your project is much larger than our <filename>calc</filename> example: suppose it contains a number of subdirectories and many more files. In the course of your work, you may decide that you need to create a working copy that is designed to have specific features and bug fixes. You can accomplish this by selectively backdating files or directories to particular revisions (using <command>svn update -r</command> liberally), or by switching files and directories to particular branches (making use of <command>svn switch</command>). When you're done, your working copy is a hodgepodge of repository locations from different revisions. But after testing, you know it's the precise combination of data you need.
ja: たとえば、プロジェクトが私たちの<filename>calc</filename> よりも もっと大きいとします。たくさんのサブディレクトリともっとたくさん のファイルがあるとします。仕事の過程で、特定の機能とバグ修正を含んだ 作業コピーが必要になったと判断します。特定のリビジョンの 以前のファイルとディレクトリを選んで(<command>svn update -r</command> liberally を使って), これを作ることもできますし、 特定のブランチにファイルとディレクトリをスイッチすることによっても できます。 (<command>svn switch</command>を使う) これをやると、あなたと作業コピーは別々のリビジョンからなる別々の リポジトリ位置のつぎはぎになります。しかしテスト後、自分がまさに必要と している組み合わせであることがわかりました。

note: Tag: para
en: Now there is a new directory in the repository, <filename>/calc/tags/mytag</filename>, which is an exact snapshot of your working copy&mdash;mixed revisions, URLs, and all.
ja: これでリポジトリに新しいディレクトリができました。 <filename>/calc/tags/mytag</filename>です。これはあなたの作業コピー の正確なスナップショットです&mdash; 混合リビジョン、URLそして すべてです。

note: Tag: title
en: Branch Maintenance
ja: ブランチの管理

note: Tag: para
en: You may have noticed by now that Subversion is extremely flexible. Because it implements branches and tags with the same underlying mechanism (directory copies), and because branches and tags appear in normal filesystem space, many people find Subversion intimidating. It's almost <emphasis>too</emphasis> flexible. In this section, we'll offer some suggestions for arranging and managing your data over time.
ja: ここまでで、Subversionは非常に柔軟なシステムであることがおわかり いただけたかと思います。ディレクトリのコピーという同じ基本的な 仕組みの上にブランチもタグも実装しており、ブランチもタグも普通の ファイルシステムの空間の中にあるので、多くの人々はSubversionの 仕組みにびっくりします。それは<emphasis>柔軟すぎる</emphasis>くらい です。この節では時間経過と共にどのようにデータを配置し管理するのが 良いかについて、少し説明します。

note: Tag: title
en: Repository Layout
ja: リポジトリのレイアウト

note: Tag: para
en: There are some standard, recommended ways to organize a repository. Most people create a <filename>trunk</filename> directory to hold the <quote>main line</quote> of development, a <filename>branches</filename> directory to contain branch copies, and a <filename>tags</filename> directory to contain tag copies. If a repository holds only one project, then often people create these top-level directories:
ja: リポジトリの編成にはある程度、標準化された、おすすめの方法が あります。ほとんどの人々は<filename>trunk</filename>ディレクトリ に開発の<quote>主系</quote>、ブランチのコピーがある<filename>branches</filename> ディレクトリ、そしてタグのコピーがある<filename>tags</filename>ディレクトリ を入れます。リポジトリがただ一つのプロジェクトを含む場合には しばしば、この三つのディレクトリをリポジトリ最上位に作ります:

note: Tag: para
en: If a repository contains multiple projects, admins typically index their layout by project (see <xref linkend="svn.reposadmin.projects.chooselayout"/> to read more about <quote>project roots</quote>):
ja: リポジトリが複数プロジェクトを含む場合は、プロジェクトごとに レイアウトをインデックス化します (<quote>プロジェクトルート</quote>についての詳細は <xref linkend="svn.reposadmin.projects.chooselayout"/> を読んでください):

note: Tag: para
en: Of course, you're free to ignore these common layouts. You can create any sort of variation, whatever works best for you or your team. Remember that whatever you choose, it's not a permanent commitment. You can reorganize your repository at any time. Because branches and tags are ordinary directories, the <command>svn move</command> command can move or rename them however you wish. Switching from one layout to another is just a matter of issuing a series of server-side moves; if you don't like the way things are organized in the repository, just juggle the directories around.
ja: もちろん、この標準的なレイアウトを無視してもかまいません。 あなたと、チームが最も作業しやすいように、このレイアウトは どのように変化させてもかまいません。どれを選んでもそれは 永久に固定されたものではありません。いつでもリポジトリを 再編成することができます。ブランチとタグは普通のディレクトリ にすぎないので<command>svn move</command>コマンドを使えば 好きなように移動、名称変更ができます。あるレイアウトから別の レイアウトへの切り替えは単にサーバ側での何回かの移動の話になります。 もしリポジトリ中の編成に何か気に入らないところがあるなら、ディレクトリ に関連した小技を使ってください。

note: Tag: para
en: Remember, though, that while moving directories may be easy to do, you need to be considerate of your users as well. Your juggling can be disorienting to users with existing working copies. If a user has a working copy of a particular repository directory, your <command>svn move</command> operation might remove the path from the latest revision. When the user next runs <command>svn update</command>, she will be told that her working copy represents a path that no longer exists, and the user will be forced to <command>svn switch</command> to the new location.
ja: しかし、ディレクトリの移動は簡単ではありますが、ユーザのこともよく 考える必要があります。この変更は既にある各自の作業コピーの場所 を再配置します。もしユーザが特定のリポジトリのディレクトリの作業 コピーを持っている場合、あなたの <command>svn move</command>操作 は最新リビジョンのパスを削除してしまうかも知れません。ユーザが 次に<command>svn update</command>を実行すると、作業コピーは すでに存在しないパスを示しているとされ、新しい場所に移動する ために<command>svn switch</command>の実行を強要されてしまう でしょう。

note: Tag: title
en: Data Lifetimes
ja: データの寿命

note: Tag: para
en: Another nice feature of Subversion's model is that branches and tags can have finite lifetimes, just like any other versioned item. For example, suppose you eventually finish all your work on your personal branch of the <filename>calc</filename> project. After merging all of your changes back into <filename>/calc/trunk</filename>, there's no need for your private branch directory to stick around anymore:
ja: Subversionモデルの別の良い機能としては他のバージョン 管理されたアイテムと同様、ブランチとタグは有限の種ｴ幔ｽしか持たない ようにもできることです。たとえば<filename>calc</filename>プロジェクト の個人的なブランチ上ですべての作業が完了したとします。すべての 変更を、<filename>/calc/trunk</filename>にマージしたあとでは その個人的なブランチのディレクトリがまったく不要になります:

note: Tag: screen
en: $ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
                 -m "Removing obsolete branch of calc project."
    
    Committed revision 375.
ja: $ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch ¥
                 -m "Removing obsolete branch of calc project."
    
    Committed revision 375.

note: Tag: para
en: And now your branch is gone. Of course it's not really gone: the directory is simply missing from the <literal>HEAD</literal> revision, no longer distracting anyone. If you use <command>svn checkout</command>, <command>svn switch</command>, or <command>svn list</command> to examine an earlier revision, you'll still be able to see your old branch.
ja: これでブランチはなくなってしまいました。もちろん本当に削除された わけではありません: ディレクトリは単に <literal>HEAD</literal>リビジョンからなくなった だけで、誰もわずらわせることはなくなりました。 前のバージョンを調べるために<command>svn checkout</command>、 <command>svn switch</command>、あるいは <command>svn list</command> を使えば依然として古いブランチを見ることができます。

note: Tag: para
en: If browsing your deleted directory isn't enough, you can always bring it back. Resurrecting data is very easy in Subversion. If there's a deleted directory (or file) that you'd like to bring back into <literal>HEAD</literal>, simply use <command>svn copy -r</command> to copy it from the old revision:
ja: 削除したディレクトリを閲覧するだけでは不十分な場合は、いつでも 戻すこともできます。データの復活はSubversionではお手のものです。 <literal>HEAD</literal>に戻したい削除ディレクトリ(またはファイル)がある場合は、単に <command>svn copy -r</command> を使って古いリビジョンから コピーしてください:

note: Tag: screen
en: $ svn copy -r 374 http://svn.example.com/repos/calc/branches/my-calc-branch \
                      http://svn.example.com/repos/calc/branches/my-calc-branch
    
    Committed revision 376.
ja: $ svn copy -r 374 http://svn.example.com/repos/calc/branches/my-calc-branch ¥
                      http://svn.example.com/repos/calc/branches/my-calc-branch
    
    Committed revision 376.

note: Tag: para
en: In our example, your personal branch had a relatively short lifetime: you may have created it to fix a bug or implement a new feature. When your task is done, so is the branch. In software development, though, it's also common to have two <quote>main</quote> branches running side-by-side for very long periods. For example, suppose it's time to release a stable version of the <filename>calc</filename> project to the public, and you know it's going to take a couple of months to shake bugs out of the software. You don't want people to add new features to the project, but you don't want to tell all developers to stop programming either. So instead, you create a <quote>stable</quote> branch of the software that won't change much:
ja: 私たちの例では個人的なブランチは比較的短い生存時間を持ちます。バグを 直したり新しい機能を追加するのに利用したからです。作業が終われば、 ブランチの種ｴ幔ｽもそこで終わりです。しかし、開発内容によっては 非常に長い時間にわたって二つの<quote>主要な</quote>ブランチが並行して生きつづけることも あります。たとえば、安定版の<filename>calc</filename>プロジェクトを 公にリリースするときがやってきて、そのソフトのバグをとるのには 何ヶ月かかかるとします。リリースバージョンに新しい機能を追加させたくは ありませんが、すべてのメンバーに開発を中止するように言いたくもありま せん。そこでかわりに、あなたはそれほど大きな修正は発生しない <quote>安定版</quote>のブランチを作ります:

note: Tag: screen
en: $ svn copy http://svn.example.com/repos/calc/trunk \
             http://svn.example.com/repos/calc/branches/stable-1.0 \
             -m "Creating stable branch of calc project."
    
    Committed revision 377.
ja: $ svn copy http://svn.example.com/repos/calc/trunk ¥
             http://svn.example.com/repos/calc/branches/stable-1.0 ¥
             -m "Creating stable branch of calc project."
    
    Committed revision 377.

note: Tag: para
en: And now developers are free to continue adding cutting-edge (or experimental) features to <filename>/calc/trunk</filename>, and you can declare a project policy that only bug fixes are to be committed to <filename>/calc/branches/stable-1.0</filename>. That is, as people continue to work on the trunk, a human selectively ports bug fixes over to the stable branch. Even after the stable branch has shipped, you'll probably continue to maintain the branch for a long time&mdash;that is, as long as you continue to support that release for customers.
ja: これで開発者は最先端の機能(あるいは実験的な機能)を <filename>/calc/trunk</filename>に追加し続けることが でき、バグフィックスだけを<filename>/calc/branches/stable-1.0</filename> にコミットするようなポリシーで進めることができます。 つまり、メンバーがtrunk上で作業し続けるときに、バグフィックスに ついては安定版ブランチ上に持っていくことができます。安定版ブランチ が出荷されたあとでも、そのブランチを長い時間かけて保守し続ける でしょう&mdash;つまり、顧客に対してそのリリースをサポートし続ける 限り。

note: Tag: title
en: Vendor branches
ja: ベンダーブランチ

note: Tag: para
en: As is especially the case when developing software, the data that you maintain under version control is often closely related to, or perhaps dependent upon, someone else's data. Generally, the needs of your project will dictate that you stay as up-to-date as possible with the data provided by that external entity without sacrificing the stability of your own project. This scenario plays itself out all the time&mdash;anywhere that the information generated by one group of people has a direct effect on that which is generated by another group.
ja: ソフトウェアを開発する場合が典型的な例ですが、バージョン管理で保守しているデータが しばしば誰かのほかのデータに密接に関係しているか、あるいは依存している ことがあります。一般的にプロジェクトで要求されることは、プロジェクトの 安定性を損なうことなく、外部の資源によって提供されるデータをできる限り 最新に保つことです。この考え方は、あるグループによって作られた情報が もう1つのグループによって作られるものに影響を与える場合、常に成り立ちます。

note: Tag: para
en: For example, software developers might be working on an application which makes use of a third-party library. Subversion has just such a relationship with the Apache Portable Runtime library (see <xref linkend="svn.developer.usingapi.apr"/>). The Subversion source code depends on the APR library for all its portability needs. In earlier stages of Subversion's development, the project closely tracked APR's changing API, always sticking to the <quote>bleeding edge</quote> of the library's code churn. Now that both APR and Subversion have matured, Subversion attempts to synchronize with APR's library API only at well-tested, stable release points.
ja: たとえば、ソフトウェア開発者がサードパーティー製のライブラリを利用する アプリケーションの開発に取り組んでいるとします。SubversionはApache ポータブル 実行時ライブラリと、ちょうどそのような関係を持っています。 (<xref linkend="svn.developer.usingapi.apr"/>参照)。Subversionのソースコードは すべての可搬性の要求を満たすために、APRライブラリに依存しています。 Subversionの開発の初期の段階では、プロジェクトはAPR のAPIの変更を非常に 正確に追いかけていました。常に、ライブラリコードの荒波の、<quote> 最先端</quote>についていきました。いまではAPRもSubversionも開発が落ち着い てきたので、Subversionはよくテストされ、安定したリリース状態にある バージョンのAPRライブラリAPIとのみ同期をとっています。

note: Tag: para
en: Now, if your project depends on someone else's information, there are several ways that you could attempt to synchronize that information with your own. Most painfully, you could issue oral or written instructions to all the contributors of your project, telling them to make sure that they have the specific versions of that third-party information that your project needs. If the third-party information is maintained in a Subversion repository, you could also use Subversion's externals definitions to effectively <quote>pin down</quote> specific versions of that information to some location in your own working copy directory (see <xref linkend="svn.advanced.externals"/>).
ja: もしプロジェクトが他の人の情報に依存しているなら、その情報と自分の ものとを同期させるためのいくつかの方法があります。 一番大変な方法ですが、自分のプロジェクトのすべての貢献者に対して 口頭または文書で手続きを伝えることができます。プロジェクトに必要な サードパーティーの情報の特定のバージョンを確実に手に入れることを 伝えます。もしサードパーティーの情報がSubversionリポジトリで管理 されているなら、Subversionの外部定義を使ってその情報の特定のバージョンを 作業コピーディレクトリ中のある場所へ効果的に<quote>結びつける</quote>こと ができるでしょう (<xref linkend="svn.advanced.externals"/>参照)。

note: Tag: para
en: But sometimes you want to maintain custom modifications to third-party data in your own version control system. Returning to the software development example, programmers might need to make modifications to that third-party library for their own purposes. These modifications might include new functionality or bug fixes, maintained internally only until they become part of an official release of the third-party library. Or the changes might never be relayed back to the library maintainers, existing solely as custom tweaks to make the library further suit the needs of the software developers.
ja: しかし、ときどき自分のバージョン管理システムでサードパーティーのデータ に加えた独自の変更を管理したいこともあります。ソフトウェア開発の 例に戻って説明すると、プログラマは自分自身の目的のために、サードパーティー のライブラリに変更を加える必要があるかも知れません。このような修正は 新しい機能の追加であったりバグフィックスであったりするかも知れませんが、 それはサードパーティーのライブラリの醐ｷｺ�なリリースの一部になるまでに 限り管理すべきものです。あるいは、変更は決してライブラリ保守担当には 伝えられず、ソフトウェア開発者の特殊な要求に合うようなライブラリを 作り上げるための独自の修正点としてずっと残り続けるかも知れません。

note: Tag: para
en: Now you face an interesting situation. Your project could house its custom modifications to the third-party data in some disjointed fashion, such as using patch files or full-fledged alternate versions of files and directories. But these quickly become maintenance headaches, requiring some mechanism by which to apply your custom changes to the third-party data, and necessitating regeneration of those changes with each successive version of the third-party data that you track.
ja: ここで、面白い状況に直面します。あなたのプロジェクトは、パッチファイルを 適用したりファイルやディレクトリーを完全に別のものに置き換えるような、若干 バラバラな方法でサードパーティーのデータへ独自の修正を加えることができました。 しかし、このようなやり方ではすぐに保守する上で頭痛の種になるので、 あなたの独自の変更をサードパーティーのデータに適用する仕組みが必要となります。 さらにあなたが追跡するサードパーティーのデータのそれぞれの連続したバージョンに それらの変更を再生する仕組みも必要となります。

note: Tag: para
en: The solution to this problem is to use <firstterm>vendor branches</firstterm>. A vendor branch is a directory tree in your own version control system that contains information provided by a third-party entity, or vendor. Each version of the vendor's data that you decide to absorb into your project is called a <firstterm>vendor drop</firstterm>.
ja: この問題に対する解決は、<firstterm>ベンダーブランチ</firstterm>を 使うことです。ベンダーブランチはサードパーティーあるいはベンダー よって提供された情報を含んでいる、こちらのバージョン管理 システム中のディレクトリツリーです。それぞれの バージョンのベンダーのデータで、自分のプロジェクトに取り込もうと 考えているもののことを、<firstterm>ベンダードロップ</firstterm>と いいます。

note: Tag: title
en: General Vendor Branch Management Procedure
ja: 一般的な、ベンダーブランチを管理する方法

note: Tag: para
en: Managing vendor branches generally works like this. You create a top-level directory (such as <filename>/vendor</filename>) to hold the vendor branches. Then you import the third party code into a subdirectory of that top-level directory. You then copy that subdirectory into your main development branch (for example, <filename>/trunk</filename>) at the appropriate location. You always make your local changes in the main development branch. With each new release of the code you are tracking you bring it into the vendor branch and merge the changes into <filename>/trunk</filename>, resolving whatever conflicts occur between your local changes and the upstream changes.
ja: ベンダーブランチの管理は一般的にはこんな感じでやります。 最上位ディレクトリを作り(<filename>/vendor</filename>のようなもの) そこにベンダーのブランチを置きます。それから最上位ディレクトリの サブディレトクリにサードパーティーのコードをインポートします。 それからそのサブディレトクリを、適当な場所にある、自分の主系開発の ブランチにコピーします(たとえば<filename>/trunk</filename>など)。 ローカルな変更は常に主系開発ブランチに対して行います。 追いかけているコードの新しいリリースのたびに、それをベンダーブランチに 持っていき、変更点を<filename>/trunk</filename>にマージします。そして、 ローカルの変更と、ベンダーの変更の間の衝突を解消します。

note: Tag: para
en: Perhaps an example will help to clarify this algorithm. We'll use a scenario where your development team is creating a calculator program that links against a third-party complex number arithmetic library, libcomplex. We'll begin with the initial creation of the vendor branch, and the import of the first vendor drop. We'll call our vendor branch directory <filename>libcomplex</filename>, and our code drops will go into a subdirectory of our vendor branch called <filename>current</filename>. And since <command>svn import</command> creates all the intermediate parent directories it needs, we can actually accomplish both of these steps with a single command.
ja: 多分、例をあげると、このステップをはっきりさせることができるかも 知れません。あなたの開発チームがサードパーティーの複素数値計算 ライブラリ libcomplex を使った計算プログラムを作っているとします。 まず、ベンダーブランチの初期生成をし、それから最初のベンダードロップ をインポートします。ここではベンダーブランチのディレクトリを <filename>libcomplex</filename>と呼び、私たちのコードドロップは <filename>current</filename>と呼ばれる私たちのベンダーブランチの サブディレクトリの中に置かれます。<command>svn import</command>は 必要なすべての中間的な親ディレクトリを作るので、このような複数の ステップを実際には一つのコマンドで実行することができます。

note: Tag: screen
en: $ svn import /path/to/libcomplex-1.0 \
                 http://svn.example.com/repos/vendor/libcomplex/current \
                 -m 'importing initial 1.0 vendor drop'
    &hellip;
ja: $ svn import /path/to/libcomplex-1.0 ¥
                 http://svn.example.com/repos/vendor/libcomplex/current ¥
                 -m 'importing initial 1.0 vendor drop'
    &hellip;

note: Tag: para
en: We now have the current version of the libcomplex source code in <filename>/vendor/libcomplex/current</filename>. Now, we tag that version (see <xref linkend="svn.branchmerge.tags"/>) and then copy it into the main development branch. Our copy will create a new directory called <filename>libcomplex</filename> in our existing <filename>calc</filename> project directory. It is in this copied version of the vendor data that we will make our customizations.
ja: これで、libcomplexのソースコードを<filename>/vendor/libcomplex/current</filename> に持ってくることができました。このバージョンにタグ付けし、 (<xref linkend="svn.branchmerge.tags"/>参照)、主系開発ブランチにコピーしま す。私たちのコピーは既存の<filename>calc</filename>プロジェクトディレクトリ 中の<filename>libcomplex</filename>という新しいディレクトリを作ります。 これが新たに独自の修正を加えるためのベンダーデータのコピーになります。

note: Tag: screen
en: $ svn copy http://svn.example.com/repos/vendor/libcomplex/current  \
               http://svn.example.com/repos/vendor/libcomplex/1.0      \
               -m 'tagging libcomplex-1.0'
    &hellip;
    $ svn copy http://svn.example.com/repos/vendor/libcomplex/1.0  \
               http://svn.example.com/repos/calc/libcomplex        \
               -m 'bringing libcomplex-1.0 into the main branch'
    &hellip;
ja: $ svn copy http://svn.example.com/repos/vendor/libcomplex/current  ¥
               http://svn.example.com/repos/vendor/libcomplex/1.0      ¥
               -m 'tagging libcomplex-1.0'
    &hellip;
    $ svn copy http://svn.example.com/repos/vendor/libcomplex/1.0  ¥
               http://svn.example.com/repos/calc/libcomplex        ¥
               -m 'bringing libcomplex-1.0 into the main branch'
    &hellip;

note: Tag: para
en: We check out our project's main branch&mdash;which now includes a copy of the first vendor drop&mdash;and we get to work customizing the libcomplex code. Before we know it, our modified version of libcomplex is now completely integrated into our calculator program.
ja: プロジェクトの主系のブランチをチェックアウトします。これは最初の ベンダードロップのコピーを含んでいます&mdash;そして、libcomplex コードの修正に入ります。もう知っているように、これで修正されたlibcomplex は、私たちの計算プログラムに完全に統合されています。

note: Tag: para
en: And entirely bug-free, of course!
ja: そして、もちろんあなたのことですから、バグも完全になくなっている、と。

note: Tag: para
en: A few weeks later, the developers of libcomplex release a new version of their library&mdash;version 1.1&mdash;which contains some features and functionality that we really want. We'd like to upgrade to this new version, but without losing the customizations we made to the existing version. What we essentially would like to do is to replace our current baseline version of libcomplex 1.0 with a copy of libcomplex 1.1, and then re-apply the custom modifications we previously made to that library to the new version. But we actually approach the problem from the other direction, applying the changes made to libcomplex between versions 1.0 and 1.1 to our modified copy of it.
ja: 何週間かたって、libcomplexの開発者はライブラリの新しいバージョンを リリースしました&mdash;バージョン1.1としましょう&mdash;それは われわれがほしかったいくつかの機能と関数を含んでいます。この新しい バージョンにアップグレードしたいものですが、既に手元にあるバージョンに 対する修正を失いたくはありません。既に示唆したように、 本質的にわれわれがやらなくてはならないのは、libcomplex1.1 のコピー でlibcomplex1.0 を置き換え、前にやった独自の修正を、新しいライブラリ のバージョンにも再び適用することです。しかし実際には私たちはこの問題に 対して別の方法で対処したいのですが、それはバージョン1.0 と 1.1 の間 にlibcomplexにおきた変更点を私たちの修正されたコピー上に適用するという ものです。

note: Tag: para
en: After replacing the 1.0 code with 1.1 code, <command>svn status</command> will show files with local modifications as well as, perhaps, some unversioned or missing files. If we did what we were supposed to do, the unversioned files are only those new files introduced in the 1.1 release of libcomplex&mdash;we run <command>svn add</command> on those to get them under version control. The missing files are files that were in 1.0 but not in 1.1, and on those paths we run <command>svn delete</command>. Finally, once our <filename>current</filename> working copy contains only the libcomplex 1.1 code, we commit the changes we made to get it looking that way.
ja: 1.0 のコードを 1.1 のコードに置き換えた後では、 <command>svn status</command> はローカルな修正を加えたファイルの一覧と バージョン化されていないファイル、あるいは失われたファイルも表示 するでしょう。いままで述べたような手順を実行していたのなら、バージョン 化されていないファイルは libcomplex の 1.1 のリリースで新しく導入され たようなものだけのはずです&mdash;そのようなファイルをバージョン管理下 に置くのに<command>svn add</command>を実行します。失われたファイルは 1.0 では存在していたが、1.1 では存在しないようなものに対応しているので <command>svn delete</command>を実行します。最後に、私たちの <filename>current</filename>作業コピーが libcomplex 1.1 のコードのみ を含むようになれば、いまの変更をコミットして、つじつまを合わせます。

note: Tag: para
en: Our <filename>current</filename> branch now contains the new vendor drop. We tag the new version (in the same way we previously tagged the version 1.0 vendor drop), and then merge the differences between the tag of the previous version and the new current version into our main development branch.
ja: 私たちの<filename>current</filename>ブランチはこれで新しい ベンダードロップを含むようになります。新しいバージョンに(バージョン 1.0のベンダードロップに対して前にしたのと同じ方法で)タグづけをして、 それから前のバージョンのタグと新しい現在のバージョンとの間の差分を 私たちの開発ブランチにマージします。

note: Tag: screen
en: $ cd working-copies/calc
    $ svn merge http://svn.example.com/repos/vendor/libcomplex/1.0      \
                http://svn.example.com/repos/vendor/libcomplex/current  \
                libcomplex
    &hellip; # resolve all the conflicts between their changes and our changes
    $ svn commit -m 'merging libcomplex-1.1 into the main branch'
    &hellip;
ja: $ cd working-copies/calc
    $ svn merge http://svn.example.com/repos/vendor/libcomplex/1.0      ¥
                http://svn.example.com/repos/vendor/libcomplex/current  ¥
                libcomplex
    &hellip; # resolve all the conflicts between their changes and our changes
    $ svn commit -m 'merging libcomplex-1.1 into the main branch'
    &hellip;

note: Tag: para
en: In the trivial use case, the new version of our third-party tool would look, from a files-and-directories point of view, just like the previous version. None of the libcomplex source files would have been deleted, renamed or moved to different locations&mdash;the new version would contain only textual modifications against the previous one. In a perfect world, our modifications would apply cleanly to the new version of the library, with absolutely no complications or conflicts.
ja: 簡単な場合だと、この新しいバージョンのサードパーティーツールは、 ファイルとディレクトリの観点から見ると、前のバージョンと同じように 見えます。libcomplex のどのソースファイルも削除されたり名称変更された り別の場所に移動されたりはしません&mdash;新しいバージョンは単に前の ものからテキストの内容の修正を受けただけに見えます。理想的な状況では 私たちの修正は新しいライブラリのバージョンに対してきれいに適用され、 複雑なことや、衝突は一切起きません。

note: Tag: para
en: But things aren't always that simple, and in fact it is quite common for source files to get moved around between releases of software. This complicates the process of ensuring that our modifications are still valid for the new version of code, and can quickly degrade into a situation where we have to manually recreate our customizations in the new version. Once Subversion knows about the history of a given source file&mdash;including all its previous locations&mdash;the process of merging in the new version of the library is pretty simple. But we are responsible for telling Subversion how the source file layout changed from vendor drop to vendor drop.
ja: しかし、ものごとというものは常に単純であるとは限りません。 実際、ソースファイルはソフトウェアのリリース間であちこち 動くのが普通です。これはわたしたちの修正が新しいバージョンのコード でも正しいということを確認する作業を複雑にしますし、新しいバージョン での修正を手でもう一度やる必要がある状況に、簡単に落ち込んでしまう ことがあります。Subversionが、与えられたソースファイルの（以前の位置を含めての） 履歴について知っていればライブラリの新しいバージョンのマージのステップは とても単純になります。しかし、わたしたちは、Subversionに ソースファイルのレイアウトがベンダードロップ間でどんな風に 変わったかを教えてやる責任があります。

note: Tag: para
en: Vendor drops that contain more than a few deletes, additions and moves complicate the process of upgrading to each successive version of the third-party data. So Subversion supplies the <command>svn_load_dirs.pl</command> script to assist with this process. This script automates the importing steps we mentioned in the general vendor branch management procedure to make sure that mistakes are minimized. You will still be responsible for using the merge commands to merge the new versions of the third-party data into your main development branch, but <command>svn_load_dirs.pl</command> can help you more quickly and easily arrive at that stage.
ja: いくつかのファイルの削除、追加、移動があったベンダードロップは サードパーティーデータのアップグレードの手順を複雑にします。 それでSubversionはこの手続きを支援するために <command>svn_load_dirs.pl</command>スクリプトを用意しています。 このスクリプトは一般的なベンダーブランチの管理手続きで言ったような インポートのステップを自動化し、間違いを最小にすることができます。 サードパーティーデータの新しいバージョンを主系開発ブランチにマージする ためのマージコマンドを使う責任はまだ残っているものの、 <command>svn_load_dirs.pl</command>はより早く簡単にこの処理まで 到達する助けになります。

note: Tag: para
en: In short, <command>svn_load_dirs.pl</command> is an enhancement to <command>svn import</command> that has several important characteristics:
ja: 簡単に言って、<command>svn_load_dirs.pl</command> は <command>svn import</command> の拡張で、いくつかの重要な 特徴を持っています:

note: Tag: para
en: It can be run at any point in time to bring an existing directory in the repository to exactly match an external directory, performing all the necessary adds and deletes, and optionally performing moves, too.
ja: いつでも、このプログラムを実行して、 リポジトリにあるディレクトリを、完全にそれに一致した外部 ディレクトリに持って行き、必要なすべての追加、削除を実行し、 さらにオプションで移動処理も行います。

note: Tag: para
en: It takes care of complicated series of operations between which Subversion requires an intermediate commit&mdash;such as before renaming a file or directory twice.
ja: このプログラムは、Subversionが必要とする中間的なコミット間で 必要な複雑な一連の処理を注意深く実行します&mdash;たとえば ファイルやディレクトリの名称変更を二回やる前など。

note: Tag: para
en: It will optionally tag the newly imported directory.
ja: それは、オプションで新しいインポートされたディレクトリを タグ付けします。

note: Tag: para
en: It will optionally add arbitrary properties to files and directories that match a regular expression.
ja: それはオプションで、正規表現にマッチするファイルとディレクトリ に任意の属性を追加します。

note: Tag: para
en: <command>svn_load_dirs.pl</command> takes three mandatory arguments. The first argument is the URL to the base Subversion directory to work in. This argument is followed by the URL&mdash;relative to the first argument&mdash;into which the current vendor drop will be imported. Finally, the third argument is the local directory to import. Using our previous example, a typical run of <command>svn_load_dirs.pl</command> might look like:
ja: <command>svn_load_dirs.pl</command> は三つの必須パラメータを とります。最初の引数は作業対象となるベースになるSubversionディレクトリのURL です。この引数のあとにはURLが続きます&mdash;最初の引数に相対的な 形で&mdash;ベンダードロップはそこにインポートされます。最後に 三番目の引数はインポートするローカルディレクトリです。前の例を 使うと、典型的な<command>svn_load_dirs.pl</command>の実行は こんな感じになります:

note: Tag: screen
en: $ svn_load_dirs.pl http://svn.example.com/repos/vendor/libcomplex \
                       current                                        \
                       /path/to/libcomplex-1.1
    &hellip;
ja: $ svn_load_dirs.pl http://svn.example.com/repos/vendor/libcomplex ¥
                       current                                        ¥
                       /path/to/libcomplex-1.1
    &hellip;

note: Tag: para
en: You can indicate that you'd like <command>svn_load_dirs.pl</command> to tag the new vendor drop by passing the <option>-t</option> command-line option and specifying a tag name. This tag is another URL relative to the first program argument.
ja: <option>-t</option> オプションにタグ名称を指定して、新しいベンダードロップ をタグ付けするように<command>svn_load_dirs.pl</command> に指示することが できます。

note: Tag: screen
en: $ svn_load_dirs.pl -t libcomplex-1.1                              \
                       http://svn.example.com/repos/vendor/libcomplex \
                       current                                        \
                       /path/to/libcomplex-1.1
    &hellip;
ja: $ svn_load_dirs.pl -t libcomplex-1.1                              ¥
                       http://svn.example.com/repos/vendor/libcomplex ¥
                       current                                        ¥
                       /path/to/libcomplex-1.1
    &hellip;

note: Tag: para
en: The script also accepts a separate configuration file for setting properties on files and directories matching a regular expression that are <emphasis>added</emphasis> to the repository. This configuration file is specified to <command>svn_load_dirs.pl</command> using the <option>-p</option> command-line option. Each line of the configuration file is a whitespace-delimited set of two or four values: a Perl-style regular expression to match the added path against, a control keyword (either <literal>break</literal> or <literal>cont</literal>), and then optionally a property name and value.
ja: このスクリプトはまたリポジトリに<emphasis>追加される</emphasis> （正規表現にマッチするような）ファイルとディレクトリの属性を設定する ために、別の設定ファイルを受け付けることができます。 この設定ファイルは<command>svn_load_dirs.pl</command> で <option>-p</option> オプションを使って指定されます。 設定ファイルの各行は空白で区切られた二つまたは四つの値です: 追加されるパスに対してマッチさせるPerlスタイルの正規表現、 制御キーワード(<literal>break</literal> または <literal>cont</literal>)、そして、オプションで属性名と 属性値がきます。

note: Tag: screen
en: \.png$              break   svn:mime-type   image/png
    \.jpe?g$            break   svn:mime-type   image/jpeg
    \.m3u$              cont    svn:mime-type   audio/x-mpegurl
    \.m3u$              break   svn:eol-style   LF
    .*                  break   svn:eol-style   native
ja: ¥.png$              break   svn:mime-type   image/png
    ¥.jpe?g$            break   svn:mime-type   image/jpeg
    ¥.m3u$              cont    svn:mime-type   audio/x-mpegurl
    ¥.m3u$              break   svn:eol-style   LF
    .*                  break   svn:eol-style   native

note: Tag: para
en: For each added path, the configured property changes whose regular expression matches the path are applied in order, unless the control specification is <literal>break</literal> (which means that no more property changes should be applied to that path). If the control specification is <literal>cont</literal>&mdash;an abbreviation for <literal>continue</literal>&mdash;then matching will continue with the next line of the configuration file.
ja: 追加されるパスが正規表現にマッチしたとき、その行の属性 がマッチしたパスに追加されていきます。ただし制御の指定が<literal>break</literal> の場合は属性の追加はその行で打ち止めになります(これはそれ以上の属性変更はこのパスに 行わないことを意味しています)。もし制御指定が<literal>cont</literal> &mdash;<literal>continue</literal>の省略形ですが&mdash;の場合は マッチング処理は設定ファイルの次の行に続いていきます。

note: Tag: para
en: Any whitespace in the regular expression, property name, or property value must be surrounded by either single or double quote characters. You can escape quote characters that are not used for wrapping whitespace by preceding them with a backslash (<literal>\</literal>) character. The backslash escapes only quotes when parsing the configuration file, so do not protect any other characters beyond what is necessary for the regular expression.
ja: 正規表現中のすべての空白、属性名、属性値はシングルまたはダブルクオート でくくる必要があります。空白を囲むために利用しているわけではない クオート文字はバックスラッシュ文字(<literal>¥</literal>) を前に付ける ことでエスケープできます。バックスラッシュは設定ファイルを解析するとき だけクオートするので、正規表現中で必要なもの以外のほかの文字には 使わないでください。

note: Tag: para
en: We've covered a lot of ground in this chapter. We've discussed the concepts of tags and branches, and demonstrated how Subversion implements these concepts by copying directories with the <command>svn copy</command> command. We've shown how to use <command>svn merge</command> to copy changes from one branch to another, or roll back bad changes. We've gone over the use of <command>svn switch</command> to create mixed-location working copies. And we've talked about how one might manage the organization and lifetimes of branches in a repository.
ja: この章では、いろいろな基本に触れました。タグとブランチの概念を議論し、 Subversionが<command>svn copy</command>でディレクトリをコピーする ことによってこれらの概念を実装していることを説明しました。 <command>svn merge</command>であるブランチから別のブランチに変更点 をコピーしたり、間違った変更を戻したりする方法をお見せしました。 <command>svn switch</command>を使って、混合状態の作業コピーを 作ってみせました。そして、どのようにしてリポジトリ内のブランチの 編成と種ｴ幔ｽを管理するかについて話しました。

note: Tag: title
en: Repository Administration
ja: リポジトリの管理

note: Tag: para
en: A directory containing repository configuration files.
ja: リポジトリ設定ファイルのあるディレクトリです。

note: Tag: para
en: A directory full of hook script templates (and hook scripts themselves, once you've installed some).
ja: フックスクリプトテンプレート全体が格納されたディレクトリです (また、インストールされたフックスクリプト自身も)。

note: Tag: para
en: A middle-ground approach can be taken, too. For example, projects can be grouped by how well they relate to each other. You might have a few repositories with a handful of projects in each repository. That way, projects that are likely to want to share data can do so easily, and as new revisions are added to the repository, at least the developers know that those new revisions are at least remotely related to everyone who uses that repository.
ja: 折衷策をとることもできます。たとえば、お互いに どの程度深く関係しているかによってプロジェクトをグループ化する ことができます。それぞれのリポジトリにいくつかのプロジェクトを持たせる ことで、少ない数のリポジトリを管理することもできます。この方法では データを共有したいプロジェクトは簡単にそうすることができますし、 新しいリビジョンがリポジトリに追加されると、開発者は そのような新しいリビジョンは、自分のプロジェクトか、少なくともそれに 関係しているプロジェクトの誰かがやったものだということがわかります。

note: Tag: para
en: The <filename>trunk</filename>, <filename>tags</filename>, and <filename>branches</filename> trio are sometimes referred to as <quote>the TTB directories</quote>.
ja: <filename>trunk</filename>, <filename>tags</filename>, <filename>branches</filename> の三つのファイルの全体を <quote>TTB ディレクトリ</quote> と呼ぶことがあります。

note: Tag: para
en: For example, your repository might look like:
ja: たとえば、リポジトリが以下のようであるとして:

note: Tag: para
en: Note that it doesn't matter where in your repository each project root is. If you have only one project per repository, the logical place to put each project root is at the root of that project's respective repository. If you have multiple projects, you might want to arrange them in groups inside the repository, perhaps putting projects with similar goals or shared code in the same subdirectory, or maybe just grouping them alphabetically. Such an arrangement might look like:
ja: それぞれのプロジェクトルートがリポジトリ中のどこにあるかは問題には なりません。もしリポジトリに唯一のプロジェクトがある場合は それぞれのプロジェクトルートを置くための論理的な場所はプロジェクト ごとのリポジトリのルートになります。もし複数のプロジェクトが ある場合は、リポジトリ内部のグループ中にそれを配置したいかも知れません、 おそらく同じサブディレクトリ中の似たような目標や共有するコードと 一緒にプロジェクトを置くか、あるいは名前の辞書順にグループ化するか、 などです。配置は以下のようになるでしょう:

note: Tag: title
en: Repository Data Store Comparison
ja: Repository 保存形式の比較

note: Tag: entry
en: Category
ja: 分類

note: Tag: entry
en: Sensitivity to interruptions
ja: リポジトリの壊れやすさ

note: Tag: entry
en: Usable from a read-only mount
ja: リードオンリーでマウントできるか

note: Tag: entry
en: <entry>no</entry>
ja: <entry>いいえ</entry>

note: Tag: entry
en: <entry>yes</entry>
ja: <entry>はい</entry>

note: Tag: entry
en: Platform-independent storage
ja: プラットフォームに独立した保存形式か

note: Tag: entry
en: Usable over network filesystems
ja: ネットワークファイルシステムでも使えるか

note: Tag: entry
en: Group permissions handling
ja: グループパーミッション制御

note: Tag: entry
en: works around umask problems
ja: umask の問題を回避できる

note: Tag: entry
en: database; no problems
ja: データベースなので問題なし

note: Tag: para
en: When the initial design phase of Subversion was in progress, the developers decided to use Berkeley DB for a variety of reasons, including its open-source license, transaction support, reliability, performance, API simplicity, thread-safety, support for cursors, and so on.
ja: Subversion の最初の 設計段階で、開発者はさまざまな理由で Berkeley DB を利用することに決めました。 その理由にはそのオープンソースライセンス、トランザクションのサポート、 信頼性、パフォーマンス、API の公開、スレッドの安全性、カーソルのサポート などが含まれていました。

note: Tag: para
en: Berkeley DB provides real transaction support&mdash;perhaps its most powerful feature. Multiple processes accessing your Subversion repositories don't have to worry about accidentally clobbering each other's data. The isolation provided by the transaction system is such that for any given operation, the Subversion repository code sees a static view of the database&mdash;not a database that is constantly changing at the hand of some other process&mdash;and can make decisions based on that view. If the decision made happens to conflict with what another process is doing, the entire operation is rolled back as if it never happened, and Subversion gracefully retries the operation against a new, updated (and yet still static) view of the database.
ja: Berkeley DB は本当のトランザクション機能をサポートしています&mdash;おそらく 上であげた理由の中で最も強力な機能です。Subversion リポジトリにアクセスする 複数のプロセスはそれぞれ他のデータを間違って破壊することを心配する必要はありません。 トランザクションシステムによって提供されている分離機能はどんな操作においても Subversion リポジトリのコードにデータベースを静的に見せることができるように するものです&mdash;他のプロセスによってときどき変更を受けているように見えるのを 防ぐものです&mdash; そしてそのような静的な見え方に基づいて、何を実行するか を決めることができるのです。もしその決定が他のプロセスがやったことと衝突 した場合、操作全体は、それがまったく実行されなかったかのようにロールバック され、Subversion はもう一度、新しく更新された(そしてやはりまた静的に見える ような状態での)データベースに対してその処理を再実行することができます。

note: Tag: para
en: Another great feature of Berkeley DB is <firstterm>hot backups</firstterm>&mdash;the ability to backup the database environment without taking it <quote>offline</quote>. We'll discuss how to backup your repository in <xref linkend="svn.reposadmin.maint.backup"/>, but the benefits of being able to make fully functional copies of your repositories without any downtime should be obvious.
ja: Berkeley DB のほかのすばらしい機能は<firstterm>ホットバックアップ</firstterm> &mdash; <quote>オフライン</quote>にせずにデータベース環境をバックアップできる 能力です。リポジトリのバックアップ方法については<xref linkend="svn.reposadmin.maint.backup"/>で議論しますが、オフラインに せずにリポジトリの完全なコピーをとることができる利点は明白でしょう。

note: Tag: para
en: The <filename>hooks</filename> subdirectory is, by default, filled with templates for various repository hooks.
ja: <filename>hooks</filename> サブディレクトリには、デフォルトでは さまざまなリポジトリフックのテンプレートがあります。

note: Tag: title
en: Berkeley DB Configuration
ja: Berkeley DB の設定

note: Tag: title
en: Repository Maintenance
ja: リポジトリの保守

note: Tag: title
en: An Administrator's Toolkit
ja: 管理者用ツールキット

note: Tag: para
en: Subversion provides a handful of utilities useful for creating, inspecting, modifying and repairing your repository. Let's look more closely at each of those tools. Afterward, we'll briefly examine some of the utilities included in the Berkeley DB distribution that provide functionality specific to your repository's database backend not otherwise provided by Subversion's own tools.
ja: Subversion はリポジトリの作成、調査、修正、修復に便利なユー ティリティーをいくつも提供しています。それぞれについてもっと詳し く見てみましょう。その後 Berkeley DB のディストリビューションに含 まれるユーティリティーのいくつかを簡単にためしてみます。 Berkeley DB は Subversion 自身のツールとしては提供していないリポ ジトリデータベースバックエンドに特化した機能を提供しています。

note: Tag: para
en: <command>svnlook</command> has a straightforward syntax:
ja: <command>svnlook</command> は単純な構文です:

note: Tag: para
en: Output from <command>svnlook</command> is designed to be both human- and machine-parsable. Take as an example the output of the <literal>info</literal> subcommand:
ja: <command>svnlook</command> の出力は人間にも マシンにも理解できるように設計されています。 <literal>info</literal> サブコマンドを例にします:

note: Tag: para
en: The output of the <literal>info</literal> subcommand is defined as:
ja: <literal>info</literal> サブコマンドの 出力は、以下のように定義されています:

note: Tag: para
en: The author, followed by a newline.
ja: 作業者、改行

note: Tag: para
en: The date, followed by a newline.
ja: 日付、改行

note: Tag: para
en: The number of characters in the log message, followed by a newline.
ja: ログメッセージの長さ、改行

note: Tag: para
en: The log message itself, followed by a newline.
ja: ログメッセージ自身、改行

note: Tag: para
en: The syntax of <command>svndumpfilter</command> is as follows:
ja: <command>svndumpfilter</command> の構文は以下のものです:

note: Tag: para
en: There are only two interesting subcommands. They allow you to make the choice between explicit or implicit inclusion of paths in the stream:
ja: 興味深いサブコマンドは二つだけです。これらのサブコマンドを使って、 ストリーム中で明示的に、あるいは暗黙に取得するパスを選ぶことができます。:

note: Tag: para
en: Filter out a set of paths from the dump data stream.
ja: ダンプデータストリームから特定のパスを排除します。

note: Tag: para
en: Allow only the requested set of paths to pass through the dump data stream.
ja: ダンプデータストリームから、指定したパスだけを 出力するようにします。

note: Tag: title
en: Berkeley DB Utilities
ja: Berkeley DB ユーティリティー

note: Tag: para
en: For day-to-day Subversion use, these tools are unnecessary. Most of the functionality typically needed for Subversion repositories has been duplicated in the <command>svnadmin</command> tool. For example, <command>svnadmin list-unused-dblogs</command> and <command>svnadmin list-dblogs</command> perform a subset of what is provided by the Berkeley <command>db_archive</command> command, and <command>svnadmin recover</command> reflects the common use cases of the <command>db_recover</command> utility.
ja: 通常のSubversion の利用ではこれらのツールは不要です。Subversion リポジトリ に必要なほとんどの機能は<command>svnadmin</command>を使って実行する ことができます。たとえば<command>svnadmin list-unused-dblogs</command>と <command>svnadmin list-dblogs</command>は Berkeley の <command>db_archive</command>で提供されている機能のサブセットであり、 <command>svnadmin recover</command>は <command>db_recover</command> ユーティリティーの普通の状況での利用の仕方を反映したコマンドです。

note: Tag: para
en: If a log message needs to be changed by an administrator, this can be done using <command>svnadmin setlog</command>. This command changes the log message (the <literal>svn:log</literal> property) on a given revision of a repository, reading the new value from a provided file.
ja: もしログメッセージを管理者が変更する必要がある場合、 <command>svnadmin setlog</command>を使います。このコマンドは リポジトリの指定したリビジョンのログメッセージ(<literal>svn:log</literal> 属性 )を、用意したファイルから新しい値を読み出し形で変更します

note: Tag: para
en: Remember, though, that by bypassing the hooks, you are likely avoiding such things as email notifications of property changes, backup systems which track unversioned property changes, and so on. In other words, be very careful about what you are changing, and how you change it.
ja: しかしフックを回避すると、属性変更、バージョン化されていない属性変更 を追うためのバックアップシステム、などなどに関係した通知 メール も 回避されてしまうことに注意してください。言い換えると、何を、どのように 修正するかについて、非常に注意して実行してください。

note: Tag: title
en: Managing Disk Space
ja: ディスク領域の管理

note: Tag: para
en: You can use <command>svnadmin</command>'s <literal>lstxns</literal> command to list the names of the currently outstanding transactions.
ja: <command>svnadmin</command>の<literal>lstxns</literal> コマンド を使って、その時点での未完了のトランザクションの名前の一覧表示 することができます。

note: Tag: title
en: txn-info.sh (Reporting Outstanding Transactions)
ja: txn-info.sh (未解決トランザクションの表示)

note: Tag: para
en: A long-abandoned transaction usually represents some sort of failed or interrupted commit. A transaction's datestamp can provide interesting information&mdash;for example, how likely is it that an operation begun nine months ago is still active?
ja: 長く放置されているトランザクションは普通は何かに失敗したか、コミットを 中断されたかのどちらかです。トランザクションの日付スタンプは 役に立つ情報を与えてくれます &mdash; たとえば 9 ヵ月も前に始まった 操作がいまだに有効である可能性など、いったいどの程度あるのでしょうか?

note: Tag: para
en: Without some sort of automatic log file removal in place, log files will accumulate as you use your repository. This is actually somewhat of a feature of the database system&mdash;you should be able to recreate your entire database using nothing but the log files, so these files can be useful for catastrophic database recovery. But typically, you'll want to archive the log files that are no longer in use by Berkeley DB, and then remove them from disk to conserve space. Use the <command>svnadmin list-unused-dblogs</command> command to list the unused log files:
ja: このような自動ログファイル削除の仕組みを利用しなければ、 リポジトリを利用するにつれてログファイルは蓄積されていきます。 それてこれは実際にデータベースシステムであれば当然付いている機能です&mdash; ログファイル以外に何も残っていないような状況でデータベース全体を再構成する ことができるようになっていなくてはならず、そのようなログファイルは データベースの壊滅的な破壊からの復旧で利用できなければならないからです。 しかし普通は Berkeley DB で既に利用されていないログファイルをアーカイブし、 その後ディスクから削除することで領域を広げようとするでしょう。利用していない ログファイルの一覧を見るには<command>svnadmin list-unused-dblogs</command>コマンドを使ってください:

note: Tag: para
en: Become the user who owns and manages the repository. This is important, as recovering a repository while running as the wrong user can tweak the permissions of the repository's files in such a way that your repository will still be inaccessible even after it is <quote>unwedged</quote>.
ja: リポジトリを所有し、管理しているユーザになってください。 これは重要ですが、実行時と同様、復旧時に間違ったユーザで作業する ことによってもリポジトリファイルのパーミッションが変更されて しまうかも知れないからです。これによって実際には<quote>復旧</quote> したのにアクセス不能のままになってしまう可能性があります。

note: Tag: para
en: Run the command <command>svnadmin recover /path/to/repos</command>. You should see output like this:
ja: <command>svnadmin recover /path/to/repos</command>コマンドを 実行してください。以下のような出力が表示されると思います:

note: Tag: para
en: This command may take many minutes to complete.
ja: このコマンドは完了までに数分かかることもあります。

note: Tag: para
en: This procedure fixes almost every case of repository lock-up. Make sure that you run this command as the user that owns and manages the database, not just as <literal>root</literal>. Part of the recovery process might involve recreating from scratch various database files (shared memory regions, for example). Recovering as <literal>root</literal> will create those files such that they are owned by <literal>root</literal>, which means that even after you restore connectivity to your repository, regular users will be unable to access it.
ja: この方法はほとんどのリポジトリロックを解消します。このコマンドは 単に <literal>root</literal>になるのではなく、データベース を所有し、管理しているユーザで実行することに注意してください。 復旧作業は、傷を負ったいろいろなデータベースファイル からの再作成の作業も含みます。(たとえば共有メモリ領域などです) <literal>root</literal> での復旧は、<literal>root</literal> が 所有しているファイルを作成することで、これはリポジトリへの 接続状況が復旧した後でも通常のユーザはこれに対してアクセスする ことができないことを意味します。

note: Tag: para
en: The other subcommand in the pair, <command>svnadmin load</command>, parses the standard input stream as a Subversion repository dump file, and effectively replays those dumped revisions into the target repository for that operation. It also gives informative feedback, this time using the standard output stream:
ja: 組になったもう一方のサブコマンドである<command>svnadmin load</command>は、標準入力を、Subversionリポジトリのダンプファイルと して解析し、ダンプされたリビジョンを目的のリポジトリに再現します。 それはまた経過情報などを返しますが、こちらは標準出力に 表示します:

note: Tag: para
en: Note that because <command>svnadmin</command> uses standard input and output streams for the repository dump and load process, people who are feeling especially saucy can try things like this (perhaps even using different versions of <command>svnadmin</command> on each side of the pipe):
ja: <command>svnadmin</command> は標準入力と標準出力をリポジトリのダンプ とロード処理に使うので、気の利いた人は、以下のようなやり方を試す こともできます(おそらく、パイプの両側の<command>svnadmin</command> は、異なるバージョンであるかも知れません):

note: Tag: para
en: As Subversion dumps each new revision, it outputs only enough information to allow a future loader to re-create that revision based on the previous one. In other words, for any given revision in the dump file, only the items that were changed in that revision will appear in the dump. The only exception to this rule is the first revision that is dumped with the current <command>svnadmin dump</command> command.
ja: Subversionはそれぞれの新しいリビジョンをダンプするのでその出力には 後で実行されるローダが前のリビジョンを元にしてそのリビジョンを再 作成するのに必要な十分な情報があります。 言い換えると、ダンプファイル中でどのようなリビジョンが指定されても リビジョン中で変更のあったアイテムのみがダンプに現れるということ です。この規則の唯一の例外は、現在の<command>svnadmin dump</command> がダンプする最初のリビジョンです。

note: Tag: para
en: However, you can change this default behavior. If you add the <option>--incremental</option> option when you dump your repository, <command>svnadmin</command> will compare the first dumped revision against the previous revision in the repository, the same way it treats every other revision that gets dumped. It will then output the first revision exactly as it does the rest of the revisions in the dump range&mdash;mentioning only the changes that occurred in that revision. The benefit of this is that you can create several small dump files that can be loaded in succession, instead of one large one, like so:
ja: しかし、このデフォルトの振る舞いを変えることもできます。リポジトリを ダンプするときに<option>--incremental</option> オプションを追加すると <command>svnadmin</command> は最初のダンプリビジョンとリポジトリ中の 直前リビジョンとの差分をとろうとします。残りのすべてのダンプ されるリビジョンにも同じ方法で扱います。 それからダンプ範囲にある残りのリビジョンが出力するのと同じように 最初のリビジョンを&mdash;リビジョン中に起こる変更だけを 考慮して出力します。 この利点は大きな一つのダンプファイルのかわりに、ロードに成醐ｻ駈ｷるような 小さないくつものダンプファイルを作ることができることです。 こんな感じです :

note: Tag: para
en: These dump files could be loaded into a new repository with the following command sequence:
ja: これらのダンプファイルは以下のようなコマンドの流れで 新しいリポジトリ中にロードされます:

note: Tag: para
en: The dump format can also be used to merge the contents of several different repositories into a single repository. By using the <option>--parent-dir</option> option of <command>svnadmin load</command>, you can specify a new virtual root directory for the load process. That means if you have dump files for three repositories, say <filename>calc-dumpfile</filename>, <filename>cal-dumpfile</filename>, and <filename>ss-dumpfile</filename>, you can first create a new repository to hold them all:
ja: ダンプ形式はまたさまざまな異なるリポジトリの 内容を単一のリポジトリにマージするために利用することもできます。 <command>svnadmin load</command>の <option>--parent-dir</option>オプションを使って ロードプロセス用の新たな仮想ルートディレクトリを指定することが できます。これは、もし<filename>calc-dumpfile</filename>, <filename>cal-dumpfile</filename>, そして <filename>ss-dumpfile</filename>という三つのリポジトリ のダンプファイルがある場合、最初にそれらすべてを保持するような 新しいリポジトリを作ることができることを意味します:

note: Tag: para
en: Then, make new directories in the repository which will encapsulate the contents of each of the three previous repositories:
ja: それから三つの以前のリポジトリのそれぞれの内容を含んだ 新しいディレクトリをリポジトリ中に作ります:

note: Tag: screen
en: $ svn mkdir -m "Initial project roots" \
          file:///path/to/projects/calc \
          file:///path/to/projects/calendar \
          file:///path/to/projects/spreadsheet
    Committed revision 1.
    $
ja: $ svn mkdir -m "Initial project roots" ¥
          file:///path/to/projects/calc ¥
          file:///path/to/projects/calendar ¥
          file:///path/to/projects/spreadsheet
    Committed revision 1.
    $

note: Tag: para
en: Lastly, load the individual dump files into their respective locations in the new repository:
ja: 最後に個々のダンプファイルを新しいリポジトリのそれぞれの 場所にロードします:

note: Tag: para
en: Let's look a realistic example of how you might use this program. We discuss elsewhere (see <xref linkend="svn.reposadmin.projects.chooselayout"/>) the process of deciding how to choose a layout for the data in your repositories&mdash;using one repository per project or combining them, arranging stuff within your repository, and so on. But sometimes after new revisions start flying in, you rethink your layout and would like to make some changes. A common change is the decision to move multiple projects which are sharing a single repository into separate repositories for each project.
ja: このプログラムが実際にどのように動作するか例を見てみましょう。 別の場所でリポジトリ中でどのようにレイアウトを選ぶかを決める手順について 議論しました(<xref linkend="svn.reposadmin.projects.chooselayout"/>)&mdash;プロジェクトごとの リポジトリ、あるいはそれらをまとめたものを使って、リポジトリ中で構成を 変更し、などの手法です。しかし、新しいリポジトリが運用されたあとで、 よくレイアウトを再編成していくつかの修正をしたいということもあります。 一番多いのは一つのリポジトリを共有していた複数のプロジェクトを プロジェクトごとの別々のリポジトリに分離したい、という場合です。

note: Tag: para
en: Our imaginary repository contains three projects: <literal>calc</literal>, <literal>calendar</literal>, and <literal>spreadsheet</literal>. They have been living side-by-side in a layout like this:
ja: 私たちの架空のリポジトリは三つのプロジェクトを含んでいます: <literal>calc</literal>, <literal>calendar</literal>, そして <literal>spreadsheet</literal>です。 それらは以下のようなレイアウトになっています:

note: Tag: para
en: To get these three projects into their own repositories, we first dump the whole repository:
ja: これら三つのプロジェクトごとの固有のリポジトリを手に入れるには、 まずリポジトリ全体をダンプします:

note: Tag: para
en: Next, run that dump file through the filter, each time including only one of our top-level directories, and resulting in three new dump files:
ja: 次に結果のダンプファイルをフィルタに通しますが、各実行時で ただ一つの最上位ディレクトリを含むように指定することで、 三つの新しいダンプファイルを生成することができます:

note: Tag: para
en: At this point, you have to make a decision. Each of your dump files will create a valid repository, but will preserve the paths exactly as they were in the original repository. This means that even though you would have a repository solely for your <literal>calc</literal> project, that repository would still have a top-level directory named <filename>calc</filename>. If you want your <filename>trunk</filename>, <filename>tags</filename>, and <filename>branches</filename> directories to live in the root of your repository, you might wish to edit your dump files, tweaking the <literal>Node-path</literal> and <literal>Node-copyfrom-path</literal> headers to no longer have that first <filename>calc/</filename> path component. Also, you'll want to remove the section of dump data that creates the <filename>calc</filename> directory. It will look something like:
ja: この時点で、判断しなくてはなりません。上でできた三つのダンプファイルは 正しいリポジトリですが、元のリポジトリ中にあった通りのパス構成で保存されて います。これは<literal>calc</literal>プロジェクト単独のリポジトリを 取得したにもかかわらず、リポジトリはあいかわらず<filename>calc</filename> という名前の最上位ディレクトリ名称を持っていることを意味します。 もし<filename>trunk</filename>, <filename>tags</filename>, そして <filename>branches</filename>ディレクトリそれぞれをリポジトリ のルートディレクトリとしたければダンプファイルを編集して<literal>Node-path</literal> と <literal>Copyfrom-path</literal>ヘッダがもうこれからは先頭に <filename>calc/</filename>というパス部分を持たないようにしなくてはなりません。 同様に<filename>calc</filename>ディレクトリを作ったダンプデータのセクションを 削除したいでしょう。それは何か以下のような感じになっています:

note: Tag: para
en: All that remains now is to create your three new repositories, and load each dump file into the right repository:
ja: この修正後に残ったファイルを使って新しい三つのリポジトリを作成する ことができ、それぞれのダンプファイルを正しいリポジトリにロード することができます:

note: Tag: para
en: Both of <command>svndumpfilter</command>'s subcommands accept options for deciding how to deal with <quote>empty</quote> revisions. If a given revision contained only changes to paths that were filtered out, that now-empty revision could be considered uninteresting or even unwanted. So to give the user control over what to do with those revisions, <command>svndumpfilter</command> provides the following command-line options:
ja: <command>svndumpfilter</command>の両方のサブコマンドとも <quote>空の</quote>リビジョンをどのように扱うかを決めることが できます。パスの変更のみを含んでいるようなリビジョンを除外 すれば、空のリビジョンは興味がないか、不要なものであると 考えることができます。<command>svndumpfilter</command>は 以下のコマンドラインオプションを用意しています:

note: Tag: para
en: Do not generate empty revisions at all&mdash;just omit them.
ja: 空のリビジョンを生成しません&mdash; 単に無視します。

note: Tag: para
en: If empty revisions are dropped (using the <option>--drop-empty-revs</option> option), change the revision numbers of the remaining revisions so that there are no gaps in the numeric sequence.
ja: 空のリビジョンが削除された場合に(<option>--drop-empty-revs</option>を 利用することによって)、残っているリビジョンのリビジョン番号を変更して リビジョン番号が飛ばないようにします。

note: Tag: para
en: If empty revisions are not dropped, preserve the revision properties (log message, author, date, custom properties, etc.) for those empty revisions. Otherwise, empty revisions will only contain the original datestamp, and a generated log message that indicates that this revision was emptied by <command>svndumpfilter</command>.
ja: 空のリビジョンが削除されない場合に、それら空のリビジョンに関する リビジョン属性(ログメッセージ、変更者、日付、カスタム属性、など)を 保存します。そうでなければ、空のリビジョンは元のタイムスタンプと、 このリビジョンは<command>svndumpfilter</command>によって空にされた ということを示す自動生成されたログメッセージのみを含むことになります。

note: Tag: para
en: While <command>svndumpfilter</command> can be very useful, and a huge timesaver, there are unfortunately a couple of gotchas. First, this utility is overly sensitive to path semantics. Pay attention to whether paths in your dump file are specified with or without leading slashes. You'll want to look at the <literal>Node-path</literal> and <literal>Node-copyfrom-path</literal> headers.
ja: <command>svndumpfilter</command> は非常に便利で、作業を省力化して くれますが、残念なことにいろいろな問題もあります。まずこのユーティリティー はパスの構文に極端に敏感です。ダンプファイル中のパスが先頭にスラッシュ を含んでいるかどうかに注意してください。<literal>Node-path</literal> と <literal>Copyfrom-path</literal>ヘッダを確認する必要がある かも知れません。

note: Tag: para
en: If the paths have leading slashes, you should include leading slashes in the paths you pass to <command>svndumpfilter include</command> and <command>svndumpfilter exclude</command> (and if they don't, you shouldn't). Further, if your dump file has an inconsistent usage of leading slashes for some reason, <footnote> <para>While <command>svnadmin dump</command> has a consistent leading slash policy&mdash;to not include them&mdash;other programs which generate dump data might not be so consistent.</para> </footnote> you should probably normalize those paths so they all have, or lack, leading slashes.
ja: パスの先頭にスラッシュがある場合、<command>svndumpfilter include</command> と <command>svndumpfilter exclude</command>に渡す パスの先頭にスラッシュを含める必要があります(そして、逆にスラッシュが ないなら含めてはいけません)。さらにダンプファイルの先頭のス ラッシュが何かの理由で矛盾している場合には <footnote> <para> <command>svnadmin dump</command> は先頭スラッシュに関して一貫した ポリシーがありますが&mdash; 付けないようにするというものです&mdash; データをダンプするほかのプログラムはそれほど一貫していません。</para> </footnote> おそらく、すべてをスラッシュ付きにするか、その逆にするような正規化を パスに対して施す必要があります。

note: Tag: title
en: Repository Backup
ja: リポジトリのバックアップ

note: Tag: para
en: Despite numerous advances in technology since the birth of the modern computer, one thing unfortunately rings true with crystalline clarity&mdash;sometimes, things go very, very awry. Power outages, network connectivity dropouts, corrupt RAM and crashed hard drives are but a taste of the evil that Fate is poised to unleash on even the most conscientious administrator. And so we arrive at a very important topic&mdash;how to make backup copies of your repository data.
ja: 現代的なコンピュータが生まれてから技術的には非常に発展してきたものの、 残念なことに、一つのことだけは間違いなく真実です&mdash;ときどき、ものごとは まったく台無しになってしまう、ということです。停電、ネットワーク切断、 RAMの破壊、ハードディスクのクラッシュは、魔物以外の何者でもありません。 運命は最も優れた管理者にさえ降りかかるのです。それで、とても重要な トピックに行き着きます&mdash;どうやってリポジトリのバックアップを とるか、です。

note: Tag: para
en: The resulting backup is a fully functional Subversion repository, able to be dropped in as a replacement for your live repository should something go horribly wrong.
ja: 結果のバックアップは、完全に機能するSubversionリポジトリで、現行の リポジトリが何かひどいことになったときには、置き換えて使うことが できるものです。

note: Tag: para
en: By now you should have a basic understanding of how to create, configure, and maintain Subversion repositories. We've introduced you to the various tools that will assist you with this task. Throughout the chapter, we've noted common administration pitfalls, and suggestions for avoiding them.
ja: ここまでで、あなたは、どうやってSubversionリポジトリを作成し、設定するか についての基本的な理解ができたはずです。この作業を助けるさまざまなツール を紹介しました。そして、章全体を通じて、管理者がよくハマりそうなことをあげ、 どうやってそれを避けるかを議論しました。

note: Tag: para
en: All that remains is for you to decide what exciting data to store in your repository, and finally, how to make it available over a network. The next chapter is all about networking.
ja: あとは、リポジトリに、どのようなデータを入れ、それをネットワーク越しに 利用できる形にするかを考えるだけです。次の章ではネットワーク利用について 詳述します。

note: Tag: title
en: Server Configuration
ja: サーバの設定

note: Tag: title
en: Overview
ja: 概観

note: Tag: entry
en: Authentication options
ja: 認証オプション

note: Tag: entry
en: HTTP(S) basic auth, X.509 certificates, LDAP, NTLM, or any other mechanism available to Apache httpd
ja: HTTP(S) 基本認証, X.509 認証, LDAP, NTLM, その他 Apache httpd で利用可能な方法

note: Tag: entry
en: User account options
ja: ユーザアカウントオプション

note: Tag: entry
en: private 'users' file
ja: 固有の 'users' ファイル

note: Tag: entry
en: Authorization options
ja: 認可のオプション

note: Tag: entry
en: Encryption
ja: 暗号化

note: Tag: entry
en: via optional SSL
ja: オプションのSSLを経由することで

note: Tag: entry
en: Interoperability
ja: 相互運用性

note: Tag: entry
en: partially usable by other WebDAV clients
ja: 部分的に他の WebDAVクライアントからも利用可能

note: Tag: entry
en: Web viewing
ja: ウェブによる参照

note: Tag: entry
en: limited built-in support, or via 3rd-party tools such as ViewVC
ja: 制限された組み込みサポート機能、あるいは ViewCVS のような サードパーティーのツール経由

note: Tag: entry
en: Speed
ja: スピード

note: Tag: entry
en: somewhat slower
ja: やや遅い

note: Tag: entry
en: somewhat faster
ja: やや速い

note: Tag: entry
en: <entry>Initial setup</entry>
ja: <entry>初期設定</entry>

note: Tag: entry
en: somewhat complex
ja: やや複雑

note: Tag: title
en: The Apache HTTP Server
ja: Apache HTTP サーバ

note: Tag: title
en: svnserve, a custom server
ja: svnserve, 専用サーバ

note: Tag: title
en: Invoking the Server
ja: サーバの起動

note: Tag: para
en: When running <command>svnserve</command> in daemon mode, you can use the <option>--listen-port=</option> and <option>--listen-host=</option> options to customize the exact port and hostname to <quote>bind</quote> to.
ja: デーモンモードで<command>svnserve</command>を実行するときには <option>--listen-port=</option>と <option>--listen-host=</option>オプションで待ち受けポートとホスト 名を<quote>指定</quote>することができます。

note: Tag: para
en: Using the <option>-r</option> option effectively modifies the location that the program treats as the root of the remote filesystem space. Clients then use URLs that have that path portion removed from them, leaving much shorter (and much less revealing) URLs:
ja: <option>-r</option>オプションの利用は リモートファイルシステム空間のルートとしてプログラムが扱う場所 を効果的に変更することができます。この場合クライアントはそのルート までの部分を除いたパスを指定することになり、もっと短い(そしてより情報制限された) URL を利用できます:

note: Tag: para
en: When invoked with the <option>--inetd</option> option, <command>svnserve</command> attempts to speak with a Subversion client via <emphasis>stdin</emphasis> and <emphasis>stdout</emphasis> using a custom protocol. This is the standard behavior for a program being run via <command>inetd</command>. The IANA has reserved port 3690 for the Subversion protocol, so on a Unix-like system you can add lines to <filename>/etc/services</filename> like these (if they don't already exist):
ja: <option>--inetd</option> オプション付きで起動すると <command>svnserve</command> はSubversion クライアントとの間 で、専用のプロトコルを使い、<emphasis>stdin</emphasis>と <emphasis>stdout</emphasis>チャンネル経由で通信しようとします。 これは<command>inetd</command>を経由して 実行されるプログラムの標準的な振る舞い方です。IANAはポート3690 をSubversion プロトコルのために予約しているため Unix風のシステム上 なら<filename>/etc/services</filename>ファイルに(もしまだ追加されていない のなら)以下の行を追加することができます:

note: Tag: para
en: And if your system is using a classic Unix-like <command>inetd</command> daemon, you can add this line to <filename>/etc/inetd.conf</filename>:
ja: そしてもし伝統的な Unix風の<command>inetd</command>デーモンを使って いるのなら <filename>/etc/inetd.conf</filename>に以下のような行を 追加することができます:

note: Tag: title
en: Built-in authentication and authorization
ja: 組み込みの認証と認可

note: Tag: para
en: When a client connects to an <command>svnserve</command> process, the following things happen:
ja: クライアントが<command>svnserve</command>プロセスに接続する とき、以下のことが起こります:

note: Tag: para
en: The client selects a specific repository.
ja: クライアントは特定のリポジトリを選択します。

note: Tag: para
en: The server processes the repository's <filename>conf/svnserve.conf</filename> file, and begins to enforce any authentication and authorization policies defined therein.
ja: サーバはリポジトリの <filename>conf/svnserve.conf</filename> ファイルを処理しその中に定義されている認証と認可の方式に強制的に 従います。

note: Tag: para
en: Depending on the situation and authorization policies,
ja: そのときの状況と認可の方式により、以下のどれかになります。

note: Tag: para
en: the client may be allowed to make requests anonymously, without ever receiving an authentication challenge, OR
ja: クライアントは要求を匿名で行うことができ、どのような認証確認も 要求されないか、

note: Tag: para
en: the client may be challenged for authentication at any time, OR
ja: クライアントは常に認証許可を求められるか、

note: Tag: para
en: if operating in <quote>tunnel mode</quote>, the client will declare itself to be already externally authenticated.
ja: もし"トンネルモード"で実行されている場合であれば、クライアント は既に外部的に認証されたことを宣言するか、です。

note: Tag: para
en: It's also possible, of course, for the client to be externally authenticated via a tunnel agent, such as <command>SSH</command>. In that case, the server simply examines the user it's running as, and uses it as the authenticated username. For more on this, see <xref linkend="svn.serverconfig.svnserve.sshauth"/>.
ja: もちろんクライアントはトンネルエージェント、たとえば <command>SSH</command>のようなものを経由して外部的に 認証することもできます。この場合サーバは単に実行している ユーザを確認し、それを認証されたユーザ名であるとして 利用します。より詳しくは <xref linkend="svn.serverconfig.svnserve.sshauth"/>を見てください。

note: Tag: title
en: Create a 'users' file and realm
ja: ユーザファイルと認証範囲の作成

note: Tag: para
en: The <literal>realm</literal> is a name that you define. It tells clients which sort of <quote>authentication namespace</quote> they're connecting to; the Subversion client displays it in the authentication prompt, and uses it as a key (along with the server's hostname and port) for caching credentials on disk (see <xref linkend="svn.serverconfig.netmodel.credcache"/>). The <literal>password-db</literal> variable points to a separate file that contains a list of usernames and passwords, using the same familiar format. For example:
ja: <literal>realm</literal> は自分で定義できる名前です。 それはクライアントに接続先の<quote>認証用の名前空間</quote>の種別を伝えます; Subversion クライアントは認証プロンプトでそれを表示し、ディスク上の キャッシュされた証明のキーとして(サーバのホスト名、ポートと共に) 利用します。(<xref linkend="svn.serverconfig.netmodel.credcache"/>参照。) <literal>password-db</literal>変数はユーザ名称とパスワードのリスト を含む個別のファイルを指す変数で、やはり同じ形式が利用されます。 たとえば:

note: Tag: para
en: The value of <literal>password-db</literal> can be an absolute or relative path to the users file. For many admins, it's easy to keep the file right in the <filename>conf/</filename> area of the repository, alongside <filename>svnserve.conf</filename>. On the other hand, it's possible you may want to have two or more repositories share the same users file; in that case, the file should probably live in a more public place. The repositories sharing the users file should also be configured to have the same realm, since the list of users essentially defines an authentication realm. Wherever the file lives, be sure to set the file's read and write permissions appropriately. If you know which user(s) <command>svnserve</command> will run as, restrict read access to the user file as necessary.
ja: <literal>password-db</literal> の値はユーザファイルの相対または 絶対パスです。多くの管理者にとって、<filename>svnserve.conf</filename> に従ったリポジトリの <filename>conf/</filename>領域にファイルを 正しく保つのは容易なことです。一方、同じユーザファイルを共有するような 二つ以上のリポジトリがほしいこともあります; そのような場合は ファイルは多分もっと公開された場所に移動すべきでしょう。ユーザファイルを共有 するリポジトリは同じ認証範囲を持つよう設定されていなくてはならず、それは ユーザ全逸ｳ器ｺ本質的にただ一つの認証範囲を定義するためです。 ファイルがある場所であればどこでもファイルの読み書きパーミッション を正しく設定してください。もし <command>svnserve</command>を どのユーザが実行しているかわかるのであれば、必要に応じて ユーザファイルに対する読み出しアクセス制限をかけてください。

note: Tag: title
en: Set access controls
ja: アクセス制御の設定

note: Tag: para
en: The example settings are, in fact, the default values of the variables, should you forget to define them. If you want to be even more conservative, you can block anonymous access completely:
ja: この例としての設定は、実際にはこれらの変数のデフォルト値なので定義 しなくても問題ありません。もしさらに保守的に設定したいのなら、 匿名のアクセスを完全に遮断することもできます:

note: Tag: para
en: <command>svnserve</command>'s built-in authentication can be very handy, because it avoids the need to create real system accounts. On the other hand, some administrators already have well-established SSH authentication frameworks in place. In these situations, all of the project's users already have system accounts and the ability to <quote>SSH into</quote> the server machine.
ja: <command>svnserve</command>の組み込み認証は非常に使いやすいものですが、 それは本当のシステム上のアカウントを作る必要がないからです。一方 管理者によっては既に確立された SSH 認証の仕組みを運用しているかも 知れません。そのような場合、プロジェクトユーザのすべてはシステムアカウント を持っており、サーバマシンに対して <quote>SSH による</quote> アクセスが可能なはず です。

note: Tag: para
en: The important thing to understand here is that the Subversion client is <emphasis>not</emphasis> connecting to a running <command>svnserve</command> daemon. This method of access doesn't require a daemon, nor does it notice one if present. It relies wholly on the ability of <command>ssh</command> to spawn a temporary <command>svnserve</command> process, which then terminates when the network connection is closed.
ja: ここで重要なのは Subversion クライアントは<command>svnserve</command> デーモンに接続するわけ<emphasis>ではない</emphasis>ということです。 このアクセス方法はデーモンは不要で、存在しているかどうかを知る必要も ありません。実際には <command>ssh</command>が一時的に起動する <command>svnserve</command> プロセスにだけ依存していて、ネットワーク接続が閉じるとそのプロセスも終了します。

note: Tag: para
en: When using <literal>svn+ssh://</literal> URLs to access a repository, remember that it's the <command>ssh</command> program prompting for authentication, and <emphasis>not</emphasis> the <command>svn</command> client program. That means there's no automatic password caching going on (see <xref linkend="svn.serverconfig.netmodel.credcache"/>). The Subversion client often makes multiple connections to the repository, though users don't normally notice this due to the password caching feature. When using <literal>svn+ssh://</literal> URLs, however, users may be annoyed by <command>ssh</command> repeatedly asking for a password for every outbound connection. The solution is to use a separate SSH password-caching tool like <command>ssh-agent</command> on a Unix-like system, or <command>pageant</command> on Windows.
ja: <literal>svn+ssh://</literal>の URL を使ってリポジトリにアクセスする 場合、認証を要求するのは<command>ssh</command>プログラムであり <command>svn</command>クライアントプログラムではないことを思い出して ください。これは自動的なパスワードのキャッシュが起きないことを 意味します(<xref linkend="svn.serverconfig.netmodel.credcache"/>を見てください)。 Subversion クライアントはリポジトリに複数の接続を張ることもよくあります がユーザはパスワードキャッシュの仕組みによって通常そのことに気づくことは ありません。しかし <literal>svn+ssh://</literal> URL を使う場合には ユーザは接続ごとに <command>ssh</command>が繰り返しパスワードをうながす ことに悩ませられるかも知れません。解決策は Unix 風のシステムなら <command>ssh-agent</command>、Windows なら <command>pageant</command> のような独立した SSH パスワードキャッシュツールを利用することです。

note: Tag: para
en: This example demonstrates a couple of things. First, it shows how to make the Subversion client launch a very specific tunneling binary (the one located at <filename>/opt/alternate/ssh</filename>) with specific options. In this case, accessing a <literal>svn+joessh://</literal> URL would invoke the particular SSH binary with <option>-p 29934</option> as arguments&mdash;useful if you want the tunnel program to connect to a non-standard port.
ja: この例はいろいろなことの参考になります。まずそれはどのようにして Subversion クライアントが非常に特殊なトンネリングのためのプログラムを 特定のオプション付きで起動するかを示しています(この場合それは <filename>/opt/alternate/ssh</filename>にあります)。 この場合<literal>svn+joessh://</literal> URLにアクセスすると 引数として<option>-p 29934</option>の付いた特定のSSHプログラム が起動されるでしょう&mdash; もし標準ではないポートにトンネルプログラム を接続したいと考えているならこれは便利です。

note: Tag: para
en: Second, it shows how to define a custom environment variable that can override the name of the tunneling program. Setting the <literal>SVN_SSH</literal> environment variable is a convenient way to override the default SSH tunnel agent. But if you need to have several different overrides for different servers, each perhaps contacting a different port or passing a different set of options to SSH, you can use the mechanism demonstrated in this example. Now if we were to set the <literal>JOESSH</literal> environment variable, its value would override the entire value of the tunnel variable&mdash;<command>$JOESSH</command> would be executed instead of <command>/opt/alternate/ssh -p 29934</command>.
ja: 次にそれはどのように してトンネルプログラムの名前を上書きする環境変数を定義してやれば 良いかを示しています。 <literal>SVN_SSH</literal>環境変数を設定するのはデフォルトの SSH トンネル エージェントを上書きする便利な方法です。 しかしもし異なるサーバ上でいくつもの異なる上書きが必要で、それぞれが 異なるポートや異なるオプションを SSH に渡しているような場合には、この例で 示すような仕組みを利用することができます。 もし<literal>JOESSH</literal>環境変数を設定 してあれば、その値はトンネル変数全体を上書きします&mdash; <command>$JOESSH</command>は <command>/opt/alternate/ssh -p 29934</command>のかわりに実行 されるでしょう。

note: Tag: title
en: SSH configuration tricks
ja: SSH 設定の技法

note: Tag: para
en: It's not only possible to control the way in which the client invokes <command>ssh</command>, but also to control the behavior of <command>sshd</command> on your server machine. In this section, we'll show how to control the exact <command>svnserve</command> command executed by <command>sshd</command>, as well as how to have multiple users share a single system account.
ja: クライアントが <command>ssh</command>を起動する方法を制御できるだけ ではなく、サーバマシン上の <command>sshd</command>の動作の仕方も 制御することができます。この節では <command>sshd</command> によって起動される <command>svnserve</command>コマンドを正しく制御する 方法を示して、複数のユーザが単一システムアカウントをどのように共有すれば 良いかについて説明します。

note: Tag: title
en: <title>Initial setup</title>
ja: <title>初期設定</title>

note: Tag: para
en: To begin, locate the home directory of the account you'll be using to launch <command>svnserve</command>. Make sure the account has an SSH public/private keypair installed, and that the user can log in via public-key authentication. Password authentication will not work, since all of the following SSH tricks revolve around using the SSH <filename>authorized_keys</filename> file.
ja: まず<command>svnserve</command>を起動するのに使うアカウントの ホームディレクトリを用意します。そのアカウントに SSH の公開鍵/秘密鍵 がインストールされていて、ユーザがその公開鍵でログインできることを 確認してください。パスワード認証は動作しなくなりますが、それは以下の SSH の技法を使うと、すべての処理に SSH <filename>authorized_keys</filename>ファイル を使うためです。

note: Tag: para
en: If it doesn't already exist, create the <filename>authorized_keys</filename> file (on Unix, typically <filename>~/.ssh/authorized_keys</filename>). Each line in this file describes a public key that is allowed to connect. The lines are typically of the form:
ja: まだ存在していなければ<filename>authorized_keys</filename>ファイルを 作ってください(Unix では普通 <filename>‾/.ssh/authorized_keys</filename> になります)。このファイルの各行には接続を許す相手先の公開鍵の記述があります。 各行は普通以下のような形をしています:

note: Tag: para
en: When the <literal>command</literal> field is set, the SSH daemon will run the named program instead of the typical <command>svnserve -t</command> invocation that the Subversion client asks for. This opens the door to a number of server-side tricks. In the following examples, we abbreviate the lines of the file as:
ja: <literal>command</literal>フィールドが設定されると 通常の <command>svnserve -t</command> のかわりに SSH デーモンがその名前のプログラムを実行します。このプログラムが Subversion クライアントの接続先になります。これがサーバ上でのいろいろな技法を 可能にする鍵です。以下の例では、ファイル中で次のように行を省略して説明します:

note: Tag: title
en: Controlling the invoked command
ja: 起動コマンドの制御

note: Tag: para
en: Because we can specify the executed server-side command, it's easy to name a specific <command>svnserve</command> binary to run and to pass it extra arguments:
ja: 実行されるサーバ側コマンドを指定することができるので、特定の <command>svnserve</command>バイナリを指定したり、追加の引数を 指定して実行することが簡単にできます:

note: Tag: para
en: In this example, <filename>/path/to/svnserve</filename> might be a custom wrapper script around <command>svnserve</command> which sets the umask (see <xref linkend="svn.serverconfig.multimethod"/>). It also shows how to anchor <command>svnserve</command> in a virtual root directory, just as one often does when running <command>svnserve</command> as a daemon process. This might be done either to restrict access to parts of the system, or simply to relieve the user of having to type an absolute path in the <literal>svn+ssh://</literal> URL.
ja: この例では <filename>/path/to/svnserve</filename>は <command>svnserve</command> に対するカスタマイズされたラッパースクリプ トで、umask を設定するようなものかも知れません(<xref linkend="svn.serverconfig.multimethod"/>を見てください)。それはまた <command>svnserve</command>用の仮想ルートディレクトリをどのように設定 するかも示しています。これはデーモンプロセスとして <command>svnserve</command>する場合によく起こることです。たとえばシス テムの特定の部分にアクセス制限する場合や、単に <literal>svn+ssh://</literal> URL の絶対パス名を入力する手間を省くため であったりします。

note: Tag: para
en: It's also possible to have multiple users share a single account. Instead of creating a separate system account for each user, generate a public/private keypair for each person. Then place each public key into the <filename>authorized_users</filename> file, one per line, and use the <option>--tunnel-user</option> option:
ja: 複数のユーザが単一アカウントを共有するようにもできます。それにはまずユー ザごとに独立したシステムアカウントを作るかわりに、メンバーごとに公開鍵 /秘密鍵のペアを生成します。つぎに一行に公開鍵をひとつづつ <filename>authorized_users</filename> ファイルにおきます。そして <option>--tunnel-user</option> オプションを使うとうまくいきます。

note: Tag: para
en: This example allows both Harry and Sally to connect to the same account via public-key authentication. Each of them has a custom command that will be executed; the <option>--tunnel-user</option> option tells <command>svnserve -t</command> to assume that the named argument is the authenticated user. Without <option>--tunnel-user</option>, it would appear as though all commits were coming from the one shared system account.
ja: この例では Harry も Sally も公開鍵認証方式によって同じアカウントで接続する ように設定しています。どちらもそれぞれにカスタマイズされたコマンドが実行されます; <option>--tunnel-user</option>オプションは <command>svnserve -t</command> が名前つき引数が認証されたユーザであることを認めるように指示しています。 <option>--tunnel-user</option> がなければ、すべてのコミットはひとつの共有された システムアカウントから発行したように見えるようになります。

note: Tag: para
en: A final word of caution: giving a user access to the server via public-key in a shared account might still allow other forms of SSH access, even if you've set the <literal>command</literal> value in <filename>authorized_keys</filename>. For example, the user may still get shell access through SSH, or be able to perform X11 or general port-forwarding through your server. To give the user as little permission as possible, you may want to specify a number of restrictive options immediately after the <literal>command</literal>:
ja: 最後の注意です: 共有アカウントにある公開鍵を経由してユーザにアクセス権を 与えても、他の形の SSH アクセスを禁止したことにはなりません。これは <filename>authorized_keys</filename> に<literal>command</literal>の 形の設定をした場合でもそうです。たとえば、ユーザは依然として SSH 経由で シェルを使ったアクセスができますし、あなたのサーバ経由で X11 や、より 一般的なポートフォワードを実行することもできます。ユーザにできるかぎり わずかな権限しか与えないようにするには <literal>command</literal>の すぐ後にそれぞれの制限オプションを指定する必要があります:

note: Tag: screen
en: command="svnserve -t --tunnel-user=harry",no-port-forwarding,\
               no-agent-forwarding,no-X11-forwarding,no-pty \
               TYPE1 KEY1 harry@example.com
ja: command="svnserve -t --tunnel-user=harry",no-port-forwarding,¥
               no-agent-forwarding,no-X11-forwarding,no-pty ¥
               TYPE1 KEY1 harry@example.com

note: Tag: title
en: httpd, the Apache HTTP server
ja: httpd, Apache HTTP サーバ

note: Tag: para
en: The Apache HTTP Server is a <quote>heavy duty</quote> network server that Subversion can leverage. Via a custom module, <command>httpd</command> makes Subversion repositories available to clients via the WebDAV/DeltaV protocol, which is an extension to HTTP 1.1 (see <ulink url="http://www.webdav.org/"></ulink> for more information). This protocol takes the ubiquitous HTTP protocol that is the core of the World Wide Web, and adds writing&mdash;specifically, versioned writing&mdash;capabilities. The result is a standardized, robust system that is conveniently packaged as part of the Apache 2.0 software, is supported by numerous operating systems and third-party products, and doesn't require network administrators to open up yet another custom port. <footnote> <para>They really hate doing that.</para> </footnote> While an Apache-Subversion server has more features than <command>svnserve</command>, it's also a bit more difficult to set up. With flexibility often comes more complexity.
ja: Apache HTTP Server は <quote>非常にいろいろなことをしてくれる</quote> ネットワークサーバ でSubversionの機能も上げることができます。カスタムモジュールを使って <command>httpd</command>はSubversion リポジトリをWebDAV/DeltaVプロトコル 経由でクライアントから利用可能にします。WebDAV/deltaVプロトコルは HTTP 1.1 の拡張です(<ulink url="http://www.webdav.org/"></ulink> により詳しい情報が あります)。このプロトコルはワールドワイドウェブの核心である、 広く利用可能なHTTP プロトコルに対して、書き込み&mdash;特にバージョン化された 書き込み&mdash;機能を付け加えます。結果は標準化された、堅牢なシステム を構成することができ、それは Apache 2.0 の一部としてパッケージ化されて います。また Apache 2.0 はさまざまなオペレーティングシステムとサード パーティー性製品によってサポートされており、それを利用すればネットワーク 管理者は新たなカスタムポートを開く必要がありません。 <footnote> <para>彼らはそういう作業を本当に嫌います。</para> </footnote> Apache-Subversion サーバは<command>svnserve</command>よりも多くの 機能を持っていますが、セットアップは少し難しくなります。柔軟性には しばしば複雑さがともなうものです。

note: Tag: para
en: Much of the following discussion includes references to Apache configuration directives. While some examples are given of the use of these directives, describing them in full is outside the scope of this chapter. The Apache team maintains excellent documentation, publicly available on their website at <ulink url="http://httpd.apache.org"></ulink>. For example, a general reference for the configuration directives is located at <ulink url=" http://httpd.apache.org/docs-2.0/mod/directives.html"></ulink>.
ja: 以下の議論の多くはApacheの設定ディレクティブへの参照を含んでいます。 いくつかの例はそのようなディレクティブの利用方法になっていますが、 その完全な説明はこの章の範囲外です。Apache チームは非常にすばらしい ドキュメントを管理していて<ulink url="http://httpd.apache.org"></ulink> から自由に参照可能です。たとえば設定ディレクティブの一般的な リファレンスは<ulink url="http://httpd.apache.org/docs-2.0/mod/directives.html"></ulink> にあります。

note: Tag: para
en: Also, as you make changes to your Apache setup, it is likely that somewhere along the way a mistake will be made. If you are not already familiar with Apache's logging subsystem, you should become aware of it. In your <filename>httpd.conf</filename> file are directives that specify the on-disk locations of the access and error logs generated by Apache (the <literal>CustomLog</literal> and <literal>ErrorLog</literal> directives, respectively). Subversion's mod_dav_svn uses Apache's error logging interface as well. You can always browse the contents of those files for information that might reveal the source of a problem that is not clearly noticeable otherwise.
ja: また、Apache の設定を変更する場合、しばしば間違いが起こります。 Apache のログシステムにまだなじみがないのであれば、それに注意すると 良いでしょう。<filename>httpd.conf</filename>ファイルにはApache に よって生成されるアクセスログとエラーログのディスク上での場所を指定する ディレクティブがあります。(それぞれ<literal>CustomLog</literal>と <literal>ErrorLog</literal>という名前です)。Subversion の mod_dav_svn も Apache のエラーログインターフェースを利用しています。これらのファイルは 情報取得のために常に閲覧することができ、ほかの方法でははっきりしない 問題の原因を明らかにするかも知れません。

note: Tag: title
en: Why Apache 2?
ja: なぜ Apache 2 が必要なのか?

note: Tag: para
en: If you're a system administrator, it's very likely that you're already running the Apache web server and have some prior experience with it. At the time of writing, Apache 1.3 is by far the most popular version of Apache. The world has been somewhat slow to upgrade to the Apache 2.X series for various reasons: some people fear change, especially changing something as critical as a web server. Other people depend on plug-in modules that only work against the Apache 1.3 API, and are waiting for a 2.X port. Whatever the reason, many people begin to worry when they first discover that Subversion's Apache module is written specifically for the Apache 2 API.
ja: もしあなたがシステム管理者なのであれば、既に Apache ウェブサーバを 実行しており、かなりの経験を持っているかも知れません。このドキュメント を書いている時点で Apache 1.3 はApache の最も有名なバージョンです。 いくつかの理由で、Apache 2.X 系へのアップグレードは世界的にはゆっくり としか進んでいません: 人によっては変更点、特にウェブサーバにとって 非常に重要な部分についての変更点を怖がります。また Apache 1.3 API で のみ動作するプラグインモジュールに依存していて、2.X 系への移植を待って いるような人もいるでしょう。どんな理由であれ、多くの人々はSubversion のApacheモジュールは Apache 2 API でのみ動作することを最初に知った とき、不安を感じます。

note: Tag: para
en: The proper response to this problem is: don't worry about it. It's easy to run Apache 1.3 and Apache 2 side-by-side; simply install them to separate places, and use Apache 2 as a dedicated Subversion server that runs on a port other than 80. Clients can access the repository by placing the port number into the URL:
ja: この問題に対する正しい反応は: 心配するな、です。Apache 1.3 と Apache 2 は同時に起動することができます: 単に別の場所にインストールし、Apache 2 を 80 以外のポートで実行する Subversion 用のサーバとすれば良いのです。 クライアントはURLにポート番号を指定することでリポジトリにアクセスできます:

note: Tag: title
en: Prerequisites
ja: 必須要件

note: Tag: para
en: To network your repository over HTTP, you basically need four components, available in two packages. You'll need Apache <command>httpd</command> 2.0, the <command>mod_dav</command> DAV module that comes with it, Subversion, and the <command>mod_dav_svn</command> filesystem provider module distributed with Subversion. Once you have all of those components, the process of networking your repository is as simple as:
ja: HTTP 越しにリポジトリにアクセスする場合、基本的には二つのパッケージで利用 可能な四つの部品が必要になります。Apache <command>httpd</command> 2.0、 それに付属している<command>mod_dav</command> DAVモジュール、Subversion、 そしてそれに付属している<command>mod_dav_svn</command>ファイルシステム 提供モジュールです。すべての部品を手に入れてしまえばリポジトリのネットワーク 対応は以下のように簡単です:

note: Tag: para
en: getting httpd 2.0 up and running with the mod_dav module,
ja: httpd 2.0 を起動し、mod_dav モジュール付きで実行する。

note: Tag: para
en: installing the mod_dav_svn plugin to mod_dav, which uses Subversion's libraries to access the repository, and
ja: mod_dav_svn プラグインを mod_dav にインストールする。mod_dav_svn はリポジトリにアクセスするために Subversion のライブラリを利用 します。そして、

note: Tag: para
en: configuring your <filename>httpd.conf</filename> file to export (or expose) the repository.
ja: <filename>httpd.conf</filename>ファイルを設定してリポジトリを 公開する。

note: Tag: para
en: You can accomplish the first two items either by compiling <command>httpd</command> and Subversion from source code, or by installing pre-built binary packages of them on your system. For the most up-to-date information on how to compile Subversion for use with the Apache HTTP Server, as well as how to compile and configure Apache itself for this purpose, see the <filename>INSTALL</filename> file in the top level of the Subversion source code tree.
ja: 最初の二つについては<command>httpd</command>とSubversion を ソースコードからコンパイルするか、自分のシステム用の既にコンパイル 済みのバイナリパッケージをインストールすることによって取得できます。 どのようにして Apache HTTP サーバと共に Subversion をコンパイルするか、 そしてこの目的のために Apache 自身をどのように設定すれば良いかに ついての最新情報は Subversion ソースコードツリーの最上位にある <filename>INSTALL</filename>ファイルを参照してください。

note: Tag: title
en: Basic Apache Configuration
ja: 基本的な Apache の設定

note: Tag: para
en: Once you have all the necessary components installed on your system, all that remains is the configuration of Apache via its <filename>httpd.conf</filename> file. Instruct Apache to load the mod_dav_svn module using the <literal>LoadModule</literal> directive. This directive must precede any other Subversion-related configuration items. If your Apache was installed using the default layout, your <command>mod_dav_svn</command> module should have been installed in the <filename>modules</filename> subdirectory of the Apache install location (often <filename>/usr/local/apache2</filename>). The <literal>LoadModule</literal> directive has a simple syntax, mapping a named module to the location of a shared library on disk:
ja: システム上に必要なすべての部品をインストールしたあとは、<filename>httpd.conf</filename> によって Apache の設定をすることだけが残っています。 <literal>LoadModule</literal> ディレクティブを使って mod_dav_svn モジュールを Apache にロードしてください。この ディレクティブはほかの Subversion 関連の設定項目に先立って指定しなくてはなりません。 Apache がデフォルトレイアウトを使ってインストールされているなら、<command>mod_dav_svn</command> モジュールは Apache インストールディレクトリの<filename>modules</filename>サブディレクトリ 中になければなりません(たいていの場合、<filename>/usr/local/apache2</filename>の ようなディレクトリになります)。<literal>LoadModule</literal>ディレクティブは単純な 構文を持ち、名前の付いたモジュールをディスク上の共有ライブラリの場所に対応付けます:

note: Tag: para
en: Note that if <command>mod_dav</command> was compiled as a shared object (instead of statically linked directly to the <command>httpd</command> binary), you'll need a similar <literal>LoadModule</literal> statement for it, too. Be sure that it comes before the <command>mod_dav_svn</command> line:
ja: <command>mod_dav</command>が ( <command>httpd</command>プログラムに直接静的にリンクされるのではなく) 共有オブジェクトとしてコンパイルされた場合、それに対しても同様の <literal>LoadModule</literal>行が必要になります。 <command>mod_dav_svn</command> 行の前に設定することに注意してください:

note: Tag: para
en: At a later location in your configuration file, you now need to tell Apache where you keep your Subversion repository (or repositories). The <literal>Location</literal> directive has an XML-like notation, starting with an opening tag, and ending with a closing tag, with various other configuration directives in the middle. The purpose of the <literal>Location</literal> directive is to instruct Apache to do something special when handling requests that are directed at a given URL or one of its children. In the case of Subversion, you want Apache to simply hand off support for URLs that point at versioned resources to the DAV layer. You can instruct Apache to delegate the handling of all URLs whose path portions (the part of the URL that follows the server's name and the optional port number) begin with <filename>/repos/</filename> to a DAV provider whose repository is located at <filename>/absolute/path/to/repository</filename> using the following <filename>httpd.conf</filename> syntax:
ja: 次に、設定ファイルの後の場所のどこかで Subversion リポジトリをどこに 置くかを Apache に伝える必要があります。<literal>Location</literal> ディレクティブは XML風の記述で、開始タグで始まり、終了タグで終わる間 にさまざまなほかの設定ディレクティブを書きます。 <literal>Location</literal>ディレクティブの目的は Apache に、指定した URL かそのサブディレクトリである特定の処理をするように指示するためにあります。 Subversion の場合、DAV層で管理するバージョン化された資源のある URL で 処理を単に引き渡すように Apache に指示するだけです。Apache に対して <filename>/repos/</filename>で始まる部分(つまり、URL のサーバ名と 場合によって付随するポート番号文字列の後に続く部分)を持ったすべての URL について、<filename>/absolute/path/to/repository</filename>にある リポジトリを管理する DAV 提供モジュールに引き渡すように指示することが できます。それには以下のような<filename>httpd.conf</filename>構文を使い ます:

note: Tag: para
en: Using the previous syntax, Apache will delegate the handling of all URLs whose path portions begin with <filename>/svn/</filename> to the Subversion DAV provider, which will then assume that any items in the directory specified by the <literal>SVNParentPath</literal> directive are actually Subversion repositories. This is a particularly convenient syntax in that, unlike the use of the <literal>SVNPath</literal> directive, you don't have to restart Apache in order to create and network new repositories.
ja: この構文を使うと Apache は<filename>/svn/</filename>で始まるパス部分 を持つすべての URL を Subversion DAV モジュールに渡しますが、すると このモジュールは<literal>SVNParentPath</literal>によって指定される ディレクトリ中のすべてのアイテムは実際のSubversion リポジトリであると 仮定します。これは<literal>SVNPath</literal>ディレクティブを利用 するのとは違って新しいネットワーク公開用リポジトリを作るたびに Apache を再起動する必要がないのでとても便利です。

note: Tag: title
en: Server Names and the COPY Request
ja: サーバ名と COPY 要求

note: Tag: para
en: Subversion makes use of the <literal>COPY</literal> request type to perform server-side copies of files and directories. As part of the sanity checking done by the Apache modules, the source of the copy is expected to be located on the same machine as the destination of the copy. To satisfy this requirement, you might need to tell mod_dav the name you use as the hostname of your server. Generally, you can use the <literal>ServerName</literal> directive in <filename>httpd.conf</filename> to accomplish this.
ja: Subversion はサーバ側でのファイルやディレクトリのコピーを するために<literal>COPY</literal>要求を利用します。Apache モジュール での信頼性チェックの一環として、コピー元はコピー先と同じマシン上に存在 していなくてはなりません。この要求を満足させるためにはサーバのホスト名 として利用する名前を mod_dav に伝える必要があります。通常これには <filename>httpd.conf</filename>中に<literal>ServerName</literal> ディレクティブを使うことができます。

note: Tag: para
en: If you are using Apache's virtual hosting support via the <literal>NameVirtualHost</literal> directive, you may need to use the <literal>ServerAlias</literal> directive to specify additional names that your server is known by. Again, refer to the Apache documentation for full details.
ja: <literal>NameVirtualHost</literal>ディレクティブを使って Apache の仮想ホスト機能を利用している場合はサーバを特定するための 追加名称を指定するのに<literal>ServerAlias</literal>ディレクティブ を使う必要があるかも知れません。やはり詳細については Apache のドキュメントを参照してください。

note: Tag: para
en: You will need to determine a permission system setup that satisfies Subversion's requirements without messing up any previously existing web page or script installations. This might mean changing the permissions on your Subversion repository to match those in use by other things that Apache serves for you, or it could mean using the <literal>User</literal> and <literal>Group</literal> directives in <filename>httpd.conf</filename> to specify that Apache should run as the user and group that owns your Subversion repository. There is no single correct way to set up your permissions, and each administrator will have different reasons for doing things a certain way. Just be aware that permission-related problems are perhaps the most common oversight when configuring a Subversion repository for use with Apache.
ja: 既に存在しているウェブページやスクリプトの設定に問題を起こさない ように Subversion の要求を満足させるためのパーミッションを決定しなくて なりません。これは Subversion リポジトリを、Apache が既に あなたに対して提供しているほかのサービスと協調するようなパーミッション に変更するか、あるいは<filename>httpd.conf</filename>の中で <literal>User</literal>や<literal>Group</literal>ディレクティブを 使ってSubversion リポジトリを所有しているユーザ・グループで Apache が実行されるべき状態に変更することを意味します。 このための唯一の正しい解法といったものはありませんし、個々の 管理者は正しいやり方をするための異なる理由を持っているはずです。 パーミッションに関連した問題はおそらく Apache を利用した Subversion リポジトリの設定時に一番よく見落とされることであるのに注意してください。

note: Tag: title
en: Authentication Options
ja: 認証オプション

note: Tag: para
en: At this point, if you configured <filename>httpd.conf</filename> to contain something like
ja: この時点で <filename>httpd.conf</filename>を以下のような 感じで設定している場合

note: Tag: para
en: anyone can interactively browse the repository's latest revision simply by pointing their web browser to the repository URL, and
ja: 誰でもリポジトリ URL をブラウザで指定することによってリポジトリの最新 リビジョンを閲覧することができます。そして

note: Tag: para
en: anyone can commit to the repository.
ja: 誰でもそのリポジトリにコミットすることができます。

note: Tag: title
en: Basic HTTP Authentication
ja: 基本 HTTP 認証

note: Tag: para
en: Next, you need to add some more <filename>httpd.conf</filename> directives inside your <literal>Location</literal> block to tell Apache what to do with your new password file. The <literal>AuthType</literal> directive specifies the type of authentication system to use. In this case, we want to specify the <literal>Basic</literal> authentication system. <literal>AuthName</literal> is an arbitrary name that you give for the authentication domain. Most browsers will display this name in the pop-up dialog box when the browser is querying the user for his name and password. Finally, use the <literal>AuthUserFile</literal> directive to specify the location of the password file you created using <command>htpasswd</command>.
ja: 次に新しいパスワードファイルを何に利用するかというのを Apache に伝える ため、 <literal>Location</literal>ブロック内部で追加の <filename>httpd.conf</filename> ディレクティブが必要になります。 <literal>AuthType</literal>ディレクティブは 利用する認証システムのタイプを指定します。今回は<literal>Basic</literal> 認証システムを指定したいと思います。<literal>AuthName</literal>は 任意の名前で認証ドメインを与えるためのものです。ほとんどのブラウザは ユーザに名前とパスワードを問い合わせるときにこの名前をポップアップダイアログ ボックス中に表示します。最後に<literal>AuthUserFile</literal>ディレクティブは <command>htpasswd</command>で作ったパスワードファイルの場所を指定します。

note: Tag: para
en: After adding these three directives, your <literal>&lt;Location&gt;</literal> block should look something like this:
ja: 三つのディレクティブを追加した後では、あなたの <literal>&lt;Location&gt;</literal> ブロックは以下のような感じになっていることでしょう:

note: Tag: para
en: This <literal>&lt;Location&gt;</literal> block is not yet complete, and will not do anything useful. It's merely telling Apache that whenever authorization is required, Apache should harvest a username and password from the Subversion client. What's missing here, however, are directives that tell Apache <emphasis>which</emphasis> sorts of client requests require authorization. Wherever authorization is required, Apache will demand authentication as well. The simplest thing to do is protect all requests. Adding <literal>Require valid-user</literal> tells Apache that all requests require an authenticated user:
ja: この <literal>&lt;Location&gt;</literal> ブロックはまだ完成しておらず 役に立つことは何もしません。単に Apache に対して、認証が要求されるとき には常にSubversion クライアントからユーザ名とパスワードを取得するように 言うだけです。しかしここで欠けているのは Apache に対して<emphasis>どのような </emphasis>種類のクライアント要求が認証で必要とされるのかを言うための ディレクティブです。これをやるのに最も簡単な方法はすべてのリクエストを保護 するこです。<literal>Require valid-user</literal> の追加は Apache に対して すべてのリクエストは認証されたユーザであることを伝えます:

note: Tag: para
en: Be sure to read the next section (<xref linkend="svn.serverconfig.httpd.authz"/>) for more detail on the <literal>Require</literal> directive and other ways to set authorization policies.
ja: 認可のポリシーを設定する <literal>Require</literal>ディレクティブと、その他の方法についての 詳細については次の節(<xref linkend="svn.serverconfig.httpd.authz"/>) を読んでください。

note: Tag: title
en: SSL Certificate Management
ja: SSL 証明書の管理

note: Tag: para
en: Businesses that need to expose their repositories for access outside the company firewall should be conscious of the possibility that unauthorized parties could be <quote>sniffing</quote> their network traffic. SSL makes that kind of unwanted attention less likely to result in sensitive data leaks.
ja: リポジトリを自社ファイアウォールの外にさらす必要のあるビジネス は認可されていない他人が自分たちのネットワークデータを<quote>盗聴</quote> しているかも知れないということを意識すべきです。 SSL はこの手の望ましくない意図が重要なデータの流出に帰結する可能性を 小さなものにします。

note: Tag: para
en: If a Subversion client is compiled to use OpenSSL, then it gains the ability to speak to an Apache server via <literal>https://</literal> URLs. The Neon library used by the Subversion client is not only able to verify server certificates, but can also supply client certificates when challenged. When the client and server have exchanged SSL certificates and successfully authenticated one another, all further communication is encrypted via a session key.
ja: Subversion クライアントが OpenSSL を使ってコンパイルされた場合、<literal>https://</literal> URL を使って Apache サーバと通信する能力を得ます。Subversion クライアントで 利用される Neon ライブラリはサーバ証明書を検証することができるだけ ではなく、確認要求を受けた場合には自分の証明書を提示する能力も持って います。クライアントとサーバが SSL 証明書を交換しお互いの認証に成功 すれば、その後のすべての通信はセッションキーによって暗号化されます。

note: Tag: para
en: It's beyond the scope of this book to describe how to generate client and server certificates, and how to configure Apache to use them. Many other books, including Apache's own documentation, describe this task. But what <emphasis>can</emphasis> be covered here is how to manage server and client certificates from an ordinary Subversion client.
ja: どのようにしてクライアントとサーバ証明書を生成するか、またその証明書を 利用するようにどうやって Apache を設定するかについてはこの本の範囲外です。 Apache 自身のドキュメントを含め、さまざまな本でこの方法を説明しています。 ここでは通常の Subversion クライアントでのサーバとクライアント証明書を どのように管理するかについて説明します。

note: Tag: para
en: When speaking to Apache via <literal>https://</literal>, a Subversion client can receive two different types of information:
ja: <literal>https://</literal>経由で Apache と通信する場合、Subversion クライアントは二つの異なるタイプの情報を受け取ることができます:

note: Tag: para
en: a server certificate
ja: サーバ証明書

note: Tag: para
en: a demand for a client certificate
ja: クライアント証明書の提示要求

note: Tag: para
en: If the client receives a server certificate, it needs to verify that it trusts the certificate: is the server really who it claims to be? The OpenSSL library does this by examining the signer of the server certificate, or <firstterm>certifying authority</firstterm> (CA). If OpenSSL is unable to automatically trust the CA, or if some other problem occurs (such as an expired certificate or hostname mismatch), the Subversion command-line client will ask you whether you want to trust the server certificate anyway:
ja: クライアントがサーバ証明書を受け取った場合、それが信頼できるものであるか どうかの検証が必要になります: サーバは本当に名乗っているそのサーバなの でしょうか? OpenSSL ライブラリはサーバ証明書にサインした者、あるいは <firstterm>認証期間</firstterm> (CA)を調べることでこれを確認します。もし OpenSSL が自動的に CA を信用することができないか、他の問題が起きた 場合(たとえば、証明書の有効期間が過ぎていたり、ホスト名が一致していない 場合など)、Subversion コマンドラインクライアントはそのサーバ証明書を とにかく信用するかどうかをユーザに聞いてきます:

note: Tag: para
en: Your run-time <filename>servers</filename> file also gives you the ability to make your Subversion client automatically trust specific CAs, either globally or on a per-host basis. Simply set the <literal>ssl-authority-files</literal> variable to a semicolon-separated list of PEM-encoded CA certificates:
ja: 実行時<filename>servers</filename>ファイルもSubversion クライアントが自動的に 特定の CA を信頼するように設定することができます。すべてのものについて そうすることもできますし、ホストごとにすることもできます。 単に<literal>ssl-authority-files</literal>を、 PEM で暗号化された CA 証明書をセミコロンで区切ったリストに設定してください:

note: Tag: para
en: Many OpenSSL installations also have a pre-defined set of <quote>default</quote> CAs that are nearly universally trusted. To make the Subversion client automatically trust these standard authorities, set the <literal>ssl-trust-default-ca</literal> variable to <literal>true</literal>.
ja: 多くの OpenSSL の設定ではほとんど無制限に信頼する <quote>default</quote> CA が、あらかじめ設定されています。Subversion クライアントにそのような 標準的な認証機関を信用させるためには<literal>ssl-trust-default-ca</literal> 変数を<literal>true</literal>に設定してください。

note: Tag: para
en: When talking to Apache, a Subversion client might also receive a challenge for a client certificate. Apache is asking the client to identify itself: is the client really who it says it is? If all goes correctly, the Subversion client sends back a private certificate signed by a CA that Apache trusts. A client certificate is usually stored on disk in encrypted format, protected by a local password. When Subversion receives this challenge, it will ask you for both a path to the certificate and the password which protects it:
ja: Apache と通信する際、Subversion クライアントはクライアント証明書の 確認要求を受けるかも知れません。Apache はクライアントに対して自分自身を 証明するようにたずねます: あんたは本当にあんたなのか? もしすべてが正し ければ Subversion クライアントはApache が信用している CA によってサイン されたプライベート証明書を送り返します。クライアント証明書は通常 暗号化された形式でディスク中に保管され、ローカルパスワードによって 保護されています。Subversion がこの確認要求を受けた場合、あなたは 証明書のパスと、それを保護しているパスワードについて聞かれます:

note: Tag: para
en: Notice that the client certificate is a <quote>p12</quote> file. To use a client certificate with Subversion, it must be in PKCS#12 format, which is a portable standard. Most web browsers are already able to import and export certificates in that format. Another option is to use the OpenSSL command-line tools to convert existing certificates into PKCS#12.
ja: クライアント証明書は <quote>p12</quote>形式のファイル であることに注意してください。クライアント証明書を Subversion で利用する場合、それは標準的な PKCS#12 フォーマットでなければなりません。 ほとんどのウェブブラウザは既にその形式の証明書をインポートしたり エクスポートしたりすることができます。他の方法としては既存の証明書 をOpenSSLのコマンドラインツールによってPKCS#12形式に変換するという ものです:

note: Tag: para
en: Again, the runtime <filename>servers</filename> file allows you to automate this challenge on a per-host basis. Either or both pieces of information can be described in runtime variables:
ja: ここでも実行時<filename>servers</filename>ファイルはホスト単位で この確認要求を自動化することを認めています。そのような情報は 実行時変数で指定できます:

note: Tag: para
en: Once you've set the <literal>ssl-client-cert-file</literal> and <literal>ssl-client-cert-password</literal> variables, the Subversion client can automatically respond to a client certificate challenge without prompting you.
ja: いったん<literal>ssl-client-cert-file</literal>と <literal>ssl-client-cert-password</literal>変数を 設定すれば、Subversion クライアントはユーザに問い合わせることなしに 自動的にクライアント証明書の確認要求に応答することができるようになります。

note: Tag: para
en: More security-conscious folk might not want to store the client certificate password in the runtime <filename>servers</filename> file.
ja: セキュリティーにもっと神経質な人はクライアント証明書用パスワード を実行時<filename>servers</filename>ファイルに格納するのを嫌がる でしょう。

note: Tag: title
en: Authorization Options
ja: 認可のオプション

note: Tag: para
en: At this point, you've configured authentication, but not authorization. Apache is able to challenge clients and confirm identities, but it has not been told how to allow or restrict access to the clients bearing those identities. This section describes two strategies for controlling access to your repositories.
ja: ここまでのところで、すでに認証についての設定は完了しました が認可はまだです。Apache はクライアントを試し、本当のクライアン トであることを確認することができますが、これらの認証済みクライアントそれ ぞれにどのようなアクセスを許し、また制限するかについてはまだ説明 していません。この節ではリポジトリに対してアクセス制御するための 二つの方法について説明します。

note: Tag: title
en: Blanket Access Control
ja: 全面的なアクセス制御

note: Tag: para
en: The simplest form of access control is to authorize certain users for either read-only access to a repository, or read/write access to a repository.
ja: アクセス制御の一番簡単な方法は特定のユーザをリポジトリに対して読み出し 専用、あるいは読み書き可能として認可することです。

note: Tag: para
en: You can restrict access on all repository operations by adding the <literal>Require valid-user</literal> directive to your <literal>&lt;Location&gt;</literal> block. Using our previous example, this would mean that only clients that claimed to be either <literal>harry</literal> or <literal>sally</literal>, and provided the correct password for their respective username, would be allowed to do anything with the Subversion repository:
ja: <literal>&lt;Location&gt;</literal>ブロックに<literal>Require valid-user</literal> ディレクティブを追加することによってすべてのリポジトリ操作にアクセス制限を 設けることができます。前の例を使うと、これは<literal>harry</literal>、 <literal>sally</literal>、あるいはユーザごとの正しいパスワードを入力した 人だけに、Subversion リポジトリに対する任意の操作を許すというものです:

note: Tag: para
en: Sometimes you don't need to run such a tight ship. For example, Subversion's own source code repository at <ulink url="http://svn.collab.net/repos/svn"></ulink> allows anyone in the world to perform read-only repository tasks (like checking out working copies and browsing the repository with a web browser), but restricts all write operations to authenticated users. To do this type of selective restriction, you can use the <literal>Limit</literal> and <literal>LimitExcept</literal> configuration directives. Like the <literal>Location</literal> directive, these blocks have starting and ending tags, and you would nest them inside your <literal>&lt;Location&gt;</literal> block.
ja: しばしばそのような厳しい設定は不要です。たとえば Subversion 自身の ソースコードリポジトリは<ulink url="http://svn.collab.net/repos/svn"></ulink> にありますが、世界中の誰でも読み出しアクセスすることが可能です( それはチェックアウトしたり、ウェブブラウザでリポジトリを閲覧する ような操作です)が、書き込み操作は認証されたユーザにのみ許されています。 この手の制限を付与するには <literal>Limit</literal>と <literal>LimitExcept</literal>設定ディレクティブを使うことができます。 <literal>Location</literal>ディレクティブのように、この二つの ブロックは開始タグと終了タグがあり、 <literal>&lt;Location&gt;</literal> ブロック中でネストすることができます。

note: Tag: para
en: The parameters present on the <literal>Limit</literal> and <literal>LimitExcept</literal> directives are HTTP request types that are affected by that block. For example, if you wanted to disallow all access to your repository except the currently supported read-only operations, you would use the <literal>LimitExcept</literal> directive, passing the <literal>GET</literal>, <literal>PROPFIND</literal>, <literal>OPTIONS</literal>, and <literal>REPORT</literal> request type parameters. Then the previously mentioned <literal>Require valid-user</literal> directive would be placed inside the <literal>&lt;LimitExcept&gt;</literal> block instead of just inside the <literal>&lt;Location&gt;</literal> block.
ja: <literal>Limit</literal>と<literal>LimitExcept</literal>ディレクティブ に現れるパラメータは HTTP 要求タイプで、そのブロック全体に影響を 与えます。たとえば、現在サポートされている読み出しのみの操作を 除くすべてのリポジトリアクセスを禁止したい場合、<literal>LimitExcept</literal> ディレクティブが、<literal>GET</literal>、<literal>PROPFIND</literal>、 <literal>OPTIONS</literal>、そして<literal>REPORT</literal>要求タイプ パラメータを渡す形で利用できます。そして既に触れた<literal>Require valid-user</literal> ディレクティブを、単に<literal>&lt;Location&gt;</literal>ブロックの中に 置くかわりに、<literal>&lt;LimitExcept&gt;</literal>ブロックの中に置く形に なります。

note: Tag: para
en: These are only a few simple examples. For more in-depth information about Apache access control and the <literal>Require</literal> directive, take a look at the <literal>Security</literal> section of the Apache documentation's tutorials collection at <ulink url="http://httpd.apache.org/docs-2.0/misc/tutorials.html"></ulink>.
ja: このようなことは単純な例にすぎません。Apache のアクセス制御と <literal>Require</literal>ディレクティブについてのさらに詳しい情報 は<ulink url="http://httpd.apache.org/docs-2.0/misc/tutorials.html"></ulink> にある Apache ドキュメントチュートリアルの<literal>Security</literal> セクションを見てください。

note: Tag: title
en: Per-Directory Access Control
ja: ディレクトリごとのアクセス制御

note: Tag: para
en: It's possible to set up finer-grained permissions using a second Apache httpd module, <command>mod_authz_svn</command>. This module grabs the various opaque URLs passing from client to server, asks <command>mod_dav_svn</command> to decode them, and then possibly vetoes requests based on access policies defined in a configuration file.
ja: 第二の Apache httpd モジュールである <command>mod_authz_svn</command> を使うと、より詳細なパーミッションの設定が可能です。このモジュールは クライアントからサーバに送信されるさまざまな裸の URL を取得し、 <command>mod_dav_svn</command>にそれを解析するように要求し、設定ファイル で定義されたアクセス方式に基づき必要に応じてアクセスを拒否します。

note: Tag: para
en: If you've built Subversion from source code, <command>mod_authz_svn</command> is automatically built and installed alongside <command>mod_dav_svn</command>. Many binary distributions install it automatically as well. To verify that it's installed correctly, make sure it comes right after <command>mod_dav_svn</command>'s <literal>LoadModule</literal> directive in <filename>httpd.conf</filename>:
ja: Subversion をソースコードから構築した場合は<command>mod_authz_svn</command> は自動的に<command>mod_dav_svn</command>のそばにインストールされます。 多くのバイナリ配布でもやはり自動的にインストールします。正しくインストール されているかどうかを確認するには<filename>httpd.conf</filename> にある、<command>mod_dav_svn</command>の<literal>LoadModule</literal> ディレクティブのすぐ後に来ていることを確認してください:

note: Tag: para
en: To activate this module, you need to configure your <literal>Location</literal> block to use the <literal>AuthzSVNAccessFile</literal> directive, which specifies a file containing the permissions policy for paths within your repositories. (In a moment, we'll discuss the format of that file.)
ja: このモジュールを有効にするには <literal>AuthzSVNAccessFile</literal> ディレクティブを使うために<literal>Location</literal>ブロックを 設定する必要があります。このディレクティブはリポジトリにある パスのパーミッションが書かれたファイルを指定します。(すぐあとで このファイルの形式について議論します。)

note: Tag: para
en: Apache is flexible, so you have the option to configure your block in one of three general patterns. To begin, choose one of these basic configuration patterns. (The examples below are very simple; look at Apache's own documentation for much more detail on Apache authentication and authorization options.)
ja: Apache は柔軟なので三つの一般的なパターンのどれかにブロックを 設定することができます。まず基本的な設定パターンの一つを選びます。 (以下の例は非常に単純です; Apache の認証と認可の設定の詳細に ついては Apache 自身のドキュメントを参照してください。)

note: Tag: para
en: The simplest block is to allow open access to everyone. In this scenario, Apache never sends authentication challenges, so all users are treated as <quote>anonymous</quote>.
ja: 最も単純なブロックはすべての人に対して自由にアクセスすることを 許すものです。このやり方では Apache は認証要求を送信することは ないのですべてのユーザは<quote>匿名</quote>として扱われます。

note: Tag: title
en: A sample configuration for anonymous access.
ja: 匿名アクセスの設定例。

note: Tag: para
en: On the opposite end of the paranoia scale, you can configure your block to demand authentication from everyone. All clients must supply credentials to identify themselves. Your block unconditionally requires authentication via the <literal>Require valid-user</literal> directive, and defines a means to authenticate.
ja: この対極にある設定方法として、すべての人にたいして認証要求するための ブロックを設定することもできます。すべてのクライアントは自身を特定 するための証明を送る必要があります。ブロックは<literal>Require valid-user</literal> ディレクティブによって無条件に認証を要求し、またその方法を定義します。

note: Tag: title
en: A sample configuration for authenticated access.
ja: 認証つきアクセスの設定例。

note: Tag: para
en: A third very popular pattern is to allow a combination of authenticated and anonymous access. For example, many administrators want to allow anonymous users to read certain repository directories, but want only authenticated users to read (or write) more sensitive areas. In this setup, all users start out accessing the repository anonymously. If your access control policy demands a real username at any point, Apache will demand authentication from the client. To do this, you use both the <literal>Satisfy Any</literal> and <literal>Require valid-user</literal> directives together.
ja: 三番目の非常に一般的な方法は認証つきアクセスと匿名アクセスの組合せ によるものです。たとえば多くの管理者はあるリポジトリのディレクトリを 誰でも読めるようにしたいが、もっと重要な場所については認証された ユーザのみが読めるように(あるいは書き込めるように)したいと考えます。 このような設定ではすべてのユーザはまずは匿名でリポジトリにアクセスし ます。ある時点で本当のユーザ名を要求しなくてはならないアクセスが 発生すると、Apache はクライアントから認証を要求します。このためには <literal>Satisfy Any</literal>ディレクティブと <literal>Require valid-user</literal>ディレクティブの両方を使います。

note: Tag: title
en: A sample configuration for mixed authenticated/anonymous access.
ja: 認証つき/匿名の両方でアクセスする場合の設定例。

note: Tag: title
en: Disabling Path-based Checks
ja: パス名にもとづいたチェックの禁止

note: Tag: para
en: The <command>mod_dav_svn</command> module goes through a lot of work to make sure that data you've marked <quote>unreadable</quote> doesn't get accidentally leaked. This means that it needs to closely monitor all of the paths and file-contents returned by commands like <command>svn checkout</command> or <command>svn update</command> commands. If these commands encounter a path that isn't readable according to some authorization policy, then the path is typically omitted altogether. In the case of history or rename tracing&mdash;e.g. running a command like <command>svn cat -r OLD foo.c</command> on a file that was renamed long ago&mdash;the rename tracking will simply halt if one of the object's former names is determined to be read-restricted.
ja: <command>mod_dav_svn</command>モジュールには、<quote>読み込み禁止</quote> のしるし がついたデータが間違って外部に漏れないようにいろいろな工夫がしてありま す。これは、 <command>svn checkout</command> や <command>svn update</command> のようなコマンドからの戻り値となるすべてのパス名とファイルの内容を綿密に チェックする必要があることを意味します。このようなコマンドが認可のポリシーに よって読み込むべきではないファイルパス名に出会うと、通常は完全にそれを 無視します。履歴や名称変更を追うようなコマンドの場合&mdash; 例えばずっと 昔に名称変更されたファイルに対して <command>svn cat -r OLD foo.c</command> のようなコマンドを実行するような場合など&mdash; 名称変更の履歴は、その ようなファイルの以前の名前に読み込み制約がある場合には、単に異常終了して しまいます。

note: Tag: para
en: On the other hand, there's also an escape-hatch of sorts, one which allows you to trade security features for speed. If you're not enforcing any sort of per-directory authorization (i.e. not using <command>mod_authz_svn</command> or similar module), then you can disable all of this path-checking. In your <filename>httpd.conf</filename> file, use the <literal>SVNPathAuthz</literal> directive:
ja: 一方、これに関する逃げ道もやはりあって、セキュリティーよりも効率を重視 するようにも設定できます。ディレクトリごとの認可の仕組みをまったく利用 しないのなら(たとえば <command>mod_authz_svn</command> やそれに類似 のモジュールを使わないのなら)、このパス名に対するチェックを完全に無効に することもできます。<filename>httpd.conf</filename>ファイルで、 <literal>SVNPathAuthz</literal>ディレクティブを使ってください:

note: Tag: para
en: The <literal>SVNPathAuthz</literal> directive is <quote>on</quote> by default. When set <quote>off</quote>, all path-based authorization checking is disabled; <command>mod_dav_svn</command> stops invoking authorization checks on every path it discovers.
ja: <literal>SVNPathAuthz</literal> ディレクティブはデフォルトでは <quote>on</quote> です。 <quote>off</quote> に設定するとすべてのパス名にもとづいた認可のチェックが禁止されます; <command>mod_dav_svn</command>はすべてのパスについて認可のチェックをしなく なります。

note: Tag: title
en: Extra Goodies
ja: おまけ

note: Tag: para
en: We've covered most of the authentication and authorization options for Apache and mod_dav_svn. But there are a few other nice features that Apache provides.
ja: ここまで Apache と mod_dav_svn のための認証と認可のオプショ ンの大部分を説明してきました。しかし Apache が用意している、さらに いくつかのすばらしい機能があります。

note: Tag: title
en: Repository Browsing
ja: リポジトリ閲覧

note: Tag: para
en: Since the URLs do not contain any information about which version of the resource you wish to see, mod_dav_svn will always answer with the youngest version. This functionality has the wonderful side-effect that you can pass around Subversion URLs to your peers as references to documents, and those URLs will always point at the latest manifestation of that document. Of course, you can even use the URLs as hyperlinks from other web sites, too.
ja: URL は見たいと思うリソースのバージョンについての情報は含まれていない ので mod_dav_svn は常に最新のバージョンで答えます。この機能は Subversion URL をドキュメントの参照先として渡すことができ、その URL は常にドキュメントの最新を指すことになる、というすばらしい効果も あります。もちろん他のウェブサイトからのハイパーリンクとして URL を 利用することもできます。

note: Tag: title
en: Can I view older revisions?
ja: 古いリビジョンを表示することはできますか?

note: Tag: para
en: With an ordinary web browser? In one word: nope. At least, not with <command>mod_dav_svn</command> as your only tool.
ja: 普通のウェブブラウザを使って、ですか? それは、ノーです。少なくとも 唯一のツールである<command>mod_dav_svn</command>なしには。

note: Tag: para
en: You generally will get more use out of URLs to versioned files&mdash;after all, that's where the interesting content tends to lie. But you might have occasion to browse a Subversion directory listing, where you'll quickly note that the generated HTML used to display that listing is very basic, and certainly not intended to be aesthetically pleasing (or even interesting). To enable customization of these directory displays, Subversion provides an XML index feature. A single <literal>SVNIndexXSLT</literal> directive in your repository's <literal>Location</literal> block of <filename>httpd.conf</filename> will instruct mod_dav_svn to generate XML output when displaying a directory listing, and to reference the XSLT stylesheet of your choice:
ja: 一般的には、(ディレクトリへのURLに比べて) バージョン化されたファイルへ のURLのほうをよく使うことになるでしょう&mdash;結局のところ、関心のある内容 がありそうな場所は、そこなのですから。 しかし、Subversion のディレクトリ一覧を参照する機会はあるかも知れず、 その場合すぐに一覧表示で生成される HTML は非常に基本的なもので、美の追求 (や、何か面白いことをやらかそうということ)を目的としているわけではないの に気づくでしょう。このディレクトリ一覧をカスタマイズするために、 Subversion は XML インデックス機能を用意しています。 <filename>httpd.conf</filename>中で、リポジトリの<literal>Location</literal> ブロック中で単一の<literal>SVNIndexXSLT</literal>ディレクティブを使うと mod_dav_svn に対して、ディレクトリ一覧表示時に XML 出力を生成し、 好きな XSLT スタイルシートを参照するように設定することができます:

note: Tag: para
en: Using the <literal>SVNIndexXSLT</literal> directive and a creative XSLT stylesheet, you can make your directory listings match the color schemes and imagery used in other parts of your website. Or, if you'd prefer, you can use the sample stylesheets provided in the Subversion source distribution's <filename>tools/xslt/</filename> directory. Keep in mind that the path provided to the <literal>SVNIndexXSLT</literal> directory is actually a URL path&mdash;browsers need to be able to read your stylesheets in order to make use of them!
ja: <literal>SVNIndexXSLT</literal>ディレクティブとクールな XSLT スタイル シートを使ってディレクトリ一覧をウェブサイトのほかの部分で利用されている 色スキーマや画像に一致させることができます。あるいは、もし望むなら Subversion ソース配布中の<filename>tools/xslt/</filename>ディレクトリ にあるサンプルスタイルシートを使うこともできます。 <literal>SVNIndexXSLT</literal> ディレクトリで指定されるパスは実際の URL パスであることに注意してください &mdash; ブラウザはそれを利用するためにはスタイルシートが読める場所に なければなりません!

note: Tag: title
en: Other Features
ja: その他の機能

note: Tag: title
en: Supporting Multiple Repository Access Methods
ja: 複数リポジトリアクセス方法のサポート

note: Tag: para
en: You've seen how a repository can be accessed in many different ways. But is it possible&mdash;or safe&mdash;for your repository to be accessed by multiple methods simultaneously? The answer is yes, provided you use a bit of foresight.
ja: いろいろな異なる方法でどのようにしてリポジトリにアクセスするかを見て きました。しかし、複数の方法で同時にあるリポジトリにアクセスすることは 可能&mdash;あるいは安全に&mdash;なのでしょうか? 答えはイエスです。少し ばかり慎重になる必要はありますが。

note: Tag: para
en: At any given time, these processes may require read and write access to your repository:
ja: ある時刻において、以下のようなプロセスがあなたのリポジトリに対して 読み出しアクセス、あるいは書き込みアクセス要求を出しているかも知れません :

note: Tag: para
en: regular system users connecting to SSH-spawned private <command>svnserve</command> processes (running as themselves) which access the repository;
ja: リポジトリにアクセスするプライベートに SSH-起動された<command>svnserve</command> プロセスに接続する通常のシステムユーザによって:

note: Tag: para
en: an <command>svnserve</command> process&mdash;either a daemon or one launched by <command>inetd</command>&mdash;running as a particular fixed user;
ja: デーモンとして、または<command>inetd</command>によって起動された<command>svnserve</command> プロセスが、特定の固定されたユーザとして実行されることによって:

note: Tag: para
en: an Apache <command>httpd</command> process, running as a particular fixed user.
ja: Apache <command>httpd</command> プロセスが、特定の固定されたユーザとして実行 されることによって

note: Tag: para
en: The most common problem administrators run into is repository ownership and permissions. Does every process (or user) in the previous list have the rights to read and write the Berkeley DB files? Assuming you have a Unix-like operating system, a straightforward approach might be to place every potential repository user into a new <literal>svn</literal> group, and make the repository wholly owned by that group. But even that's not enough, because a process may write to the database files using an unfriendly umask&mdash;one that prevents access by other users.
ja: 管理者が直面する一番よくある問題はリポジトリの所有権とパーミッションです。 上のリストにあるすべてのプロセス(あるいはユーザ)は Berkeley DB ファイルに対する 読み書きの権限を持っていますか? あなたが Unix風のオペレーティングシステム を使っているとして、一番素直な解決方法は、すべての潜在的なリポジトリユーザ を新しい<literal>svn</literal>グループに入れてしまい、リポジトリをその グループによって完全に所有されている形にしてしまうことです。しかし それだけでは十分ではありません。プロセスはデータベースファイルに、排他的な umask で書き込むかも知れません&mdash;それは他のユーザがアクセスするのを 妨害してしまいます。

note: Tag: para
en: So the next step beyond setting up a common group for repository users is to force every repository-accessing process to use a sane umask. For users accessing the repository directly, you can make the <command>svn</command> program into a wrapper script that first sets <command>umask 002</command> and then runs the real <command>svn</command> client program. You can write a similar wrapper script for the <command>svnserve</command> program, and add a <command>umask 002</command> command to Apache's own startup script, <filename>apachectl</filename>. For example:
ja: それでリポジトリユーザの共通グループ設定の後の次のステップはすべてのリポジトリ アクセスプロセスで、正しい umask を使うことです。リポジトリに直接アクセスする ユーザの場合は<command>svn</command>プログラムをくるんでしまうスクリプトを 作り、その先頭で<command>umask 002</command>を設定してから実際の<command>svn</command> クライアントプログラムを実行すれば良いでしょう。同様のラッパースクリプトを <command>svnserve</command>についても書き、Apache の起動スクリプト <filename>apachectl</filename>の先頭にも<command>umask 002</command>コマンドを 追加しましょう。たとえば:

note: Tag: para
en: Another common problem is often encountered on Unix-like systems. As a repository is used, Berkeley DB occasionally creates new log files to journal its actions. Even if the repository is wholly owned by the <command>svn</command> group, these newly created files won't necessarily be owned by that same group, which then creates more permissions problems for your users. A good workaround is to set the group SUID bit on the repository's <filename>db</filename> directory. This causes all newly-created log files to have the same group owner as the parent directory.
ja: また別のよくある問題が Unix風システムではよく起こります。 リポジトリが利用されると BerkeleyDB は必要におうじて新しい ログファイルを作り動作を記録します。リポジトリ自体は 完全に<command>svn</command>グループによって所有されていても このようにして新規に作られたファイルが同じグループによって 所有される必要はありません。これが理由でユーザにとっては また別のパーミッションの問題がおこります。うまい回避策としては リポジトリのある<filename>db</filename>ディレクトリにたいして グループ SUID ビットを立てることです。これによって すべての新たに作成されるログファイルは親ディレクトリと 同じ所有グループになります。

note: Tag: para
en: Once you've jumped through these hoops, your repository should be accessible by all the necessary processes. It may seem a bit messy and complicated, but the problems of having multiple users sharing write-access to common files are classic ones that are not often elegantly solved.
ja: いったんこの問題を乗り越えてしまえば、あなたのリポジトリは すべての必要なプロセスからアクセスすることができるようになって いるはずです。少し面倒で複雑ですが、複数のユーザが書き込みアクセス を共有することで起こる問題は、しばしばきれいに解くことができない 古典的な問題です。

note: Tag: para
en: Fortunately, most repository administrators will never <emphasis>need</emphasis> to have such a complex configuration. Users who wish to access repositories that live on the same machine are not limited to using <literal>file://</literal> access URLs&mdash;they can typically contact the Apache HTTP server or <command>svnserve</command> using <literal>localhost</literal> for the server name in their <literal>http://</literal> or <literal>svn://</literal> URLs. And to maintain multiple server processes for your Subversion repositories is likely to be more of a headache than necessary. We recommend you choose the server that best meets your needs and stick with it!
ja: ありがたいことに、ほとんどのリポジトリ管理者はそのような複雑な 設定をする<emphasis>必要</emphasis>はないでしょう。 同じマシン上にあるリポジトリにアクセスしたいと思うユーザは <literal>file://</literal>アクセス URL を利用することに制限されて いるわけではありません&mdash; <literal>http://</literal>や <literal>svn://</literal>URL中にサーバ名として <literal>localhost</literal> を指定する形でApache HTTP サーバや<command>svnserve</command> を使うこともできるのです。そして複数のサーバプロセスを Subversion リポジトリのために管理することは頭痛の種を増やすだけのことです。 自分のニーズに本当に合ったサーバ構成を選択し、そこにしがみついて 離れない、これがおすすめの方法です!

note: Tag: title
en: The svn+ssh:// server checklist
ja: svn+ssh:// サーバのチェックリスト

note: Tag: para
en: It can be quite tricky to get a bunch of users with existing SSH accounts to share a repository without permissions problems. If you're confused about all the things that you (as an administrator) need to do on a Unix-like system, here's a quick checklist that resummarizes some of things discussed in this section:
ja: パーミッションの問題を回避してリポジトリを共有するように既存の SSH アカウントのある複数のユーザを設定するのはとても技巧的な話しになるかも しれません。Unix風システム上で(管理者として)やらなくてはならない 作業に混乱した時にそなえてこの節で議論した内容をもう１度まとめて チェックリストにしておきます:

note: Tag: title
en: Runtime Configuration Area
ja: 実行時設定領域

note: Tag: para
en: The Subversion <firstterm>configuration area</firstterm> is a two-tiered hierarchy of option names and their values. Usually, this boils down to a special directory that contains <firstterm>configuration files</firstterm> (the first tier), which are just text files in standard INI format (with <quote>sections</quote> providing the second tier). These files can be easily edited using your favorite text editor (such as Emacs or vi), and contain directives read by the client to determine which of several optional behaviors the user prefers.
ja: Subversionの<firstterm>設定領域</firstterm> は二層に分かれたオプション名と 値の階層です。普通、これは<firstterm>定義ファイル</firstterm> (最初の 層)を含む特別なディレクトリに要約してあり、それは標準的なINI形式の テキストファイルにすぎません。(そこには<quote>sections</quote> があり、 それが第二層になります)これらのファイルは好きなテキストエディタを 使って簡単に編集することができます。(emacs とか vi とか) そして、クライアント によって読み出される命令を含んでいて、ユーザが好むさまざまなオプションの 振る舞いをどうするかを決定します。

note: Tag: title
en: Configuration Area Layout
ja: 設定領域のレイアウト

note: Tag: para
en: The first time that the <command>svn</command> command-line client is executed, it creates a per-user configuration area. On Unix-like systems, this area appears as a directory named <filename>.subversion</filename> in the user's home directory. On Win32 systems, Subversion creates a folder named <filename>Subversion</filename>, typically inside the <filename>Application Data</filename> area of the user's profile directory (which, by the way, is usually a hidden directory). However, on this platform the exact location differs from system to system, and is dictated by the Windows registry. <footnote> <para>The <literal>APPDATA</literal> environment variable points to the <filename>Application Data</filename> area, so you can always refer to this folder as <filename>%APPDATA%\Subversion</filename>.</para> </footnote> We will refer to the per-user configuration area using its Unix name, <filename>.subversion</filename>.
ja: <command>svn</command>コマンドラインクライアントが最初に実行されると、 それはユーザごとの構成領域を作ります。Unix風のシステムなら、この領域は ユーザのホームディレクトリに、<filename>.subversion</filename> という名前の ディレクトリとして用意されます。Win32システムでは、Subversionは <filename>Subversion</filename>という名前のフォルダを作ります。普通には ユーザプロファイルディレクトリ(これは通常は隠れたディレクトリになりますが) の<filename>Application Data</filename> 領域 の内部になります。しかし、このプラットフォームでは、完全な場所はシステム ごとに違っていて、本当の場所はWindowsレジストリ <footnote> <para><literal>APPDATA</literal> 環境変数は <filename>Application Data</filename> 領域を 指しているので、常にそのフォルダを<filename>%APPDATA%¥Subversion</filename> のように参照することができます。 </para> </footnote> に設定されています。 ユーザごとの設定領域は、Unix での名前である<filename>.subversion</filename> を使って参照することにします。

note: Tag: para
en: In addition to the per-user configuration area, Subversion also recognizes the existence of a system-wide configuration area. This gives system administrators the ability to establish defaults for all users on a given machine. Note that the system-wide configuration area does not alone dictate mandatory policy&mdash;the settings in the per-user configuration area override those in the system-wide one, and command-line arguments supplied to the <command>svn</command> program have the final word on behavior. On Unix-like platforms, the system-wide configuration area is expected to be the <filename>/etc/subversion</filename> directory; on Windows machines, it looks for a <filename>Subversion</filename> directory inside the common <filename>Application Data</filename> location (again, as specified by the Windows Registry). Unlike the per-user case, the <command>svn</command> program does not attempt to create the system-wide configuration area.
ja: ユーザごとの設定領域に加えて、Subversionはシステム全体の設定領域も 理解することができます。これはシステム管理者にあるマシン上での すべてのユーザに対するデフォルトを設定する力を与えます。システム全体 の設定領域は必須のポリシーがあるわけではありません&mdash;ユーザ ごとの設定領域は、システム全体の領域を上書きし、<command>svn</command> プログラムに与えるコマンドライン引数は振る舞いを決める最後の場所に なります。Unix風のプラットフォームでは、システム全体の設定領域は <filename>/etc/subversion</filename> ディレクトリにあると期待されて います。Windows マシンの場合は共通<filename>アプリケーション データ </filename> 領域の内部にある <filename>Subversion</filename>ディレクトリを見に行きます (このディレクトリもWindows レジストリによって指定されます)。 ユーザごとの場合と違って、<command>svn</command> プログラムは システム全体の設定領域を作ろうとはしません。

note: Tag: para
en: The per-user configuration area also contains a cache of authentication data. The <filename>auth</filename> directory holds a set of subdirectories that contain pieces of cached information used by Subversion's various supported authentication methods. This directory is created in such a way that only the user herself has permission to read its contents.
ja: ユーザごとの設定領域は認証データのキャッシュも含みます。<filename>auth</filename> ディレクトリは Subversionでサポートされているさまざまな認証方法で利用される キャッシュ情報の要素を含むサブディレクトリの集まりを保持します。 このディレクトリはユーザ自身だけがその内容を読むことができるような形に 作成されます。

note: Tag: title
en: Configuration and the Windows Registry
ja: 設定と、Windowsのレジストリ

note: Tag: para
en: In addition to the usual INI-based configuration area, Subversion clients running on Windows platforms may also use the Windows registry to hold the configuration data. The option names and their values are the same as in the INI files. The <quote>file/section</quote> hierarchy is preserved as well, though addressed in a slightly different fashion&mdash;in this schema, files and sections are just levels in the registry key tree.
ja: 普通の INIベースの設定領域に加えて、Windowsプラットフォーム上で実行されて いるSubversionクライアントはWindowsのレジストリも設定データを格納する場所 として利用することができます。オプション名とその値は INIファイル中と同じ です。<quote>file/section</quote> の階層関係も保存されます。わずかに異なる 方法によりますが&mdash;この方法では、ファイルとセクションは単にレジストリ キーのツリーの階層にしかすぎません。

note: Tag: para
en: Subversion looks for system-wide configuration values under the <literal>HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion</literal> key. For example, the <literal>global-ignores</literal> option, which is in the <literal>miscellany</literal> section of the <filename>config</filename> file, would be found at <literal>HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\Config\Miscellany\global-ignores</literal>. Per-user configuration values should be stored under <literal>HKEY_CURRENT_USER\Software\Tigris.org\Subversion</literal>.
ja: Subversionはシステム全体の設定値を <literal>HKEY_LOCAL_MACHINE¥Software¥Tigris.org¥Subversion</literal>キー の元で検削ｳ駈ｵます。たとえば<literal>global-ignores</literal> オプション、 これは<filename>config</filename> ファイルの<literal>miscellany</literal> セクションにありますが、<literal>HKEY_LOCAL_MACHINE¥Software¥Tigris.org¥Subversion¥Config¥Miscellany¥global-ignores</literal>に見つけることができます。 ユーザごとの設定値は <literal>HKEY_CURRENT_USER¥Software¥Tigris.org¥Subversion</literal>. の下に格納されるはずです。

note: Tag: para
en: Command-line options
ja: コマンドラインオプション

note: Tag: para
en: The per-user INI files
ja: ユーザごとのINIファイル

note: Tag: para
en: The per-user Registry values
ja: ユーザごとのレジストリ値

note: Tag: para
en: The system-wide INI files
ja: システム全体のINIファイル

note: Tag: para
en: The system-wide Registry values
ja: システム全体のレジストリ値

note: Tag: para
en: Also, the Windows Registry doesn't really support the notion of something being <quote>commented out</quote>. However, Subversion will ignore any option key whose name begins with a hash (<literal>#</literal>) character. This allows you to effectively comment out a Subversion option without deleting the entire key from the Registry, obviously simplifying the process of restoring that option.
ja: また、Windowsレジストリは<quote>コメントアウト</quote> のような概念をサポートしていません。しかし、Subversionは、 キーの名前がハッシュ文字(<literal>#</literal>) で始まるような すべてのオプションを無視します。これで実際にはSubversionのオプション を、レジストリから完全にキーを消さずにコメントアウトすることができます。 明らかに、そのオプションの設定作業は簡単にしています。

note: Tag: para
en: The <command>svn</command> command-line client never attempts to write to the Windows Registry, and will not attempt to create a default configuration area there. You can create the keys you need using the <command>REGEDIT</command> program. Alternatively, you can create a <filename>.reg</filename> file, and then double-click on that file from the Explorer shell, which will cause the data to be merged into your registry.
ja: <command>svn</command> コマンドラインクライアントはWindowsの レジストリに書き込むことは決してありませんし、そこに デフォルトの設定値を作ろうともしません。必要なキーは <command>REGEDIT</command>プログラムで作ることができます。他の方法 としては、<filename>.reg</filename> ファイルを作り、エクスプローラ シェルからそのファイルをダブルクリックすると、そのデータが レジストリにマージされます。

note: Tag: title
en: Sample Registration Entries (.reg) File.
ja: レジストリエントリ(.reg) ファイルの例

note: Tag: para
en: The previous example shows the contents of a <filename>.reg</filename> file which contains some of the most commonly used configuration options and their default values. Note the presence of both system-wide (for network proxy-related options) and per-user settings (editor programs and password storage, among others). Also note that all the options are effectively commented out. You need only to remove the hash (<literal>#</literal>) character from the beginning of the option names, and set the values as you desire.
ja: この例は、<filename>.reg</filename> の内容を示した例ですが、その 中には、よく利用される設定オプションの大部分とそのデフォルト値が あります。システムの設定(たとえばネットワークプロキシに関するオプション) と、ユーザごとの設定(利用するエディタ、パスワード、など)の両方が あることに注意してください。さらにすべてのオプションは、コメントアウト されていることにも注意してください。オプション名の先頭のハッシュ文字 (<literal>#</literal>) を取り除くだけで、望んでいる値に設定することが できます。

note: Tag: title
en: Configuration Options
ja: 設定オプション

note: Tag: para
en: In this section, we will discuss the specific run-time configuration options that are currently supported by Subversion.
ja: この章では、特定の実行時オプションについて議論します。現在Subversion がサポートしているものについてです。

note: Tag: title
en: Servers
ja: servers

note: Tag: para
en: The <filename>servers</filename> file contains Subversion configuration options related to the network layers. There are two special section names in this file&mdash;<literal>groups</literal> and <literal>global</literal>. The <literal>groups</literal> section is essentially a cross-reference table. The keys in this section are the names of other sections in the file; their values are <firstterm>globs</firstterm>&mdash;textual tokens which possibly contain wildcard characters&mdash;that are compared against the hostnames of the machine to which Subversion requests are sent.
ja: <filename>servers</filename> ファイルはSubversionの設定オプションで、 ネットワーク層に関係したものを含んでいます。二つのセクション名がその ファイルにはあります&mdash;<literal>groups</literal> と<literal>global</literal> です。<literal>groups</literal>セクションは、要するにクロスリファレンスの テーブルです。このセクションのキーは、ファイル中にある別のセクションの名前 です。その値は<firstterm>グロブ</firstterm>&mdash;ワイルドカードを含んで いるかも知れないテキストトークンです&mdash;で、Subversionの要求が送信 されるマシンのホスト名称と比較されます。

note: Tag: para
en: When Subversion is used over a network, it attempts to match the name of the server it is trying to reach with a group name under the <literal>groups</literal> section. If a match is made, Subversion then looks for a section in the <filename>servers</filename> file whose name is the matched group's name. From that section it reads the actual network configuration settings.
ja: Subversionがネットワーク越しに利用される場合、<literal>groups</literal> セクションにあるグループ名に合うサーバ名称とマッチするものを探します。 もしマッチした場合はSubversionは次に、その名前がグループ名称とマッチした <filename>servers</filename> ファイル中のセクションを探します。そして そのセクションから実際のネットワーク設定オプションを読み出します。

note: Tag: para
en: The <literal>global</literal> section contains the settings that are meant for all of the servers not matched by one of the globs under the <literal>groups</literal> section. The options available in this section are exactly the same as those valid for the other server sections in the file (except, of course, the special <literal>groups</literal> section), and are as follows:
ja: <literal>global</literal> セクションは<literal>groups</literal>セクション のどのグロブにも当てはまらなかったすべてのサーバに対する 設定があります。このセクションで使えるオプションは、ファイルの別の サーバセクションで利用できるものとまったく同じです。(ただし、 もちろん、<literal>groups</literal> セクションは例外です) 以下のような感じです:

note: Tag: para
en: This specifies the hostname of the proxy computer through which your HTTP-based Subversion requests must pass. It defaults to an empty value, which means that Subversion will not attempt to route HTTP requests through a proxy computer, and will instead attempt to contact the destination machine directly.
ja: これは、プロキシコンピュータのホスト名称で、HTTPベースのSubversion はそこを通じて通信しなくてはなりません。デフォルトは空で、それは Subversionはプロキシを通してHTTP要求せず、直接、目的のマシンと 通信しようとすることを意味しています。

note: Tag: para
en: This specifies the port number on the proxy host to use. It defaults to an empty value.
ja: これは、利用するプロキシホストのポート番号を指定します。 デフォルトは空です。

note: Tag: para
en: This specifies the username to supply to the proxy machine. It defaults to an empty value.
ja: これは、プロキシマシンで必要なユーザ名を指定します。 デフォルトは空です。

note: Tag: para
en: This specifies the password to supply to the proxy machine. It defaults to an empty value.
ja: これは、プロキシマシンで必要なパスワードを指定します。 デフォルトは空です。

note: Tag: para
en: This specifies whether or not Subversion should attempt to compress network requests made to DAV-ready servers. The default value is <literal>yes</literal> (though compression will only occur if that capability is compiled into the network layer). Set this to <literal>no</literal> to disable compression, such as when debugging network transmissions.
ja: これは、DAVが有効なサーバで、Subversionがネットワーク要求データを 圧縮するかどうかを指定します。デフォルト値は<literal>yes</literal> (ただし、圧縮はネットワーク層のコンパイル時に有効になっていなくては なりませんが、)です。<literal>no</literal> に設定すると圧縮は 無効になりますが、これはネットワーク転送のデバッグ時などに使います。

note: Tag: para
en: This is an integer mask that the underlying HTTP library, Neon, uses for choosing what type of debugging output to yield. The default value is <literal>0</literal>, which will silence all debugging output. For more information about how Subversion makes use of Neon, see <xref linkend="svn.developer"/>.
ja: これは、整数値のマスクで、HTTPライブラリNeon がどのようなタイプの デバック出力を生成するかを指定するものです。デフォルトは <literal>0</literal>で、すべてデバッグ出力を無効にします。Subversion がNeonをどのように使うかについての詳細は <xref linkend="svn.developer"/>を見てください。

note: Tag: literal
en: ssl-authority-files
ja: ssl-authority-file

note: Tag: para
en: This is a semicolon-delimited list of paths to files containing certificates of the certificate authorities (or CAs) that are accepted by the Subversion client when accessing the repository over HTTPS.
ja: これは HTTPS 経由でリポジトリにアクセスするときに Subversion クライアントによって受け入れられる認証機関(あるいは CA)の 証明書を含むファイルパスのリストをセミコロンで区切ったものになります。

note: Tag: para
en: Set this variable to <literal>yes</literal> if you want Subversion to automatically trust the set of default CAs that ship with OpenSSL.
ja: Subversion が自動的に OpenSSL に付いているデフォルトのCA を信用する ようにしたい場合にはこの変数を<literal>yes</literal>にしてください。

note: Tag: para
en: If a host (or set of hosts) requires an SSL client certificate, you'll normally be prompted for a path to your certificate. By setting this variable to that same path, Subversion will be able to find your client certificate automatically without prompting you. There's no standard place to store your certificate on disk; Subversion will grab it from any path you specify.
ja: ホスト(あるいは何台かのホスト)が SSL クライアント証明書を要求する場合 普通は証明書のあるパスを入力するようにユーザにうながします。そのパスを この変数に設定すると Subversion はユーザの入力なしにクライアント証明書 を自動的に探すことができるようになります。証明書をディスク上に保存する ための標準的な場所はありません; Subversion は指定したどのようなパスから でもそれを取得することができます。

note: Tag: para
en: If your SSL client certificate file is encrypted by a passphrase, Subversion will prompt you for the passphrase whenever the certificate is used. If you find this annoying (and don't mind storing the password in the <filename>servers</filename> file), then you can set this variable to the certificate's passphrase. You won't be prompted anymore.
ja: SSL クライアント証明書ファイルがパスフレーズで暗号化されている場合 Subversion はその証明書を利用するたびにパスフレーズの入力を求めます。 これが嫌なら(そして<filename>servers</filename>ファイル中に 自分のパスワードを保存するのが嫌でなけれぱ)、この変数に証明書の パスフレーズを設定することができます。これでパスフレーズを聞かれる ことはなくなります。

note: Tag: title
en: Config
ja: config

note: Tag: para
en: The <literal>auth</literal> section contains settings related to Subversion's authentication and authorization against the repository. It contains:
ja: <literal>auth</literal> セクションはSubversionのリポジトリに対する 認証と許可に関係した設定があります。それは:

note: Tag: para
en: This instructs Subversion to cache, or not to cache, passwords that are supplied by the user in response to server authentication challenges. The default value is <literal>yes</literal>. Set this to <literal>no</literal> to disable this on-disk password caching. You can override this option for a single instance of the <command>svn</command> command using the <option>--no-auth-cache</option> command-line parameter (for those subcommands that support it). For more information, see <xref linkend="svn.serverconfig.netmodel.credcache"/>.
ja: これはSubversionにサーバ認証チャレンジに対してユーザが 入力するパスワードをキャッシュするかどうかを指示します。 デフォルトは<literal>yes</literal> です。<literal>no</literal>に 設定するとディスク上でのパスワードのキャッシュを無効にします。 このオプションは<command>svn</command> コマンドインスタンスのどれか で<option>--no-auth-cache</option> を使うと上書きすることができます。 (あるいはこの引数をサポートしているコマンドであればどれでも)。 詳細は<xref linkend="svn.serverconfig.netmodel.credcache"/>を参照してください。

note: Tag: para
en: This setting is the same as <literal>store-passwords</literal>, except that it enables or disables disk-caching of <emphasis>all</emphasis> authentication information: usernames, passwords, server certificates, and any other types of cacheable credentials.
ja: この設定は <literal>store-passwords</literal>と同じですが、ディスク上 にキャッシュする <emphasis>すべての</emphasis>認証情報を有効にしたり 無効にするところが違います。このような情報にはユーザ名、パスワード サーバ証明書、その他のキャッシュ可能な認証情報すべてが含まれます。

note: Tag: para
en: The <literal>helpers</literal> section controls which external applications Subversion uses to accomplish its tasks. Valid options in this section are:
ja: <literal>helpers</literal> セクションはSubversionがどの 外部アプリケーションをいくつかの処理で使うかを制御します。 このセクションで有効なものは:

note: Tag: para
en: This specifies the absolute path of a differencing program, used when Subversion generates <quote>diff</quote> output (such as when using the <command>svn diff</command> command). By default Subversion uses an internal differencing library&mdash;setting this option will cause it to perform this task using an external program. See <xref linkend="svn.advanced.externaldifftools"/> for more details on using such programs.
ja: これは差分表示プログラムの絶対パスを指定します。このプログラムは Subversionが <quote>diff</quote> の出力を生成するのに利用 されるものです( <command>svn diff</command> コマンド実行時 などです)。デフォルトで Subversion は内部的な差分ライブラリを 利用します&mdash;このオプションによって外部プログラムを使って 処理するようになります。そのようなプログラムの使い方の詳細は <xref linkend="svn.advanced.externaldifftools"/>を見てください。

note: Tag: para
en: This specifies the absolute path of a three-way differencing program. Subversion uses this program to merge changes made by the user with those received from the repository. By default Subversion uses an internal differencing library&mdash;setting this option will cause it to perform this task using an external program. See <xref linkend="svn.advanced.externaldifftools"/> for more details on using such programs.
ja: これはスリーウェイ差分プログラムの絶対パスを指定します。Subversion はこのプログラムをリポジトリから受け取った、ユーザがした変更点を マージするのに使います。デフォルトで Subversion は内部的な差分 ライブラリを利用します&mdash;このオプションを設定すると、外部プログラムを 使って処理を実行するようになります。そのようなプログラムの使い方の 詳細は <xref linkend="svn.advanced.externaldifftools"/> を見てください。

note: Tag: para
en: This flag should be set to <literal>true</literal> if the program specified by the <literal>diff3-cmd</literal> option accepts a <option>--diff-program</option> command-line parameter.
ja: このフラグは<literal>diff3-cmd</literal> オプションが <option>--diff-program</option> パラメータを受け付ける場合には <literal>true</literal>を指定すべきです。

note: Tag: para
en: The <literal>tunnels</literal> section allows you to define new tunnel schemes for use with <command>svnserve</command> and <literal>svn://</literal> client connections. For more details, see <xref linkend="svn.serverconfig.svnserve.sshauth"/>.
ja: <literal>tunnels</literal> セクションでは <command>svnserve</command> と<literal>svn://</literal>クライアント接続を使った新しいトンネルスキーマを定義する ことができます。詳細は<xref linkend="svn.serverconfig.svnserve.sshauth"/>を参照してください。

note: Tag: para
en: The <literal>miscellany</literal> section is where everything that doesn't belong elsewhere winds up. <footnote> <para>Anyone for potluck dinner?</para> </footnote> In this section, you can find:
ja: <literal>miscellany</literal> セクションは他の場所に置けない すべてのものの置き場所です。 <footnote> <para>残り物でディナーはいかが?</para> </footnote> このセクションには:

note: Tag: para
en: When running the <command>svn status</command> command, Subversion lists unversioned files and directories along with the versioned ones, annotating them with a <literal>?</literal> character (see <xref linkend="svn.tour.cycle.examine.status"/>). Sometimes, it can be annoying to see uninteresting, unversioned items&mdash;for example, object files that result from a program's compilation&mdash;in this display. The <literal>global-ignores</literal> option is a list of whitespace-delimited globs which describe the names of files and directories that Subversion should not display unless they are versioned. The default value is <literal>*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store</literal>.
ja: <command>svn status</command>コマンドを実行するとSubversionは バージョン化されないファイルとディレクトリをバージョン化されて いるものと一緒に一覧表示します。このときバージョン化されていない ことを<literal>?</literal> 文字で表現します。 (<xref linkend="svn.tour.cycle.examine.status"/>参照)。 ときどき、あまり興味のないバージョン化されないアイテムが表示されるのを 見るのを面倒に思うことがあります。 &mdash;たとえば、プログラムのコンパイルによってできるオブジェクトファイル など&mdash; <literal>global-ignores</literal> オプションは空白で区切られたグロブの リストで、バージョン化されていないのであればSubversionに表示して欲しく ないものの名前の指定になります。デフォルトは <literal>*.o *.lo *.la #*# .*.rej *.rej .*‾ *‾ .#* .DS_Store</literal>です。

note: Tag: para
en: As well as <command>svn status</command>, the <command>svn add</command> and <command>svn import</command> commands also ignore files that match the list when they are scanning a directory. You can override this behaviour for a single instance of any of these commands by explicitly specifying the file name, or by using the <option>--no-ignore</option> command-line flag.
ja: <command>svn status</command> のほか、 <command>svn add</command>、<command>svn import</command> コマンドもリストにマッチするファイルを無視します。 どのコマンドでも<option>--no-ignore</option> フラグを使うとこのオプションをその実行に限って上書きできます。

note: Tag: para
en: For information on more fine-grained control of ignored items, see <xref linkend="svn.advanced.props.special.ignore"/>.
ja: 無視するアイテムについてのもっと細かい制御については <xref linkend="svn.advanced.props.special.ignore"/>を見てください。

note: Tag: para
en: This instructs Subversion to automatically set properties on newly added or imported files. The default value is <literal>no</literal>, so set this to <literal>yes</literal> to enable Auto-props. The <literal>auto-props</literal> section of this file specifies which properties are to be set on which files.
ja: これは Subversion に新規追加またはインポートしたファイルの属性を 自動的に設定するように指示します。デフォルト値は<literal>no</literal> なので有効にするには<literal>yes</literal>にしてください。 このファイルの<literal>auto-props</literal>セクションはどの属性が どのファイル上に設定されるかを指定します。

note: Tag: para
en: This variable sets the default character set encoding for commit log messages. It's a permanent form of the <option>--encoding</option> option (see <xref linkend="svn.ref.svn.sw"/>). The Subversion repository stores log messages in UTF-8, and assumes that your log message is written using your operating system's native locale. You should specify a different encoding if your commit messages are written in any other encoding.
ja: この変数はログメッセージをコミットするキャラクタセットのデフォルト エンコーディングを設定します。これは <option>--encoding</option> オプションを無条件に有効にするものです( <xref linkend="svn.ref.svn.sw"/> 参照)。Subversion リポジトリはログメッセージを UTF8 で保存し、あなたの ログメッセージはあなたのオペレーティングシステムの独自のロカールを使って 書き込まれることを仮定しています。他のエンコーディングで書いたメッセージ をコミットしたい場合には別のエンコーディングを指定すべきです。

note: Tag: para
en: Normally your working copy files have timestamps that reflect the last time they were touched by any process, whether that be your own editor or by some <command>svn</command> subcommand. This is generally convenient for people developing software, because build systems often look at timestamps as a way of deciding which files need to be recompiled.
ja: 通常作業コピーのファイルはどんな操作をしたかにかかわらず最後に触った 時刻を反映したタイムスタンプを持ちます。これはエディタで編集したか、 他の<command>svn</command>サブコマンドを使ったかにはよりません。 これは普通はソフトウェア開発者にとって便利なものですが、それは ビルドシステムはよくどのファイルが再コンパイルを必要としているか を決めるのにタイムスタンプを見るためです。

note: Tag: para
en: In other situations, however, it's sometimes nice for the working copy files to have timestamps that reflect the last time they were changed in the repository. The <command>svn export</command> command always places these <quote>last-commit timestamps</quote> on trees that it produces. By setting this config variable to <literal>yes</literal>, the <command>svn checkout</command>, <command>svn update</command>, <command>svn switch</command>, and <command>svn revert</command> commands will also set last-commit timestamps on files that they touch.
ja: しかし別の状況ではリポジトリで変更された最終時刻を反映しているような タイムスタンプが作業ファイルに振られているほうが便利であることも あります。 <command>svn export</command>コマンドは常に、このような 抽出したツリー上の <quote>最終コミット時間</quote> を振りますが、この設定変数を <literal>yes</literal>にすると、<command>svn checkout</command>, <command>svn update</command>, <command>svn switch</command>, そして <command>svn revert</command>についても同様に、それらの操作が 触れたファイルに最終コミット時間を振るようになります。

note: Tag: para
en: The <literal>auto-props</literal> section controls the Subversion client's ability to automatically set properties on files when they are added or imported. It contains any number of key-value pairs in the format <literal>PATTERN = PROPNAME=PROPVALUE</literal> where <literal>PATTERN</literal> is a file pattern that matches a set of filenames and the rest of the line is the property and its value. Multiple matches on a file will result in multiple propsets for that file; however, there is no guarantee that auto-props will be applied in the order in which they are listed in the config file, so you can't have one rule <quote>override</quote> another. You can find several examples of auto-props usage in the <filename>config</filename> file. Lastly, don't forget to set <literal>enable-auto-props</literal> to <literal>yes</literal> in the <literal>miscellany</literal> section if you want to enable auto-props.
ja: <literal>auto-props</literal>セクションは Subversion クライアントが追加 またはインポートしたファイルの属性を自動的に設定する能力を制御します。 そこには <literal>PATTERN = PROPNAME=PROPVALUE</literal>の形をした 任意数のキー・属性値の組を置くことができますが、ここで<literal>PATTERN</literal> はファイル名称にマッチするような正規表現で、行の残りの部分は対応する属性と その値です。ファイルに複数の要素がマッチすれば、そのファイルに複数の属性が 設定されることになります; しかし設定ファイル中に列挙された auto-props が その順序で適用されるかどうかの保証はないので一つの規則で別の規則を <quote>上書き</quote>することはできません。<filename>config</filename> ファイル中に、auto-props を使ったさまざまな例を見つけることができる でしょう。最後に、auto-props を有効にするには<literal>enable-auto-props</literal> を<literal>yes</literal>にするのを忘れずに。

note: Tag: title
en: Localization
ja: ローカライゼーション

note: Tag: para
en: <firstterm>Localization</firstterm> is the act of making programs behave in a region-specific way. When a program formats numbers or dates in a way specific to your part of the world, or prints messages (or accepts input) in your native language, the program is said to be <firstterm>localized</firstterm>. This section describes steps Subversion has made towards localization.
ja: <firstterm>ローカライゼーション</firstterm> とはプログラムが 特定の地域に応じた動作をするように作ることを言います。あるプログラムが 数値や日付を特定の地域に応じて書式化して出力したり、その地域の言語でメッ セージを出力したり(あるいはそのような入力を受け入れたり)できるのであれ ば、そのプログラムは<firstterm>ローカライズされている</firstterm> と言 われます。この節では Subversion のローカライゼーションに向けた取り組み について説明します。

note: Tag: title
en: Understanding locales
ja: ロケールの理解

note: Tag: para
en: Most modern operating systems have a notion of the <quote>current locale</quote>&mdash;that is, the region or country whose localization conventions are honored. These conventions&mdash;typically chosen by some runtime configuration mechanism on the computer&mdash;affect the way in which programs present data to the user, as well as the way in which they accept user input.
ja: 最近のほとんどのオペレーティングシステムは <quote>現在のロケール値</quote> という考え方を採り入れています &mdash; つまり、その時点で考慮されている ローカリゼーションの規約が、どの地域や国に対応しているかという値です。 このような規約は&mdash; 普通はコンピュータの実行時の設定のしくみを 通じて選択されるものですが &mdash; プログラムがデータをユーザに対して 出力する時や、ユーザからの入力を受け付けるときの動作に影響を与えます。

note: Tag: para
en: The output is a list of locale-related environment variables and their current values. In this example, the variables are all set to the default <literal>C</literal> locale, but users can set these variables to specific country/language code combinations. For example, if one were to set the <literal>LC_TIME</literal> variable to <literal>fr_CA</literal>, then programs would know to present time and date information formatted according a French-speaking Canadian's expectations. And if one were to set the <literal>LC_MESSAGES</literal> variable to <literal>zh_TW</literal>, then programs would know to present human-readable messages in Traditional Chinese. Setting the <literal>LC_ALL</literal> variable has the effect of changing every locale variable to the same value. The value of <literal>LANG</literal> is used as a default value for any locale variable that is unset. To see the list of available locales on a Unix system, run the command <command>locale -a</command>.
ja: 出力されているのはロケール関連の環境変数とその現在値です。この例では変 数はすべてデフォルトの<literal>C</literal>ロケールになっています。ユー ザはこれらの変数を特定の国/言語コードの組合せに変更することができます。 例えば <literal>LC_TIME</literal>変数の値を<literal>fr_CA</literal> に すると、プログラムはフランス語を話すカナダ人に対する書式で時刻と日付を 表示するようになります。あるいは <literal>LC_MESSAGES</literal>変数を <literal>zh_TW</literal>に設定すれば、プログラムは人が読むためのメッセー ジ中国語で表示するようになります。 <literal>LC_ALL</literal>変数を設定 すると全てのロケール変数の値が同じ値になります。 <literal>LANG</literal> の値はどのロケール変数も設定されていない場合の デフォルト値になります。Unix システムで可能なロケールの一覧は <command>locale -a</command>を実行するとわかります。

note: Tag: para
en: On Windows, locale configuration is done via the <quote>Regional and Language Options</quote> control panel item. There you can view and select the values of individual settings from the available locales, and even customize (at a sickening level of detail) several of the display formatting conventions.
ja: Windows ではロケールの設定はコントロールパネルの<quote>地域と言語のオ プション</quote>を通じて設定することができます。その画面で利用できるロ ケール値がそれぞれどのようになっているかを確認し、選択することができ、 (かなり特殊なケースだと思いますが)表示形式の規約をさまざまにカスタマイ ズすることすらできます。

note: Tag: title
en: Subversion's use of locales
ja: Subversion でのロケール

note: Tag: para
en: The Subversion client, <command>svn</command>, honors the current locale configuration in two ways. First, it notices the value of the <literal>LC_MESSAGES</literal> variable and attempts to print all messages in the specified language. For example:
ja: Subversion クライアントである <command>svn</command>は、ふたつの場面で 現在のロケール値を正しく扱います。まず、<literal>LC_MESSAGES</literal> 変数の値を見て全てのメッセージを特定の言語で表示しようとします。たとえ ば:

note: Tag: para
en: This behavior works identically on both Unix and Windows systems. Note, though, that while your operating system might have support for a certain locale, the Subversion client still may not be able to speak the particular language. In order to produce localized messages, human volunteers must provide translations for each language. The translations are written using the GNU gettext package, which results in translation modules that end with the <filename>.mo</filename> filename extension. For example, the German translation file is named <filename>de.mo</filename>. These translation files are installed somewhere on your system. On Unix, they typically live in <filename>/usr/share/locale/</filename>, while on Windows they're often found in the <filename>\share\locale\</filename> folder in Subversion's installation area. Once installed, a module is named after the program it provides translations for. For example, the <filename>de.mo</filename> file may ultimately end up installed as <filename>/usr/share/locale/de/LC_MESSAGES/subversion.mo</filename>. By browsing the installed <filename>.mo</filename> files, you can see which languages the Subversion client is able to speak.
ja: この動作は Unix でも Windows でも同じです。しかし、あなたのオペレーティ ングシステムが特定のロケールをサポートしているとしても Subversion クラ イアントがその特定の言語をしゃべることができるとは限りません。ローカラ イズされたメッセージを出力するにはボランティアによる言語ごとの翻訳が必 要になります。翻訳は GNU gettext パッケージを利用しているので、 <filename>.mo</filename> というファイル拡張子をもった翻訳モジュールが 結果として必要になります。たとえば、ドイツ語の翻訳ファイルは <filename>de.mo</filename>になる、といった具合です。このような翻訳ファ イルはあなたのシステムの、ある特定の場所にインストールされます。Unix であれば普通は<filename>/usr/share/locale/</filename> のような場所にな り、Windows であれば Subversion をインストールしたフォルダの中の <filename>¥share¥locale¥</filename>フォルダなどに見つかることがよくあ ります。いったんインストールするとモジュールは翻訳を実行するプログラム の名前に変更されます。例えば <filename>de.mo</filename>というファイル は最終的には <filename>/usr/share/locale/de/LC_MESSAGES/subversion.mo</filename> の ような名前でインストールされます。インストールされている <filename>.mo</filename>ファイルを見れば、Subversion クライアントが実 際にはどの言語を話すことができるかがわかります。

note: Tag: para
en: The second way in which the locale is honored involves how <command>svn</command> interprets your input. The repository stores all paths, filenames, and log messages in Unicode, encoded as UTF-8. In that sense, the repository is <firstterm>internationalized</firstterm>&mdash;that is, the repository is ready to accept input in any human language. This means, however, that the Subversion client is responsible for sending only UTF-8 filenames and log messages into the repository. In order to do this, it must convert the data from the native locale into UTF-8.
ja: ロケールが考慮される二番目の場面は <command>svn</command> があなたの入力を解釈する時です。リポジトリはすべてのパス名、ファイル名 そしてログメッセージを UTF-8 でエンコードされた Unicode で保存します。 この意味でリポジトリは <firstterm>国際化されて</firstterm>います&mdash; つまり、リポジトリはどのような自然言語の入力も受け入れる用意ができて います。しかしこれは Subversion クライアントは UTF-8 ファイル名とログ メッセージだけをリポジトリに送る責任があることを意味します。このため Subversion クライアントはデータをネイティブのロケールから UTF-8 へと 変換しなくてなりません。

note: Tag: para
en: Note that while the repository demands UTF-8 filenames and log messages, it <emphasis>does not</emphasis> pay attention to file contents. Subversion treats file contents as opaque strings of bytes, and neither client nor server makes an attempt to understand the character set or encoding of the contents.
ja: リポジトリはファイル名とログメッセージは UTF-8 であることを要求します がファイルの内容にはまったく考慮 <emphasis>しません</emphasis>。 Subversion はファイルの内容を単なるバイト列の並びとして扱い、クライア ント側もサーバ側もその内容のキャラクタセットやエンコーディングを理解し ようとはしません。

note: Tag: title
en: Character set conversion errors
ja: キャラクタセット変換エラー

note: Tag: para
en: While using Subversion, you might get hit with an error related to character set conversions:
ja: Subversion を利用しているとキャラクタセット変換に関係したエラー に遭駈ｷ駈ｷるかも知れません:

note: Tag: para
en: Errors like this typically occur when the Subversion client has received a UTF-8 string from the repository, but not all of the characters in that string can be represented using the encoding of the current locale. For example, if your locale is <literal>en_US</literal> but a collaborator has committed a Japanese filename, you're likely to see this error when you receive the file during an <command>svn update</command>.
ja: このようなエラーは Subversio クライアントが UTF-8 文字列をリポジトリ から受け取ったがその文字列中のすべての文字を現在のロケールのエンコーディング を使って表現できるわけではないような場合に典型的に発生します。たとえば 現在のロケールが <literal>en_US</literal> であるのに他の開発者が日本語の ファイル名をコミットした場合、<command>svn update</command>実行中にファイル を受け取っているときにこのようなエラーが発生するかも知れません。

note: Tag: para
en: The solution is either to set your locale to something which <emphasis>can</emphasis> represent the incoming UTF-8 data, or to change the filename or log message in the repository. (And don't forget to slap your collaborator's hand&mdash;projects should decide on common languages ahead of time, so that all participants are using the same locale.)
ja: 解決方法としては受け手のロケールを取り込もうとする UTF-8 データを表現 することが <emphasis>可能な</emphasis>どれかのロケールに設定するか、 リポジトリ中のファイル名やログメッセージを変更するかです。(それから その開発者にきちんと次のように伝えておくことも忘れずに&mdash;このプロジェクト はある共通の言語で開発することに決めたので、すべての開発者はそのロケール を使うように、と。)

note: Tag: title
en: Using External Differencing Tools
ja: 外部差分ツールの利用

note: Tag: para
en: The presence of <option>--diff-cmd</option> and <option>--diff3-cmd</option> options, and similarly named runtime configuration parameters (see <xref linkend="svn.advanced.confarea.opts.config"/>), can lead to a false notion of how easy it is to use external differencing (or <quote>diff</quote>) and merge tools with Subversion. While Subversion can use most of popular such tools available, the effort invested in setting this up often turns out to be non-trivial.
ja: <option>--diff-cmd</option>と<option>--diff3-cmd</option> オプションや 同じような名前の実行時環境パラメータ(<xref linkend="svn.advanced.confarea.opts.config"/>参照)がある ので、Subversion で外部差分ツール(あるいは <quote>diff</quote>)とマージツールを 使うのは簡単なことだという間違った考えを持ってしまうかも知れません。 Subversion ではそのようなよく知られたほとんどのツールを使うことが できますが、このような設定に必要な努力はそれほど簡単ではないことが よくあります。

note: Tag: para
en: The interface between Subversion and external diff and merge tools harkens back to a time when Subversion's only contextual differencing capabilities were built around invocations of the GNU diffutils toolchain, specifically the <command>diff</command> and <command>diff3</command> utilities. To get the kind of behavior Subversion needed, it called these utilities with more than a handful of options and parameters, most of which were quite specific to the utilities. Some time later, Subversion grew its own internal differencing library, and as a failover mechanism, <footnote> <para>Subversion developers are good, but even the best make mistakes.</para> </footnote> the <option>--diff-cmd</option> and <option>--diff3-cmd</option> options were added to the Subversion command-line client so users could more easily indicate that they preferred to use the GNU diff and diff3 utilities instead of the newfangled internal diff library. If those options were used, Subversion would simply ignore the internal diff library, and fall back to running those external programs, lengthy argument lists and all. And that's where things remain today.
ja: Subversion と外部 diff と merge ツールは Subversion の唯一の文脈差分 を出力する能力が GNU の diffutils の連携した呼び出しだけであった ころに由来しています。具体的には <command>diff</command> と <command>diff3</command> ユーティリティーです。Subversion が必要とする ような動作をさせるには、そのようなユーティリティーをかなりたくさんの オプションと引数で呼び出されました。それらのほとんどはそれぞれの ユーティリティーごとの非常に特殊なオプションでした。ある時点から Subversion は自分自身の内部差分ライブラリを持つようになり、エラー回避の仕組みとして の <footnote> <para> Subversion 開発者はもちろんみんな優秀ですが、猿も木から落ちるといいます。 </para> </footnote> <option>--diff-cmd</option>と<option>--diff3-cmd</option> オプションが Subversion コマンドラインクライアントに追加されていて、 これによってユーザは、新しい内部 diff ライブラリを使うかわりに自分の 好きな GNU diff や diff3 ユーティリティーを使うこともできたのです。 このようなオプションが利用された場合、Subversion は単に内部 diff ライブラリを無視し、そのような外部プログラムを長い引数つきで実行します。 これが、このようなオプションが今でも残っている理由です。

note: Tag: para
en: It didn't take long for folks to realize that having such easy configuration mechanisms for specifying that Subversion should use the external GNU diff and diff3 utilities located at a particular place on the system could be applied toward the use of other diff and merge tools, too. After all, Subversion didn't actually verify that the things it was being told to run were members of the GNU diffutils toolchain. But the only configurable aspect of using those external tools is their location on the system&mdash;not the option set, parameter order, etc. Subversion continues throwing all those GNU utility options at your external diff tool regardless of whether or not that program can understand those options. And that's where things get unintuitive for most users.
ja: Subversion がシステム中の特定のディレクトリにある外部 GNU diff と diff3 ユーティリティーを利用するための簡単な設定の仕組みは他の diff や merge ツールにも一般的に利用できることに開発チームが気づくまでにはそんなに 長い時間はかかりませんでした。要するに Subversion は実際に実行せよと 言われた外部ツールが GNU diffutils のツールの組み合わせであるかどうか を実際には確認していなかったのです。しかしこれらの外部ツールを利用する ための、そのツールのシステム中の場所だけは設定しなくてはなりません&mdash; 必要なオプションと、パラメータの順序、などを指定するのはもちろんのこと ですが。Subversion は、このような GNU ユーティリティー用のオプションの すべてを、実際にそのオプションが理解されるかどうかにかかわりなく 外部 diff ツールに渡します。そしてここがほとんどのユーザにとって 直観的には理解しにくい部分です。

note: Tag: para
en: The key to using external diff and merge tools (other than GNU diff and diff3, of course) with Subversion is to use wrapper scripts which convert the input from Subversion into something that your differencing tool can understand, and then to convert the output of your tool back into a format which Subversion expects&mdash;the format that the GNU tools would have used. The following sections cover the specifics of those expectations.
ja: 外部 diff と merge ツール(もちろん GNU diff と diff3 以外のものも含みますが) を Subversion で利用するときの鍵は、Subversion からの入力をその差分ツールが 理解できる何らかの形に変換し、そのツールからの出力内容&mdash; それは たとえば GNU ツールが利用しているような書式ということになるのでしょうが&mdash; を Subversion 側で理解できる形に変換するようなラッパースクリプトを使うことです。 以下の節ではこのような考え方を具体的に述べます。

note: Tag: para
en: The decision on when to fire off a contextual diff or merge as part of a larger Subversion operation is made entirely by Subversion, and is affected by, among other things, whether or not the files being operated on are human-readable as determined by their <literal>svn:mime-type</literal> property. This means, for example, that even if you had the niftiest Microsoft Word-aware differencing or merging tool in the Universe, it would never be invoked by Subversion so long as your versioned Word documents had a configured MIME type that denoted that they were not human-readable (such as <literal>application/msword</literal>). For more about MIME type settings, see
ja: Subversion の処理の一部として文脈 diff や merge をいつ利用するかの判断は 完全に Subversion 側で決定され、操作対象となるファイルが人間によって 可読な形式であるかどうかは他の場合と同様 <literal>svn:mime-type</literal> 属性によって決められます。これによって、例えば、仮にあなたが宇宙で一番 すぐれた Microsoft Word 用の差分とマージツールを手にしていたとしても、 そのバージョン化された Word ドキュメントが人間によって可読ではないことを 示す MIME タイプに設定されていなければ(たとえば <literal>application/msword</literal>のようなもの)決して起動されることは ないでしょう。MIME タイプの設定についての詳細は <xref linkend="svn.advanced.props.special.mime-type"/>を見て ください。

note: Tag: title
en: External diff
ja: 外部 diff

note: Tag: para
en: The GNU diff manual page puts it this way: <quote>An exit status of 0 means no differences were found, 1 means some differences were found, and 2 means trouble.</quote>
ja: GNU diff のマニュアルには以下のようにあります: <quote> 0 の終了コードは差分がなかったことを意味し、1 は何か差分があったことを、また 2 は処理に異常があったことを示します。 </quote>

note: Tag: para
en: and <xref linkend="svn.advanced.externaldifftools.diff.ex-2"/> are templates for external diff tool wrappers in the Bourne shell and Windows batch scripting languages, respectively.
ja: と <xref linkend="svn.advanced.externaldifftools.diff.ex-2"/> はそれぞれ Bourne シェルと Windows バッチスクリプト言語での外部 diff ツールの ラッパー用テンプレートです。

note: Tag: programlisting
en: #!/bin/sh
    
    # Configure your favorite diff program here.
    DIFF="/usr/local/bin/my-diff-tool"
    
    # Subversion provides the paths we need as the sixth and seventh 
    # parameters.
    LEFT=${6}
    RIGHT=${7}
    
    # Call the diff command (change the following line to make sense for
    # your merge program).
    $DIFF --left $LEFT --right $RIGHT
    
    # Return an errorcode of 0 if no differences were detected, 1 if some were.
    # Any other errorcode will be treated as fatal.
ja: #!/bin/sh
    
    # ここに自分の好きな diff プログラムを設定してください。
    DIFF="/usr/local/bin/my-diff-tool"
    
    # Subversion は 6 番目と 7 番目の引数としてパス名が必要です
    LEFT=${6}
    RIGHT=${7}
    
    # diff コマンドを呼び出します (merge プログラムで意味を持つように
    # 以下の行を変更してください。)
    $DIFF --left $LEFT --right $RIGHT
    
    # 差分がなけばエラーコード 0 を、差分があれば 1 を返します。
    # それ以外のエラーコードは致命的とみなします。

note: Tag: programlisting
en: @ECHO OFF
    
    REM Configure your favorite diff program here.
    SET DIFF="C:\Program Files\Funky Stuff\My Diff Tool.exe"
    
    REM Subversion provides the paths we need as the sixth and seventh 
    REM parameters.
    SET LEFT=%6
    SET RIGHT=%7
    
    REM Call the diff command (change the following line to make sense for
    REM your merge program).
    %DIFF% --left %LEFT% --right %RIGHT%
    
    REM Return an errorcode of 0 if no differences were detected, 1 if some were.
    REM Any other errorcode will be treated as fatal.
ja: @ECHO OFF
    
    REM ここに自分の好きな diff プログラムを設定してください。
    SET DIFF="C:¥Program Files¥Funky Stuff¥My Diff Tool.exe"
    
    REM Subversion は 6 番目と 7 番目の引数としてパス名が必要です
    SET LEFT=%6
    SET RIGHT=%7
    
    REM diff コマンドを呼び出します (merge プログラムで意味を持つように
    REM 以下の行を変更してください。)
    %DIFF% --left %LEFT% --right %RIGHT%
    
    REM 差分がなけばエラーコード 0 を、差分があれば 1 を返します。
    REM それ以外のエラーコードは致命的とみなします。

note: Tag: title
en: External diff3
ja: 外部 diff3

note: Tag: para
en: and <xref linkend="svn.advanced.externaldifftools.diff3.ex-2"/> are templates for external merge tool wrappers in the Bourne shell and Windows batch scripting languages, respectively.
ja: と <xref linkend="svn.advanced.externaldifftools.diff3.ex-2"/> はそれぞれ Bourne シェルと Windows バッチスクリプト言語用の外部マージツール ラッパーのテンプレートです。

note: Tag: programlisting
en: #!/bin/sh
    
    # Configure your favorite diff3/merge program here.
    DIFF3="/usr/local/bin/my-merge-tool"
    
    # Subversion provides the paths we need as the ninth, tenth, and eleventh 
    # parameters.
    MINE=${9}
    OLDER=${10}
    YOURS=${11}
    
    # Call the merge command (change the following line to make sense for
    # your merge program).
    $DIFF3 --older $OLDER --mine $MINE --yours $YOURS
    
    # After performing the merge, this script needs to print the contents
    # of the merged file to stdout.  Do that in whatever way you see fit.
    # Return an errorcode of 0 on successful merge, 1 if unresolved conflicts
    # remain in the result.  Any other errorcode will be treated as fatal.
ja: #!/bin/sh
    
    # ここに自分の好きな diff3/merge プログラムを設定してください。
    DIFF3="/usr/local/bin/my-merge-tool"
    
    # Subversion は必要となるパスを、9, 10, 11 番目の引数として用意します。
    MINE=${9}
    OLDER=${10}
    YOURS=${11}
    
    # merge コマンドを呼び出します (merge プログラムで意味を持つように
    # 以下の行を変更してください。)
    $DIFF3 --older $OLDER --mine $MINE --yours $YOURS
    
    # マージ処理実行後、このスクリプトはマージされたファイル内容を標準出力に
    # 表示す必要があります。適切だと考える方法でこれを行ってください。
    # エラーコード 0 はマージ成功を、1 は解消不能な衝突が結果に残ったことを
    # 示します。それ以外のエラーコードは致命的とみなします。

note: Tag: programlisting
en: @ECHO OFF
    
    REM Configure your favorite diff3/merge program here.
    SET DIFF3="C:\Program Files\Funky Stuff\My Merge Tool.exe"
    
    REM Subversion provides the paths we need as the ninth, tenth, and eleventh 
    REM parameters.  But we only have access to nine parameters at a time, so we
    REM shift our nine-parameter window twice to let us get to what we need.
    SHIFT
    SHIFT
    SET MINE=%7
    SET OLDER=%8
    SET YOURS=%9
    
    REM Call the merge command (change the following line to make sense for
    REM your merge program).
    %DIFF3% --older %OLDER% --mine %MINE% --yours %YOURS%
    
    REM After performing the merge, this script needs to print the contents
    REM of the merged file to stdout.  Do that in whatever way you see fit.
    REM Return an errorcode of 0 on successful merge, 1 if unresolved conflicts
    REM remain in the result.  Any other errorcode will be treated as fatal.
ja: @ECHO OFF
    
    REM ここに自分の好きな diff3/merge プログラムを設定してください。
    SET DIFF3="C:¥Program Files¥Funky Stuff¥My Merge Tool.exe"
    
    REM Subversion は必要となるパスを、9, 10, 11 番目の引数として用意しますが、
    REM 一度にアクセスできる引数の数は 9 個までなので、必要な引数を取得するため
    REM 取得前に 9 個のパラメータウィンドウを二回シフトしておきます。
    SHIFT
    SHIFT
    SET MINE=%7
    SET OLDER=%8
    SET YOURS=%9
    
    REM merge コマンドを呼び出します (merge プログラムで意味を持つように
    REM 以下の行を変更してください。)
    %DIFF3% --older %OLDER% --mine %MINE% --yours %YOURS%
    
    REM マージ処理実行後、このスクリプトはマージされたファイル内容を標準出力に
    REM 表示す必要があります。適切だと考える方法でこれを行ってください。
    REM エラーコード 0 はマージ成功を、1 は解消不能な衝突が結果に残ったことを
    REM 示します。それ以外のエラーコードは致命的とみなします。

note: Tag: title
en: Layered Library Design
ja: 階層化されたライブラリ設計

note: Tag: para
en: Primary interface for client programs
ja: クライアントプログラムへの主要なインターフェース

note: Tag: para
en: Tree and byte-stream differencing routines
ja: ツリーとバイトストリームの差分ルーチン

note: Tag: para
en: Contextual differencing and merging routines
ja: コンテキスト差分とマージルーチン

note: Tag: para
en: Filesystem commons and module loader
ja: ファイルシステムの共通関数と、モジュールローダー

note: Tag: para
en: The Berkeley DB filesystem back-end
ja: Berkeley DB ファイルシステムバックエンド

note: Tag: para
en: The native filesystem (FSFS) back-end
ja: ネイティブファイルシステム (FSFS) バックエンド

note: Tag: para
en: Repository Access commons and module loader
ja: リポジトリアクセスのための共通ルーチンとモジュールローダ

note: Tag: para
en: The WebDAV Repository Access module
ja: WebDAV リポジトリアクセスモジュール

note: Tag: para
en: The local Repository Access module
ja: ローカルリポジトリアクセスモジュール

note: Tag: para
en: The custom protocol Repository Access module
ja: 独自プロトコルによるリポジトリアクセスモジュール

note: Tag: para
en: Repository interface
ja: リポジトリインターフェース

note: Tag: para
en: Miscellaneous helpful subroutines
ja: さまざまな役に立つサブルーチン

note: Tag: para
en: The working copy management library
ja: 作業コピー管理ライブラリ

note: Tag: para
en: Apache authorization module for Subversion repositories access via WebDAV
ja: WebDAV経由で Subversion リポジトリにアクセスするための Apache 認証モジュール。

note: Tag: para
en: Apache module for mapping WebDAV operations to Subversion ones
ja: WebDAV操作をSubversionのものに対応付けるApacheモジュール

note: Tag: title
en: Repository Layer
ja: リポジトリ層

note: Tag: para
en: Make your changes (adds, deletes, property modifications, etc.).
ja: 修正の実行(追加、削除、属性の修正、など)

note: Tag: para
en: Commit your transaction.
ja: トランザクションのコミット

note: Tag: para
en: Once you have committed your transaction, your filesystem modifications are permanently stored as historical artifacts. Each of these cycles generates a single new revision of your tree, and each revision is forever accessible as an immutable snapshot of <quote>the way things were.</quote>
ja: トランザクションをコミットすると、ファイルシステムの変更は歴史上の 出来事として永久に記録されます。このようなそれぞれのサイクルは ツリーに新しいリビジョンを作り、それぞれのリビジョンは<quote>あることが どのようであったか</quote>という純粋なスナップショットとしていつでもアクセス できるようになります。

note: Tag: title
en: The Transaction Distraction
ja: トランザクションを邪魔するもの

note: Tag: para
en: Fortunately for users of the filesystem API, the transaction support provided by the database system itself is hidden almost entirely from view (as should be expected from a properly modularized library scheme). It is only when you start digging into the implementation of the filesystem itself that such things become visible (or interesting).
ja: ファイルシステムAPI利用者にとって幸運なことに、データベースシステム 自身によって用意されているトランザクションサポートは、ほとんどの場合 隠れていて見えません。(普通のモジュール化されたライブラリの設計から 期待されることですが)。ファイルシステム自身の実装を開始する場合に初めて、 そのようなことが見えるように(あるいは興味深く思えるように)なります。

note: Tag: para
en: Unlike most filesystems, though, a path alone is not enough information to identify a file or directory in Subversion. Think of a directory tree as a two-dimensional system, where a node's siblings represent a sort of left-and-right motion, and descending into subdirectories a downward motion. <xref linkend="svn.developer.layerlib.repos.dia-1"/> shows a typical representation of a tree as exactly that.
ja: ほとんどのファイルシステムとは違い、パスだけを指定するのは、Subversion のファイルやディレトクリを特定するのに十分な情報ではありません。 ディレクトリツリーを二次元のシステムと考えてください。ここで、あるノードの 兄弟は、左から右に移動することを表現していて、サブディレトクリに降りていく のは、下向きの移動であると考えてください。<xref linkend="svn.developer.layerlib.repos.dia-1"/> は典型的なツリーの 表現を示しています。

note: Tag: title
en: Files and directories in two dimensions
ja: 二次元の中のファイルとディレクトリ

note: Tag: title
en: Versioning time&mdash;the third dimension!
ja: バージョン化した時刻&mdash;第三の次元!

note: Tag: para
en: As we mentioned earlier, the libsvn_fs API looks and feels like any other filesystem, except that it has this wonderful versioning capability. It was designed to be usable by any program interested in a versioning filesystem. Not coincidentally, Subversion itself is interested in that functionality. But while the filesystem API should be sufficient for basic file and directory versioning support, Subversion wants more&mdash;and that is where libsvn_repos comes in.
ja: 以前指摘したように、libsvn_fs API は他のファイルシステムと見かけは よくにているが、このすばらしいバージョン管理能力だけは例外です。 それはバージョンファイルシステムに興味のあるすべてのプログラマによって 利用できるように設計されました。偶然の一致ではありませんが、 Subversion自身もその機能に興味があります。しかし、ファイルシステムAPI は基本的なファイルとディレクトリのバージョン管理をサポートしていますが Subversionはさらに多くを要求します&mdash;そしてそれはlibsvn_repos が 提供するものです。

note: Tag: para
en: create, open, destroy, and perform recovery steps on a Subversion repository and the filesystem included in that repository.
ja: Subversionリポジトリと、それに含まれるファイルシステム上での ファイルの生成、オープン、削除、そして回復のステップ

note: Tag: para
en: describe the differences between two filesystem trees.
ja: 二つのファイルシステムツリー間の比較の表示

note: Tag: para
en: query for the commit log messages associated with all (or some) of the revisions in which a set of files was modified in the filesystem.
ja: ファイルシステム中で修正されたファイルがあるすべて(あるいは いくつかの)のリビジョンに結びついたコミットログメッセージへの 問い合わせ

note: Tag: para
en: generate a human-readable <quote>dump</quote> of the filesystem, a complete representation of the revisions in the filesystem.
ja: ファイルシステムの可読な<quote>ダンプ</quote>の生成、ファイルシステム中にある リビジョンの完全な表現

note: Tag: para
en: parse that dump format, loading the dumped revisions into a different Subversion repository.
ja: ダンプフォーマットの解析、異なるSubversionリポジトリの中に ダンプされたリビジョンをロードすること

note: Tag: para
en: As Subversion continues to evolve, the repository library will grow with the filesystem library to offer increased functionality and configurable option support.
ja: Subversionが進化し続けるにつれて、リポジトリライブラリは 増えつづける機能と設定可能なオプションをサポートを提供する ために，ファイルシステムライブラリとともに大きくなり続ける でしょう。

note: Tag: title
en: Repository Access Layer
ja: リポジトリアクセス層

note: Tag: title
en: Client Layer
ja: クライアント層

note: Tag: para
en: On the client side, the Subversion working copy is where all the action takes place. The bulk of functionality implemented by the client-side libraries exists for the sole purpose of managing working copies&mdash;directories full of files and other subdirectories which serve as a sort of local, editable <quote>reflection</quote> of one or more repository locations&mdash;and propagating changes to and from the Repository Access layer.
ja: クライアント側から見ると、Subversionの作業コピーは すべての処理が起こる場所です。クライアント側ライブラリによって 実装される機能は、作業コピーの管理というただ一つの目的のために 存在します&mdash;ローカルな場所に何らかの形で提供される ファイルと他のサブディレクトリのあるディレクトリが、一つ以上の リポジトリ位置を<quote>反映した</quote>ものとし、リポジトリアクセス層との間の 変更を伝えたりします。

note: Tag: para
en: Subversion's working copy library, libsvn_wc, is directly responsible for managing the data in the working copies. To accomplish this, the library stores administrative information about each working copy directory within a special subdirectory. This subdirectory, named <filename>.svn</filename>, is present in each working copy directory and contains various other files and directories which record state and provide a private workspace for administrative action. For those familiar with CVS, this <filename>.svn</filename> subdirectory is similar in purpose to the <filename>CVS</filename> administrative directories found in CVS working copies. For more information about the <filename>.svn</filename> administrative area, see <xref linkend="svn.developer.insidewc"/>in this chapter.
ja: Subversionの作業コピーライブラリ、libsvn_wc は作業コピー中の データの管理に直接の責任を負います。これをやるために、このライブラリ は特別なサブディレクトリの中にそれぞれの作業コピーについての管理情報 を格納します。このサブディレクトリは<filename>.svn</filename> という 名前ですが、どの作業コピー中にも存在し、管理に関係した動作を するための状態を記録し、作業スペースを確保するためのさまざまな ファイルやディレクトリを含んでいます。CVSになじみのある人なら、 この<filename>.svn</filename> サブディレクトリは、その目的としては CVSの作業コピーにある管理ディレクトリ<filename>CVS</filename> に よく似ていることがわかると思います。<filename>.svn</filename> 管理領域についての詳細は、この章の <xref linkend="svn.developer.insidewc"/>を参照してください

note: Tag: para
en: The Subversion client library, libsvn_client, has the broadest responsibility; its job is to mingle the functionality of the working copy library with that of the Repository Access Layer, and then to provide the highest-level API to any application that wishes to perform general revision control actions. For example, the function <function>svn_client_checkout()</function> takes a URL as an argument. It passes this URL to the RA layer and opens an authenticated session with a particular repository. It then asks the repository for a certain tree, and sends this tree into the working copy library, which then writes a full working copy to disk (<filename>.svn</filename> directories and all).
ja: Subversionクライアントライブラリ libsvn_client は広範囲の役目を 負います。その仕事は、作業コピーライブラリの機能と、リポジトリアクセス層 の機能を結びつけることで、一般的なリビジョン制御を実行したいと思う すべてのアプリケーションに最上位のAPIを提供することです。たとえば <function>svn_client_checkout()</function> 関数は引数としてURLを とります。この関数は URLを RA層に渡し、特定のリポジトリに認証された セッションを開きます。それからそのリポジトリに特定のツリーを指定し、 このツリーを作業コピーライブラリに送りますが、今度はそのライブラリが 作業コピー全体をディスクに書き込みます(<filename>.svn</filename> ディレクトリを含むすべての情報)。

note: Tag: title
en: Binding Directly&mdash;A Word About Correctness
ja: 直接のバインド&mdash;正確さについての言葉

note: Tag: para
en: If you wrap such a command-line program with yet another program, the second program has access only to already-interpreted (and as we mentioned, likely incomplete) information, which it must <emphasis>again</emphasis> translate into <emphasis>its</emphasis> representation format. With each layer of wrapping, the integrity of the original data is potentially tainted more and more, much like the result of making a copy of a copy (of a copy &hellip;) of a favorite audio or video cassette.
ja: そのようなコマンドラインプログラムを別のプログラムでラップすると、 ラップするほうのプログラムは既に解釈された(そして注意したように おそらく不完全な)情報にアクセスすることができるだけで、それは <emphasis>もう一度</emphasis>、<emphasis>自分に固有の</emphasis> 表現形式に変換しなくてはなりません。それぞれのラッピングの層ごとに、 最初のデータの正確さはどんどん失われていく可能性があり、それはちょうど 自分の好きなオーディオやビデオカセットを繰り返しコピーするときに 起こるような話になってしまいます。

note: Tag: title
en: Inside the Working Copy Administration Area
ja: 作業コピー管理領域の内部

note: Tag: para
en: As we mentioned earlier, each directory of a Subversion working copy contains a special subdirectory called <filename>.svn</filename> which houses administrative data about that working copy directory. Subversion uses the information in <filename>.svn</filename> to keep track of things like:
ja: 以前指摘したように、Subversion作業コピーのディレクトリのそれぞれは <filename>.svn</filename> という名前の特別のサブディレクトリを持ち、 そこに作業コピーディレクトリに関する管理情報を格納します。 Subversion は<filename>.svn</filename> 中の情報を以下のようなことを 記録するのに利用します:

note: Tag: para
en: Which repository location(s) are represented by the files and subdirectories in the working copy directory.
ja: どこにあるリポジトリが、作業コピーディレクトリのファイルやサブディレクトリ によって表現されているのか。

note: Tag: para
en: What revision of each of those files and directories are currently present in the working copy.
ja: どのリビジョンのファイルやディレクトリが現在の作業コピーに あるのか。

note: Tag: para
en: Any user-defined properties that might be attached to those files and directories.
ja: ファイルやディレクトリに結びついたユーザ定義の属性。

note: Tag: para
en: Pristine (un-edited) copies of the working copy files.
ja: 作業コピーファイルの修正元(編集前)コピー。

note: Tag: title
en: The Entries File
ja: Entries ファイル

note: Tag: title
en: Pristine Copies and Property Files
ja: 修正元コピーと属性ファイル

note: Tag: title
en: Using the APIs
ja: APIの利用

note: Tag: title
en: The Apache Portable Runtime Library
ja: Apache Portable Runtime ライブラリ

note: Tag: title
en: Programming with Memory Pools
ja: メモリプールを使ったプログラミング

note: Tag: title
en: URL and Path Requirements
ja: URL と Path の要求

note: Tag: para
en: With remote version control operation as the whole point of Subversion's existence, it makes sense that some attention has been paid to internationalization (i18n) support. After all, while <quote>remote</quote> might mean <quote>across the office</quote>, it could just as well mean <quote>across the globe.</quote> To facilitate this, all of Subversion's public interfaces that accept path arguments expect those paths to be canonicalized, and encoded in UTF-8. This means, for example, that any new client binary that drives the libsvn_client interface needs to first convert paths from the locale-specific encoding to UTF-8 before passing those paths to the Subversion libraries, and then re-convert any resultant output paths from Subversion back into the locale's encoding before using those paths for non-Subversion purposes. Fortunately, Subversion provides a suite of functions (see <filename>subversion/include/svn_utf.h</filename>) that can be used by any program to do these conversions.
ja: Subversion全体の問題としてのリモートバージョン管理操作では、国際化(i18n) のサポートについていくらか注意しておく必要があります。 結局、<quote>リモート</quote>が、<quote>オフィス以外の場所</quote>を意味するのなら、それは <quote>全世界から</quote>という意味でもあります。このような状況に対応するために Subversionのパス引数をとる、すべてのパブリックインターフェースは パスが正規化され、UTF-8でエンコードされているものとします。 これはたとえば、libsvn_clientインターフェースを呼び出す、 新しいクライアントバイナリはすべて、Subversionライブラリにパスを渡す 前に、まずパスをローカルコーディングからUTF-8に変換しなくてはならず、 Subversion からの結果パスを、Subversion以外の目的に利用する前には ローカルコーディングに再変換しなくてはならないということです。 幸運なことに、Subversionはこのような変換が必要な任意のプログラムが 利用できるような関数を用意しています (<filename>subversion/include/svn_utf.h</filename>を参照してください)。

note: Tag: title
en: Using Languages Other than C and C++
ja: C と C++以外の言語の利用

note: Tag: title
en: Using the Repository Layer
ja: リポジトリ層の利用

note: Tag: title
en: Using the Repository Layer with Python
ja: Pythonを使ったリポジトリ層

note: Tag: title
en: Subversion Complete Reference
ja: Subversion リファレンス

note: Tag: para
en: This chapter is intended to be a complete reference to using Subversion. This includes the command line client (<command>svn</command>) and all its subcommands, as well as the repository administration programs (<command>svnadmin</command> and <command>svnlook</command>) and their respective subcommands.
ja: この章はSubversionの完全なリファレンスです。 コマンドラインクライアント (<command>svn</command>) とそのすべてのサブコマンド、 さらにリポジトリ管理プログラム (<command>svnadmin</command>と<command>svnlook</command>) と そのすべてのサブコマンドです。

note: Tag: title
en: The Subversion Command Line Client: <command>svn</command>
ja: Subversion コマンドラインクライアント: <command>svn</command>

note: Tag: para
en: You can find many more examples of how to use most client commands in <xref linkend="svn.tour"/> and commands for managing properties in <xref linkend="svn.advanced.props"/>.
ja: クライアントコマンドの利用法については、もっとたくさんの 例が <xref linkend="svn.tour"/>にあり、属性の管理については <xref linkend="svn.advanced.props"/>にあります。

note: Tag: para
en: Enables auto-props, overriding the <literal>enable-auto-props</literal> directive in the <filename>config</filename> file.
ja: <filename>config</filename>ファイルにある<literal>enable-auto-props</literal> ディレクティブを上書きする形で auto-props を有効にします。

note: Tag: para
en: Instructs Subversion to read configuration information from the specified directory instead of the default location (<filename>.subversion</filename> in the user's home directory).
ja: Subversion にデフォルトの場所(ユーザのホームディレクトリにある<filename>.subversion</filename> )のかわりに特定のディレクトリから設定情報を読み出すように指示します。

note: Tag: para
en: Specifies an external program to use to merge files.
ja: ファイルをマージするために使う外部プログラムを指定します。

note: Tag: para
en: Goes through all the motions of running a command, but makes no actual changes&mdash;either on disk or in the repository.
ja: コマンドの実行をそのままたどりますが、実際の動作はしません &mdash;作業コピーに対しても、リポジトリに対するコマンドにも使えます。

note: Tag: para
en: Specifies an external program to use to edit a log message or a property value. See the <literal>editor-cmd</literal> section in <xref linkend="svn.advanced.confarea.opts.config"/> for ways to specify a default editor.
ja: ログメッセージや属性値を編集するのに使う外部プログラムを指定します。

note: Tag: para
en: Tells Subversion that your commit message is encoded in the charset provided. The default is your operating system's native locale, and you should specify the encoding if your commit message is in any other encoding.
ja: コミットメッセージが指定した文字コード系でエンコードされていることを Subversion に伝えます。 デフォルトはあなたのオペレーティングシステムのもともとの ロケールで、コミットメッセージが別の文字コード系でエンコードされている場合にはそれを 指定する必要があります。

note: Tag: term
en: <option>--extensions</option> (<option>-x</option>) <replaceable>ARGS</replaceable>
ja: <option>--extensions</option>(<option>-x</option>) <replaceable>ARGS</replaceable>

note: Tag: para
en: Forces a suspicious parameter passed to the <option>--message</option> (<option>-m</option>) or <option>--file</option> (<option>-F</option>) options to be accepted as valid. By default, Subversion will produce an error if parameters to these options look like they might instead be targets of the subcommand. For example, if you pass a versioned file's path to the <option>--file</option> (<option>-F</option>) option, Subversion will assume you've made a mistake, that the path was instead intended as the target of the operation, and that you simply failed to provide some other&mdash;unversioned&mdash;file as the source of your log message. To assert your intent and override these types of errors, pass the <option>--force-log</option> option to subcommands that accept log messages.
ja: <option>--messages</option> (<option>-m</option>) や <option>--file</option> (<option>-F</option>) オプションに 渡す疑わしい引数を正しいものとして強制的に受け入れる ように指示します。デフォルトでは、Subversion は正しいサブコマンドで あると解釈するかわりに、そのような引数が間違いであるとして エラーを生成します。 たとえば、バージョン化されたファイルのパスを<option>--file</option> (<option>-F</option>) オプションに渡すと、Subversion はそのパスが 操作対象として意図されていたと考えずに、その引数には間違いがあると みなし、ログメッセージのためのバージョン化されていない元ファイルを 用意することに失敗してしまいます。自分の意図を宣言し、この種のエラー を無視するためには、<option>--force-log</option>オプションをログメッセージ を受け入れるサブコマンドに対して指定する必要があります。

note: Tag: term
en: <option>--help</option> (<option>-h</option> or <option>-?</option>)
ja: <option>--help</option> (<option>-h or -?</option>)

note: Tag: para
en: If used with one or more subcommands, shows the built-in help text for each subcommand. If used alone, it displays the general client help text.
ja: 一つ以上のサブコマンドと一緒に使って、それぞれのサブコマンドの 組み込みヘルプテキストを表示します。このスイッチだけを単独で 使うと、一般的なコマンドクライアントのヘルプテキストを表示します。

note: Tag: para
en: Tells Subversion to ignore ancestry when calculating differences (rely on path contents alone).
ja: Subversion に対して 差分を計算するときに、系統情報を無視するよう指示します(単にパス内容のみを利用します)。

note: Tag: para
en: Tells Subversion to ignore external definitions and the external working copies managed by them.
ja: Subversion に外部定義と外部定義によって管理される外部作業コピー を無視するように指示します。

note: Tag: para
en: Prints output in a format suitable for concatenation.
ja: (他の出力と)連結するのに適した形式で 出力を表示します。

note: Tag: para
en: Show only the first <replaceable>NUM</replaceable> log messages.
ja: 最初の <replaceable>NUM</replaceable>個のログメッセージだけを 表示します。

note: Tag: para
en: Prevents caching of authentication information (e.g. username and password) in the Subversion administrative directories.
ja: 認証情報(ユーザ名やパスワードなど)をSubversion管理ディレクトリにキャッシュしないよう 指示します。

note: Tag: para
en: Disables auto-props, overriding the <literal>enable-auto-props</literal> directive in the <filename>config</filename> file.
ja: <filename>config</filename>ファイル中の<literal>enable-auto-props</literal> ディレクティブを上書きする形で auto-props を無効にします。

note: Tag: para
en: Prevents Subversion from printing differences for added files. The default behavior when you add a file is for <command>svn diff</command> to print the same differences that you would see if you had added the entire contents of an existing (empty) file.
ja: Subversion が追加されたファイルの差分を表示するのを防ぎます。 ファイルを追加した場合のデフォルトの動作は<command>svn diff</command> については、すでに(空の)ファイルが存在していて、そこに新たな ファイルの内容全体が追加された場合の差分の出力と同じになります。

note: Tag: para
en: Prevents Subversion from printing differences for deleted files. The default behavior when you remove a file is for <command>svn diff</command> to print the same differences that you would see if you had left the file but removed all the content.
ja: 削除されたファイルの差分を表示しないようにSubversionに指示します。 デフォルトではファイルを削除したときの<command>svn diff</command>の 出力は、ファイルは削除されずゼロバイトで残っているかのような 形になります。

note: Tag: para
en: Shows files in the status listing that would normally be omitted since they match a pattern in the <literal>global-ignores</literal> configuration option or the <literal>svn:ignore</literal> property. See <xref linkend="svn.advanced.confarea.opts.config"/> and <xref linkend="svn.advanced.props.special.ignore"/> for more information.
ja: <literal>global-ignores</literal>設定オプション、あるいはsvn:ignore属 性にマッチしたため通常なら省略されるようなファイルの ステータス一覧を表示します。 <xref linkend="svn.advanced.confarea.opts.config"/>と <xref linkend="svn.advanced.props.special.ignore"/> にさらに詳しい情報があります。

note: Tag: para
en: Don't automatically unlock files (the default commit behavior is to unlock all files listed as part of the commit). See <xref linkend="svn.advanced.locking"/> for more information.
ja: 自動的にファイルをアンロックしません(デフォルトのコミットの動作は コミットの一環として関連するすべてのファイルをアンロックします)。 より詳しくは<xref linkend="svn.advanced.locking"/>を見て ください。

note: Tag: para
en: In the case of an authentication failure, or insufficient credentials, prevents prompting for credentials (e.g. username or password). This is useful if you're running Subversion inside of an automated script and it's more appropriate to have Subversion fail than to prompt for more information.
ja: 認証が失敗したり十分な許可がないときに、認証要求するのを 抑制します。(たとえば、ユーザ名とパスワード)これは、 Subversionを自動スクリプト中で実行しているようなときで 認証要求させるよりも単に失敗したほうが便利な場合に 役に立ちます。

note: Tag: para
en: Stops a subcommand from recursing into subdirectories. Most subcommands recurse by default, but some subcommands&mdash;usually those that have the potential to remove or undo your local modifications&mdash;do not.
ja: サブディレクトリに対してサブコマンドを再帰的に実行するのを 抑止します。ほとんどのサブコマンドはデフォルトで再帰的に実行 されますが、いくつかのサブコマンド&mdash;普通は、作業コピーの 変更に対する削除や取り消しが起きるようなもの&mdash;はそうでは ありません。

note: Tag: para
en: Pay attention to ancestry when calculating differences.
ja: 差分を計算するときに系統情報を考慮します。

note: Tag: para
en: Indicates that you are providing your password for authentication on the command line&mdash;otherwise, if it is needed, Subversion will prompt you for it.
ja: コマンドライン上で認証用パスワードを指定します&mdash;これを 指定しなければ、必要な場所でSubversion はパスワード入力を 要求してきます。

note: Tag: para
en: Requests that the client print only essential information while performing an operation.
ja: 実行中に重要な情報だけを表示するように指示します。

note: Tag: para
en: Makes a subcommand recurse into subdirectories. Most subcommands recurse by default.
ja: サブコマンドをサブディレクトリに対して再帰的に実行する ようにします。ほとんどのサブコマンドはデフォルトで再帰的な 動作をします。

note: Tag: para
en: Used with the <command>svn switch</command> subcommand, changes the location of the repository that your working copy references. This is useful if the location of your repository changes and you have an existing working copy that you'd like to continue to use. See <command>svn switch</command> for an example.
ja: <command>svn switch</command>サブコマンドと一緒に使うことで作業コピー が参照しているリポジトリの場所を変更します。これは、リポジトリの 場所が移動しても、既に存在している作業コピーを続けて利用したい場合 に便利です。例として、<command>svn switch</command>を参照してください。

note: Tag: para
en: See <xref linkend="svn.tour.revs.keywords"/> for more information.
ja: 詳しくは<xref linkend="svn.tour.revs.keywords"/> を見てください。

note: Tag: para
en: Causes the client to display information about which files in your working copy are out-of-date. This doesn't actually update any of your files&mdash;it just shows you which files will be updated if you run <command>svn update</command>.
ja: 作業コピーのどのファイルが最新であるかの情報を表示します。 これは実際に自分に作業ファイルを更新しません&mdash;もし <command>svn update</command>を実行したとしたら、どの ファイルが更新されるかを表示するだけです。

note: Tag: para
en: Causes a Subversion subcommand which is traversing the history of a versioned resource to stop harvesting that historical information when a copy&mdash;that is, a location in history where that resource was copied from another location in the repository&mdash;is encountered.
ja: Subversion のサブコマンドでバージョン化されたリソースを巡回する ようなものについて、コピーを発見したときには履歴情報の収集を止める ようにします。&mdash; ここで言うコピーとは履歴の中でリポジトリの ほかの場所からコピーされたリソースがあるような場所のことを言って います。

note: Tag: para
en: Tells Subversion to get the list of files that you wish to operate on from the filename you provide instead of listing all the files on the command line.
ja: コマンドライン上にすべてのファイルを記入するかわりに、 指定したファイルから操作したいファイルの一覧を取得するよう Subversion に指示します。

note: Tag: para
en: Indicates that you are providing your username for authentication on the command line&mdash;otherwise, if it is needed, Subversion will prompt you for it.
ja: コマンドライン上での認証に、指定したユーザ名称を使うように 指示します&mdash;そうでなければ、必要な場所で、Subversionは その入力をユーザに求めます。

note: Tag: para
en: Requests that the client print out as much information as it can while running any subcommand. This may result in Subversion printing out additional fields, detailed information about every file, or additional information regarding its actions.
ja: サブコマンド実行時に、できるたけ多くの情報を表示するように 指示します。Subversion は、追加フィールド、すべてのファイルの 詳細情報、動作内容についての追加情報などを表示するようになります。

note: Tag: para
en: Prints output in XML format.
ja: XMLフォーマットで出力します。

note: Tag: title
en: <command>svn</command> Subcommands
ja: <command>svn</command> サブコマンド

note: Tag: refpurpose
en: Add files, directories, or symbolic links.
ja: 通常ファイル、ディレクトリ、シンボリックリンクを追加します。

note: Tag: title
en: Synopsis
ja: 用法

note: Tag: title
en: Alternate Names
ja: 別名

note: Tag: para
en: None
ja: なし

note: Tag: title
en: Changes
ja: 変更対象

note: Tag: para
en: Working Copy
ja: 作業コピー

note: Tag: para
en: <para>No</para>
ja: <para>なし</para>

note: Tag: title
en: Examples
ja: 例

note: Tag: para
en: To add a file to your working copy:
ja: 作業コピーにファイルを追加:

note: Tag: para
en: When adding a directory, the default behavior of <command>svn add</command> is to recurse:
ja: ディレクトリを追加するとき <command>svn add</command> のデフォルトは 再帰的です:

note: Tag: para
en: You can add a directory without adding its contents:
ja: 内部にあるファイルを追加することなしに、ディレクトリのみ追加する ことができます:

note: Tag: para
en: Normally, the command <command>svn add *</command> will skip over any directories that are already under version control. Sometimes, however, you may want to add every unversioned object in your working copy, including those hiding deeper down. Passing the <option>--force</option> option makes <command>svn add</command> recurse into versioned directories:
ja: 通常、コマンド<command>svn add *</command>はすでにバージョン管理下に あるすべてのディレクトリを飛ばします。しかし作業コピーにあるすべての バージョン化されていないオブジェクトを再帰的に追加したいこともあるでしょ う。<command>svn add</command>に <option>--force</option>オプションを渡すと 既にバージョン化されているディレクトリにも再帰的に降りていきます:

note: Tag: refpurpose
en: Show author and revision information in-line for the specified files or URLs.
ja: 指定されたファイルまたは URL の変更者とリビジョン情報をインラインで表示 します。

note: Tag: para
en: Show author and revision information in-line for the specified files or URLs. Each line of text is annotated at the beginning with the author (username) and the revision number for the last change to that line.
ja: 指定されたファイルまたは URL の変更者とリビジョン情報をインラインで表示 します。それぞれのテキスト行には先頭に変更者(ユーザ名)と、最後にその行に 変更があったリビジョン番号の注釈がつきます。

note: Tag: para
en: Nothing
ja: なし

note: Tag: para
en: If you want to see blame annotated source for <filename>readme.txt</filename> in your test repository:
ja: 自分のテスト用リポジトリにある <filename>readme.txt</filename> の注釈付きソースを見たい場合には:

note: Tag: refpurpose
en: Output the contents of the specified files or URLs.
ja: 指定したファイルまたはURLの内容を表示します。

note: Tag: para
en: Output the contents of the specified files or URLs. For listing the contents of directories, see <command>svn list</command>.
ja: 指定したファイルまたはURLの内容を表示します。 ディレクトリの内容の表示については、<command>svn list</command> を見てください。

note: Tag: para
en: If you want to view readme.txt in your repository without checking it out:
ja: チェックアウトすることなしにリポジトリ中のreadme.txtを表示したい 場合:

note: Tag: para
en: If your working copy is out of date (or you have local modifications) and you want to see the <literal>HEAD</literal> revision of a file in your working copy, <command>svn cat</command> will automatically fetch the <literal>HEAD</literal> revision when you give it a path:
ja: 作業コピーが最新ではない(か、作業コピーに何か修正を加えた 場合)状態で、作業コピーのあるファイルの<literal>HEAD</literal> リビジョンを見たい場合、パスを指定すれば<command>svn cat</command> は 自動的に <literal>HEAD</literal>リビジョン にアクセスします:

note: Tag: refpurpose
en: Check out a working copy from a repository.
ja: リポジトリから作業コピーをチェックアウトします。

note: Tag: para
en: Check out a working copy from a repository. If <replaceable>PATH</replaceable> is omitted, the basename of the URL will be used as the destination. If multiple URLs are given each will be checked out into a subdirectory of <replaceable>PATH</replaceable>, with the name of the subdirectory being the basename of the URL.
ja: リポジトリから作業コピーをチェックアウトします。 <replaceable>PATH</replaceable> が省略されれば コピー先としてURLのベース名が使われます。 複数のURLが指定された場合には、 それぞれが、<replaceable>PATH</replaceable>のサブディレクトリに チェックアウトされますが ここでのサブディレクトリの名前はURLのベース名になります。

note: Tag: para
en: Creates a working copy.
ja: 作業コピーが新たに作られます。

note: Tag: para
en: Check out a working copy into a directory called <filename>mine</filename>:
ja: <filename>mine</filename>と呼ばれるディレクトリに作業コピーをチェックアウト:

note: Tag: refpurpose
en: Recursively clean up the working copy.
ja: 作業コピーを再帰的に正常化する。

note: Tag: para
en: Recursively clean up the working copy, removing working copy locks and resuming unfinished operations. If you ever get a <quote>working copy locked</quote> error, run this command to remove stale locks and get your working copy into a usable state again.
ja: 作業コピーを再帰的に正常化するため、操作が未完了の ロックを削除します。<quote>作業コピーロック</quote>エラーが 発生したときには、このコマンドを実行して、ロックを解除し、 作業コピーを正常に戻してください。

note: Tag: para
en: Working copy
ja: 作業コピー

note: Tag: para
en: Well, there's not much to the examples here as <command>svn cleanup</command> generates no output. If you pass no <replaceable>PATH</replaceable>, <quote><filename>.</filename></quote> is used.
ja: <command>svn cleanup</command> は何も出力しないので、あまり例はありません。 もし、<replaceable>PATH</replaceable> を指定しなければ、<quote><filename>.</filename></quote>をかわりに使います。

note: Tag: refpurpose
en: Send changes from your working copy to the repository.
ja: 作業コピーの変更点をリポジトリに送ります。

note: Tag: para
en: If you begin a commit and Subversion launches your editor to compose the commit message, you can still abort without committing your changes. If you want to cancel your commit, just quit your editor without saving your commit message and Subversion will prompt you to either abort the commit, continue with no message, or edit the message again.
ja: コミット処理を始め、Subversionがメッセージ作成のためのエディタを起動 した後でもまだ変更をコミットせず中断することができます。コミットを 取り消したければコミットメッセージを保存せずに単にエディタを終了 してください。Subversionはコミットを中断するか、メッセージなしで継続 するか、メッセージを再編集するかを聞いてきます。

note: Tag: para
en: ci (short for <quote>check in</quote>; not <quote>co</quote>, which is short for <quote>checkout</quote>)
ja: ci (<quote>check in</quote> の短縮形です; <quote>co</quote>ではありません。 <quote>co</quote>は<quote>checkout</quote>の短縮形です。)

note: Tag: para
en: Working copy, repository
ja: 作業コピー、リポジトリ

note: Tag: para
en: Commit a simple modification to a file with the commit message on the command line and an implicit target of your current directory (<quote><filename>.</filename></quote>):
ja: コマンドラインで指定したコミットメッセージとカレントディレクトリ (<quote><filename>.</filename></quote>)を暗黙のターゲットとして単純な変更をコミットします:

note: Tag: para
en: Commit a modification to the file <filename>foo.c</filename> (explicitly specified on the command line) with the commit message in a file named <literal>msg</literal>:
ja: ファイル<filename>foo.c</filename> (コマンドラインで明示的に 指定) の変更点を、ファイル<literal>msg</literal>の内容をコミットメッセージと してコミット:

note: Tag: screen
en: $ svn commit --file file_under_vc.txt foo.c
    svn: The log message file is under version control
    svn: Log message file is a versioned file; use '--force-log' to override
    
    $ svn commit --force-log --file file_under_vc.txt foo.c
    Sending        foo.c
    Transmitting file data .
    Committed revision 6.
ja: $ svn commit --file file_under_vc.txt foo.c
    svn: The log message file is under version control
    svn: Log message file is a versioned file; use `--force-log' to override
    
    $ svn commit --force --file-log file_under_vc.txt foo.c
    Sending        foo.c
    Transmitting file data .
    Committed revision 6.

note: Tag: para
en: To commit a file scheduled for deletion:
ja: 削除予告ファイルをコミット:

note: Tag: refpurpose
en: Copy a file or directory in a working copy or in the repository.
ja: 作業コピーやリポジトリ中の、 ファイルやディレクトリをコピー。

note: Tag: para
en: Copy a file in a working copy or in the repository. <replaceable>SRC</replaceable> and <replaceable>DST</replaceable> can each be either a working copy (WC) path or URL:
ja: 作業コピーまたはリポジトリ中のファイルをコピーします。 <replaceable>SRC</replaceable> と <replaceable>DST</replaceable> は、作業コピー(WC)上のパスでも、URLでもかまいません:

note: Tag: para
en: Copy and schedule an item for addition (with history).
ja: 追加用にファイルをコピーし、追加予告します。 (with history).

note: Tag: para
en: Immediately commit a copy of WC to URL.
ja: WCのコピーを直接URLにコミット。

note: Tag: para
en: Check out URL into WC, and schedule it for addition.
ja: URLをWCにチェックアウトし、追加予告する。

note: Tag: para
en: Complete server-side copy. This is usually used to branch and tag.
ja: 完全なサーバ上のみでのコピー。これは普通ブランチやタグに 利用されます。

note: Tag: para
en: You can only copy files within a single repository. Subversion does not support cross-repository copying.
ja: ファイルは一つのリポジトリの内部でのみコピー可能です。 Subversionはリポジトリ間コピーをサポートしていません。

note: Tag: para
en: Repository if destination is a URL.
ja: コピー先が URL である場合はリポジトリ。

note: Tag: para
en: Working copy if destination is a WC path.
ja: コピー先が作業コピーのパスである場合は作業コピー。

note: Tag: para
en: If source or destination is in the repository, or if needed to look up the source revision number.
ja: コピー元またはコピー先がリポジトリであるか、 ソースリビジョン番号を参照する必要がある場合には発生 する。

note: Tag: screen
en: --message (-m) TEXT
    --file (-F) FILE
    --revision (-r) REV
    --quiet (-q)
    --username USER
    --password PASS
    --no-auth-cache
    --non-interactive
    --force-log
    --editor-cmd EDITOR
    --encoding ENC
    --config-dir DIR
ja: --message (-m) TEXT
    --file (-F) FILE
    --revision (-r) REV
    --quiet (-q)
    --username USER
    --password PASS
    --no-auth-cache
    --non-interactive
    --editor-cmd EDITOR
    --encoding ENC
    --config-dir DIR

note: Tag: para
en: Copy an item within your working copy (just schedules the copy&mdash;nothing goes into the repository until you commit):
ja: 作業コピー中のファイルまたはディレクトリをコピー( コピー予告のみ&mdash;次のコミットまでリポジトリには何も 起こらない):

note: Tag: para
en: Copy an item in your working copy to a URL in the repository (an immediate commit, so you must supply a commit message):
ja: リポジトリ中の URL に作業コピー中のファイルまたはディレクトリ をコピー(同時にコミットされるので、コミットメッセージを 指定する必要あり):

note: Tag: para
en: Copy an item from the repository to your working copy (just schedules the copy&mdash;nothing goes into the repository until you commit):
ja: リポジトリのファイルまたはディレクトリを作業コピーに コピー(コピーの予告のみ&mdash;次のコミットまでリポジトリには 何も起こらない):

note: Tag: para
en: This is the recommended way to resurrect a dead file in your repository!
ja: これはリポジトリ中の死んだファイルを復活させるおすすめの 方法です

note: Tag: para
en: And finally, copying between two URLs:
ja: そして最後に二つのURLの間でコピーする方法:

note: Tag: para
en: This is the easiest way to <quote>tag</quote> a revision in your repository&mdash;just <command>svn copy</command> that revision (usually <literal>HEAD</literal>) into your tags directory.
ja: リポジトリ中のリビジョンに<quote>tag</quote>をつける一番簡単な方法 &mdash;そのリビジョン(普通は<literal>HEAD</literal>)をタグ付けされた ディレクトリに、単に <command>svn copy</command> する。

note: Tag: para
en: And don't worry if you forgot to tag&mdash;you can always specify an older revision and tag anytime:
ja: そのタグを忘れるのを心配する必要はありません&mdash; いつでも古いリビジョンを指定してタグ付けすることが できます:

note: Tag: refpurpose
en: Delete an item from a working copy or the repository.
ja: 作業コピーかリポジトリから ファイルまたはディレクトリを削除します。

note: Tag: para
en: Items specified by URL are deleted from the repository via an immediate commit. Multiple URLs are committed atomically.
ja: URLで指定されたファイルまたはディレクトリは 直接コミットを発行する形で削除されます。複数の URL は単一のトランザクションと して不分割にコミットされます。

note: Tag: para
en: Only if operating on URLs
ja: URLに対して操作した場合のみ発生する

note: Tag: screen
en: --force
    --force-log
    --message (-m) TEXT
    --file (-F) FILE
    --quiet (-q)
    --targets FILENAME
    --username USER
    --password PASS
    --no-auth-cache
    --non-interactive
    --editor-cmd EDITOR
    --encoding ENC
    --config-dir DIR
ja: --force
    --force-log
    --message (-m) TEXT
    --file (-F) FILE
    --quiet (-q)
    --targets FILENAME
    --username USER
    --password PASS
    --no-auth-cache
    --non-interactive
    --encoding ENC

note: Tag: para
en: Deleting a URL, however, is immediate, so you have to supply a log message:
ja: URLを削除しますが、それは直ちに起こるので ログメッセージを指定する必要があります:

note: Tag: para
en: Here's an example of how to force deletion of a file that has local mods:
ja: この例は作業コピーに修正があるファイルを強制削除する方法です:

note: Tag: programlisting
en: diff OLD-URL[@OLDREV] NEW-URL[@NEWREV]
ja: svn diff OLD-URL[@OLDREV] NEW-URL[@NEWREV]

note: Tag: para
en: <command>svn diff -r N:M URL</command> is shorthand for <command>svn diff -r N:M --old=URL --new=URL</command>.
ja: <command>svn diff -r N:M URL</command> は <command>svn diff -r N:M --old=URL --new=URL</command>の略記法です。

note: Tag: para
en: <command>svn diff [-r N[:M]] URL1[@N] URL2[@M]</command> is shorthand for <command>svn diff [-r N[:M]] --old=URL1 --new=URL2</command>.
ja: <command>svn diff [-r N[:M]] URL1[@N] URL2[@M]</command> は <command>svn diff [-r N[:M]] --old=URL1 --new=URL2</command>の略記法です。

note: Tag: para
en: If <replaceable>TARGET</replaceable> is a URL, then revs N and M can be given either via the <option>--revision</option> or by using <quote>@</quote> notation as described earlier.
ja: <replaceable>TARGET</replaceable> が URL なら N と M のリビジョンは <option>--revision</option>を経由したものであるか既に述べたように <quote>@</quote>記法で指定されたものになります。

note: Tag: para
en: The server compares <replaceable>TARGET</replaceable>@<replaceable>N</replaceable> and <replaceable>TARGET</replaceable>@<replaceable>M</replaceable>.
ja: サーバは <replaceable>TARGET</replaceable>@<replaceable>N</replaceable> と <replaceable>TARGET</replaceable>@<replaceable>M</replaceable> を比較します。

note: Tag: para
en: The client compares <replaceable>TARGET</replaceable>@<replaceable>N</replaceable> against working copy.
ja: クライアントは <replaceable>TARGET</replaceable>@<replaceable>N</replaceable> と作業コピーを比較します。

note: Tag: para
en: The client compares base and working copies of <replaceable>TARGET</replaceable>.
ja: クライアントは <replaceable>TARGET</replaceable>のベースリビジョンと作業コピーを 比較します。

note: Tag: para
en: If the alternate syntax is used, the server compares <replaceable>URL1</replaceable> and <replaceable>URL2</replaceable> at revisions <replaceable>N</replaceable> and <replaceable>M</replaceable> respectively. If either <replaceable>N</replaceable> or <replaceable>M</replaceable> are omitted, a value of <literal>HEAD</literal> is assumed.
ja: 別の構文を使うとサーバはそれぞれリビジョン <replaceable>N</replaceable>と <replaceable>M</replaceable>にある <replaceable>URL1</replaceable>と <replaceable>URL2</replaceable> を比較します。もしNかMが省略されれば <replaceable>HEAD</replaceable> の値が使われます。

note: Tag: para
en: By default, <command>svn diff</command> ignores the ancestry of files and merely compares the contents of the two files being compared. If you use <option>--notice-ancestry</option>, the ancestry of the paths in question will be taken into consideration when comparing revisions (that is, if you run <command>svn diff</command> on two files with identical contents but different ancestry you will see the entire contents of the file as having been removed and added again).
ja: デフォルトでは<command>svn diff</command>はファイルの系統を無視し、 単に比較対象になっている二つのファイルの内容を比較するだけです。 <option>--notice-ancestry</option>を使うとリビジョンを比較する際に、 問題になっているパスの系統が考慮されます(つまり、同じ内容を持っては いるが異なる系統を持つ二つのファイルに対して<command>svn diff</command>を実行すると、ファイル全体が一度削除され、 もう一度すべてが追加された形の結果を得ることになります)。

note: Tag: para
en: For obtaining differences against anything but <literal>BASE</literal> revision in your working copy
ja: 相違点を知るのに必要な場合は発生する。ただし作業コピーの <literal>BASE</literal>リビジョンを取得する場合は除く。

note: Tag: para
en: Compare <literal>BASE</literal> and your working copy (one of the most popular uses of <command>svn diff</command>):
ja: <literal>BASE</literal>リビジョンと作業コピーを比較します。(<command>svn diff</command> の一番よくある使い方):

note: Tag: para
en: See how your working copy's modifications compare against an older revision:
ja: 作業コピーの変更を以前のリビジョンと比較する方法:

note: Tag: para
en: Compare revision 3000 to revision 3500 using <quote>@</quote> syntax:
ja: リビジョン3000とリビジョン3500を<quote>@</quote>構文を使って比較:

note: Tag: para
en: Compare revision 3000 to revision 3500 using range notation (you only pass the one URL in this case):
ja: リビジョン3000とリビジョン3500を範囲指定で比較( この場合は一つのURLのみを渡せばいい):

note: Tag: para
en: Compare revision 3000 to revision 3500 of all files in <filename>trunk</filename> using range notation:
ja: 範囲指定によって <filename>trunk</filename>にある全てのファイルの リビジョン 3000 と リビジョン 3500 を比較する:

note: Tag: para
en: Compare revision 3000 to revision 3500 of only three files in <filename>trunk</filename> using range notation:
ja: 範囲指定によって <filename>trunk</filename>にある三つのファイルに ついてのみリビジョン 3000 と リビジョン 3500 を比較する:

note: Tag: para
en: If you have a working copy, you can obtain the differences without typing in the long URLs:
ja: 作業コピーがある場合、長い URL指定することなしに 相違点を取得することができます:

note: Tag: para
en: Use <option>--diff-cmd</option> <replaceable>CMD</replaceable> <option>-x</option> to pass arguments directly to the external diff program
ja: <option>--diff-cmd</option> <replaceable>CMD</replaceable> <option>-x</option> を使って 外部 diff プログラムに直接引数を渡します

note: Tag: refpurpose
en: Export a clean directory tree.
ja: ディレクトリツリーのエクスポート

note: Tag: para
en: The first form exports a clean directory tree from the repository specified by URL, at revision <replaceable>REV</replaceable> if it is given, otherwise at <literal>HEAD</literal>, into <replaceable>PATH</replaceable>. If <replaceable>PATH</replaceable> is omitted, the last component of the <replaceable>URL</replaceable> is used for the local directory name.
ja: 最初の構文では指定されたURLのリポジトリからディレクトリツリーを エクスポートします。このさい、<replaceable>REV</replaceable> が指定されれば リビジョン <replaceable>REV</replaceable> から、 そうでなければ <literal>HEAD</literal>のリビジョンが利用され、結果は <replaceable>PATH</replaceable>に出力されます。 <replaceable>PATH</replaceable>が省略されれば<replaceable>URL</replaceable>の 最後の部分がローカルディレクトリ名称として利用されます。

note: Tag: para
en: The second form exports a clean directory tree from the working copy specified by <replaceable>PATH1</replaceable> into <replaceable>PATH2</replaceable>. All local changes will be preserved, but files not under version control will not be copied.
ja: 二番目の構文では <replaceable>PATH1</replaceable>で指定されたローカル作業コピーを <replaceable>PATH2</replaceable>に出力 します。すべての作業コピーへの変更は保存されますが、バージョン管理下 にないファイルはコピーされません。

note: Tag: para
en: Local disk
ja: ローカルディスク

note: Tag: para
en: Only if exporting from a URL
ja: URLからのエクスポートの場合のみ発生する

note: Tag: para
en: Export from your working copy (doesn't print every file and directory):
ja: 作業コピーからのエクスポート( すべてのファイルとディレクトリをいちいち表示しない):

note: Tag: para
en: Export directly from the repository (prints every file and directory):
ja: リポジトリから直接エクスポート( すべてのファイルとディレクトリを表示):

note: Tag: para
en: When rolling operating-system-specific release packages, it can be useful to export a tree which uses a specific EOL character for line endings. The <option>--native-eol</option> option will do this, but it only affects files that have <literal>svn:eol-style = native</literal> properties attached to them. For example, to export a tree with all CRLF line endings (possibly for a Windows .zip file distribution):
ja: オペレーティングシステムごとのリリースパッケージを作る場合、行末に特定 の EOL文字を使ってエクスポートすることができると便利です。<option>--native-eol</option> オプションはこれをしますが、それはファイルが <literal>svn:eol-style = native</literal>属性を持っているものだけに効果があります。 たとえばすべてが CRLF 改行を持っているファイルからなるツリーをエクスポー トする場合(おそらく Windows の .zip ファイルでの配布のような場合が考え られますが):

note: Tag: para
en: This is your best friend when you're using Subversion and this book isn't within reach!
ja: Subversionを使う場合の最良のガイドで、それに比べたらこの本などは 及びません!

note: Tag: refpurpose
en: Commit an unversioned file or tree into the repository.
ja: バージョン管理されていないファイルやツリーをリポジトリに コミットします。

note: Tag: para
en: Recursively commit a copy of <replaceable>PATH</replaceable> to <replaceable>URL</replaceable>. If <replaceable>PATH</replaceable> is omitted <quote><filename>.</filename></quote> is assumed. Parent directories are created in the repository as necessary.
ja: <replaceable>PATH</replaceable>のコピーを再帰的に <replaceable>URL</replaceable>にコミットします。 <replaceable>PATH</replaceable> がなければ <quote><filename>.</filename></quote> が仮定されます。 必要に応じて親ディレクトリがリポジトリに作られます。

note: Tag: para
en: Repository
ja: リポジトリ

note: Tag: para
en: After importing data, note that the original tree is <emphasis>not</emphasis> under version control. To start working, you still need to <command>svn checkout</command> a fresh working copy of the tree.
ja: データほインポートした後でも、もとのツリーがバージョン 管理下に入ったわけ<emphasis>ではない</emphasis>のに注意し てください。作業を始めるには、まずそのツリーのための新しい作業コ ピーを<command>svn checkout</command>コマンドで作る必要が あります。

note: Tag: refpurpose
en: Display information about a local or remote item.
ja: ローカル、あるいはリモートパスにあるアイテムについての情報を表示します。

note: Tag: para
en: Path
ja: パス

note: Tag: para
en: Name
ja: 名前

note: Tag: para
en: Repository Root
ja: リポジトリのルート

note: Tag: para
en: Repository UUID
ja: リポジトリの UUID

note: Tag: para
en: Node Kind
ja: ノードの種類

note: Tag: para
en: Last Changed Author
ja: 最後に修正した人

note: Tag: para
en: Last Changed Revision
ja: 最後に修正したリビジョン

note: Tag: para
en: Last Changed Date
ja: 最後に修正した日時

note: Tag: para
en: Lock Token
ja: ロック・トークン

note: Tag: para
en: Lock Owner
ja: ロックの所有者

note: Tag: para
en: Text Last Updated
ja: 最後に更新したテキスト

note: Tag: para
en: Properties Last Updated
ja: 最後に更新した属性

note: Tag: para
en: Checksum
ja: チェックサム

note: Tag: para
en: <command>svn info</command> will show you all the useful information that it has for items in your working copy. It will show information for files:
ja: <command>svn info</command> は作業コピー中の ファイルまたはディレクトリに関する有用な情報を表示します。 次はファイルに関する情報を表示します:

note: Tag: para
en: It will also show information for directories:
ja: ディレクトリに対する情報を表示することもできます:

note: Tag: para
en: <command>svn info</command> also acts on URLs (also note that the file readme.doc in this example is locked, so lock information is also provided):
ja: <command>svn info</command> は URL に対しても処理することができます(この例での readme.doc ファイルはロックされているので、ロック情報もまた 表示されていることに注意してください):

note: Tag: refpurpose
en: List directory entries in the repository.
ja: リポジトリ中のディレクトリエントリを一覧表示します。

note: Tag: para
en: List each <replaceable>TARGET</replaceable> file and the contents of each <replaceable>TARGET</replaceable> directory as they exist in the repository. If <replaceable>TARGET</replaceable> is a working copy path, the corresponding repository URL will be used.
ja: それぞれの <replaceable>TARGET</replaceable> ファイルと <replaceable>TARGET</replaceable> ディレクトリのリポジトリ 中の内容を一覧表示します。 <replaceable>TARGET</replaceable> が作業コピーのパスである場合、対応するリポジトリ URL が利用されます。

note: Tag: para
en: The default <replaceable>TARGET</replaceable> is <quote><filename>.</filename></quote>, meaning the repository URL of the current working copy directory.
ja: デフォルトの <replaceable>TARGET</replaceable> 値は <quote><filename>.</filename></quote> で、現在の作業コピーディレクトリ のリポジトリURLを意味します。

note: Tag: para
en: Revision number of the last commit
ja: 最後のコミットのリビジョン番号

note: Tag: para
en: Author of the last commit
ja: 最後のコミットをした人

note: Tag: para
en: Size (in bytes)
ja: データサイズ (バイト単位の)

note: Tag: para
en: Date and time of the last commit
ja: 最後のコミットの日時

note: Tag: para
en: With <option>--xml</option>, output is in XML format (with a header and an enclosing document element unless <option>--incremental</option> is also specified). All of the information is present; the <option>--verbose</option> option is not accepted.
ja: <option>--xml</option> オプションをつけると XML 形式で 出力します( <option>--incremental</option> を同時に指定し なければヘッダとタグでくくられたドキュメント要素も一緒に出力され ます)。すべての情報が対象になります; <option>--verbose</option> オプションは認められません。

note: Tag: para
en: <command>svn list</command> is most useful if you want to see what files a repository has without downloading a working copy:
ja: <command>svn list</command> は、作業コピーを ダウンロードすることなしにどんなファイルがリポジトリにあるかを知る ときに役立ちます:

note: Tag: screen
en: $ svn list --verbose file:///tmp/repos
         16 sally         28361 Jan 16 23:18 README.txt
         27 sally             0 Jan 18 15:27 INSTALL
         24 harry               Jan 18 11:27 examples/
ja: $ svn list --verbose file:///tmp/repos
         16 sally         28361 Jan 16 23:18 README.txt
         27 sally             0 Jan 18 15:27 INSTALL
         24 harry               Jan 18 11:27 例/

note: Tag: refpurpose
en: Lock working copy paths or URLs in the repository, so that no other user can commit changes to them.
ja: 作業コピーパスまたはリポジトリ中の URL をロックし、他のユーザがそこに 変更点をコミットできないようにします。

note: Tag: para
en: Lock each <replaceable>TARGET</replaceable>. If any <replaceable>TARGET</replaceable> is already locked by another user, print a warning and continue locking the rest of the <replaceable>TARGET</replaceable>s. Use <option>--force</option> to steal a lock from another user or working copy.
ja: <replaceable>TARGET</replaceable>それぞれをロックします。 他のユーザによってすでに <replaceable>TARGET</replaceable>のどれかが ロックされていた場合、警告を出して残りの<replaceable>TARGET</replaceable> をロックします。他のユーザ、あるいは作業コピーの設定したロックを <option>--force</option>オプションで横取りすることもできます。

note: Tag: para
en: Working Copy, Repository
ja: 作業コピー、リポジトリ

note: Tag: para
en: Lock two files in your working copy:
ja: 作業コピー中のふたつのファイルをロックする:

note: Tag: para
en: Lock a file in your working copy that is currently locked by another user:
ja: 他のユーザによって現在ロックされている作業コピー中の ファイルをロックする:

note: Tag: para
en: Lock a file without a working copy:
ja: 作業コピーに関係しないファイルをロックする:

note: Tag: para
en: For further details, see <xref linkend="svn.advanced.locking"/>.
ja: より詳細は <xref linkend="svn.advanced.locking"/>を見てください。

note: Tag: refpurpose
en: Display commit log messages.
ja: コミットログメッセージの表示。

note: Tag: para
en: If you specify a URL alone, then it prints log messages for everything that the URL contains. If you add paths past the URL, only messages for those paths under that URL will be printed. The default revision range for a URL is <literal>HEAD:1</literal>.
ja: URLだけを指定すれば、その URL に含まれるすべてのログメッセージが 表示されます。URLの後にパスを付ければ URL中のそれらのパスに含まれる メッセージだけが表示されます。URL のデフォルトリビジョン範囲は <literal>HEAD:1</literal> です。

note: Tag: para
en: With <option>--verbose</option>, <command>svn log</command> will also print all affected paths with each log message. With <option>--quiet</option>, <command>svn log</command> will not print the log message body itself (this is compatible with <option>--verbose</option>).
ja: <option>--verbose</option> を指定すると<command>svn log</command> はそれぞれのログメッセージと共に関連したすべてのパスを表示します。 <option>--quiet</option> を指定すると <command>svn log</command> はログメッセージの本体部分を表示しなくなります(これは <option>--verbose</option> スイッチと両立します)。

note: Tag: para
en: Each log message is printed just once, even if more than one of the affected paths for that revision were explicitly requested. Logs follow copy history by default. Use <option>--stop-on-copy</option> to disable this behavior, which can be useful for determining branch points.
ja: それぞれのログメッセージは、そのリビジョンに影響のあるパスが二度 以上要求されても、一度だけ表示されます。ログはデフォルトではコピーされた 履歴に従います。<option>--stop-on-copy</option> はこの振る舞いを無効にしますが、ブランチが 起きた場所を特定する場合には役に立ちます。

note: Tag: para
en: You can see the log messages for all the paths that changed in your working copy by running <command>svn log</command> from the top:
ja: 最上位で <command>svn log</command> を実行することによって作業コピー中の変更されたすべての パスのログメッセージを見ることができます:

note: Tag: para
en: Examine all log messages for a particular file in your working copy:
ja: 作業コピー中の特定のファイルに関するすべてのログメッセージを調べます:

note: Tag: para
en: If you don't have a working copy handy, you can log a URL:
ja: 作業コピーが手元にない場合、URLを log することができます:

note: Tag: para
en: If you want several distinct paths underneath the same URL, you can use the <literal>URL [PATH...]</literal> syntax.
ja: 同じURLの下のいくつかの別のパスがほしい場合<literal>URL [PATH...] </literal> 構文を使うことができます。

note: Tag: para
en: However, if you wanted to gather 2 non-sequential log messages into a file, you might do something like this:
ja: しかし、二つの順番になっていないログメッセージをファイルに 出力したい場合、何か次のような感じになるでしょう:

note: Tag: para
en: If you run <command>svn log</command> on a specific path and provide a specific revision and get no output at all
ja: もし <command>svn log</command> を特定のパス上の特定のリビジョン指定で実行すると 何も出力されないでしょう

note: Tag: para
en: That just means that the path was not modified in that revision. If you log from the top of the repository, or know the file that changed in that revision, you can specify it explicitly:
ja: それはパスはリビジョンによっては修正されなかったことを意味 しています。リポジトリの最上位で log するか、そのリビジョンで 修正したファイルを知っているなら、明示的にそれを指定することが できます:

note: Tag: refpurpose
en: Apply the differences between two sources to a working copy path.
ja: 二つのソースの差を作業コピーパスに反映します。

note: Tag: para
en: In the first and second forms, the source paths (URLs in the first form, working copy paths in the second) are specified at revisions <replaceable>N</replaceable> and <replaceable>M</replaceable>. These are the two sources to be compared. The revisions default to <literal>HEAD</literal> if omitted.
ja: 最初の形式と二番目の形式ではソースとなるパス(これは最初の形式ではURL, 二番目の形式では作業コピーパスとなります)はリビジョン <replaceable>N</replaceable> と <replaceable>M</replaceable> で指定され、 その二つが比較されます。リビジョンが省略されれば <literal>HEAD</literal> を指定されたものと みなします。

note: Tag: para
en: In the third form, <replaceable>SOURCE</replaceable> can be a URL or working copy item, in which case the corresponding URL is used. This URL, at revisions <replaceable>N</replaceable> and <replaceable>M</replaceable>, defines the two sources to be compared.
ja: 三番目の形式では <replaceable>SOURCE</replaceable> は URL か、作業コピーアイテムであり、その場合、 対応した URLが利用されます。この、リビジョン <replaceable>N</replaceable> と <replaceable>M</replaceable> のURLが、比較対象と なります。

note: Tag: para
en: <replaceable>WCPATH</replaceable> is the working copy path that will receive the changes. If <replaceable>WCPATH</replaceable> is omitted, a default value of <quote><filename>.</filename></quote> is assumed, unless the sources have identical basenames that match a file within <quote><filename>.</filename></quote>: in which case, the differences will be applied to that file.
ja: <replaceable>WCPATH</replaceable> が変更を受け取る作業コピーパスです。もし <replaceable>WCPATH</replaceable>が省略されると、 デフォルトとして <quote><filename>.</filename></quote>が利用されます。ただし、両方のソースのベース名が同じで、 さらに、その名前のファイルが <quote><filename>.</filename></quote>にある場合は別で、この場合は、差分はその ファイルに適用されます。

note: Tag: para
en: Unlike <command>svn diff</command>, the merge command takes the ancestry of a file into consideration when performing a merge operation. This is very important when you're merging changes from one branch into another and you've renamed a file on one branch but not the other.
ja: <command>svn diff</command>とは違い、マージコマンドはマージ操作の実行 時にファイルの系統を考慮します。これはあるブランチでの変更点を別の ブランチにマージする場合に、あるブランチでは名称を変更したが、もう一方 ではそうしなかったような場合に非常に重要になります。

note: Tag: para
en: Only if working with URLs
ja: URLに対して動作するときのみ発生する

note: Tag: para
en: Merge a branch back into the trunk (assuming that you have a working copy of the trunk, and that the branch was created in revision 250):
ja: ブランチを主系にマージします (主系の作業コピーがあり、ブランチがリビジョン250で作られたと仮定します):

note: Tag: para
en: If you branched at revision 23, and you want to merge changes on trunk into your branch, you could do this from inside the working copy of your branch:
ja: リビジョン23で分岐(ブランチ化)して、そのブランチの中の主系に変更を マージしたいとします。これにはブランチの作業コピーの中で以下のような操作を します:

note: Tag: para
en: To merge changes to a single file:
ja: 変更を一つのファイルにマージするには:

note: Tag: screen
en: $ cd myproj
    $ svn merge -r 30:31 thhgttg.txt 
    U  thhgttg.txt
ja: $ cd myproj
    $ svn merge -r 30:31 thhgttg.txt
    U  thhgttg.txt

note: Tag: refpurpose
en: Create a new directory under version control.
ja: バージョン管理下にある新しいディレクトリを作ります。

note: Tag: para
en: Create a directory with a name given by the final component of the <replaceable>PATH</replaceable> or URL. A directory specified by a working copy <replaceable>PATH</replaceable> is scheduled for addition in the working copy. A directory specified by a URL is created in the repository via an immediate commit. Multiple directory URLs are committed atomically. In both cases all the intermediate directories must already exist.
ja: <replaceable>PATH</replaceable> または URLを最後の部分とするようなディレクトリを作ります。 作業コピー <replaceable>PATH</replaceable> で指定されたディレクトリは作業コピーへの追加として 予告されます。URL によって指定されたディレクトリは作成と同時に コミットされます。複数のディレクトリ URL は不分割にコミットされます。 どちらの場合でも途中のディレクトリはすべて存在していなくてはなりません。

note: Tag: para
en: Working copy, repository if operating on a URL
ja: 作業コピー。URLを指定した場合はリポジトリ

note: Tag: para
en: Only if operating on a URL
ja: URLを指定した場合は発生する

note: Tag: para
en: Create a directory in your working copy:
ja: 作業コピー中にディレクトリを作る:

note: Tag: para
en: Create one in the repository (instant commit, so a log message is required):
ja: リポジトリに作る(コミットが発生するのでログメッセージを 指定する必要がある) :

note: Tag: refpurpose
en: Move a file or directory.
ja: ファイルやディレクトリを移動する。

note: Tag: para
en: This command moves a file or directory in your working copy or in the repository.
ja: このコマンドは作業コピーまたはリポジトリにある ファイルやディレクトリを移動します。

note: Tag: para
en: This command is equivalent to an <command>svn copy</command> followed by <command>svn delete</command>.
ja: このコマンドは、<command>svn copy</command> の後に <command>svn delete</command>を実行するのと同じことです。

note: Tag: para
en: Subversion does not support moving between working copies and URLs. In addition, you can only move files within a single repository&mdash;Subversion does not support cross-repository moving.
ja: Subversionでは作業コピーとURLの間の移動はサポートしていません。 さらに、ファイルの移動は一つのリポジトリの内部でのみ可能です&mdash; Subversionはリポジトリ間の移動をサポートしていません。

note: Tag: para
en: Move and schedule a file or directory for addition (with history).
ja: 移動してから、ファイルやディレクトリを追加予告します。

note: Tag: para
en: Complete server-side rename.
ja: サーバ上での名称変更

note: Tag: para
en: Move a file in your working copy:
ja: 作業コピーのファイルを移動:

note: Tag: para
en: Move a file in the repository (an immediate commit, so it requires a commit message):
ja: リポジトリのファイルを移動(コミットが発生するので コミットメッセージを指定する必要がある):

note: Tag: screen
en: $ svn move -m "Move a file" http://svn.red-bean.com/repos/foo.c \
                                http://svn.red-bean.com/repos/bar.c
    
    Committed revision 27.
ja: $ svn move -m "Move a file" http://svn.red-bean.com/repos/foo.c ¥
                                http://svn.red-bean.com/repos/bar.c
    
    Committed revision 27.

note: Tag: refpurpose
en: Remove a property from an item.
ja: アイテムから属性を削除します。

note: Tag: para
en: Working copy, repository only if operating on a URL
ja: 作業コピー。URLを指定した場合はリポジトリ

note: Tag: para
en: Delete a property from a file in your working copy
ja: 作業コピーのファイルから属性を削除する

note: Tag: para
en: Delete a revision property:
ja: リビジョン属性を削除する:

note: Tag: refpurpose
en: Edit the property of one or more items under version control.
ja: バージョン管理されている一つ以上のアイテムの属性を編集する。

note: Tag: para
en: <command>svn propedit</command> makes it easy to modify properties that have multiple values:
ja: <command>svn propedit</command> は、複数の値を持つ 属性を簡単に変更することができます:

note: Tag: refpurpose
en: Print the value of a property.
ja: 属性の値を表示します。

note: Tag: para
en: Print the value of a property on files, directories, or revisions. The first form prints the versioned property of an item or items in your working copy, while the second prints unversioned remote property on a repository revision. See <xref linkend="svn.advanced.props"/> for more information on properties.
ja: ファイル、ディレクトリ、リビジョンの属性値を表示します。 最初の形式は作業コピーにある一つ以上のアイテムのバージョン管理された属性を表示します。 二番目の形式ではあるリポジトリリビジョンのバージョン管理していない属性を 表示します。属性についての詳細は <xref linkend="svn.advanced.props"/> を見てください。

note: Tag: para
en: Examine a property of a file in your working copy:
ja: 作業コピー中のアイテムの属性を調べる:

note: Tag: para
en: The same goes for a revision property:
ja: リビジョン属性についても同様:

note: Tag: refpurpose
en: List all properties.
ja: すべての属性を一覧表示します。

note: Tag: para
en: You can use proplist to see the properties on an item in your working copy:
ja: 作業コピーのアイテムの属性の一覧を見たい場合は proplist コマンドを使うことができます:

note: Tag: para
en: But with the <option>--verbose</option> flag, svn proplist is extremely handy as it also shows you the values for the properties:
ja: しかし<option>--verbose</option> フラグを付けると、それぞれの属性の値も 一緒に表示することができるのでとても便利です:

note: Tag: refpurpose
en: Set PROPNAME to PROPVAL on files, directories, or revisions.
ja: ファイル、ディレクトリ、リビジョンの PROPNAME の値 を PROPVALに設定する。

note: Tag: programlisting
en: svn propset PROPNAME [PROPVAL | -F VALFILE] PATH...
ja: svn propset PROPNAME [PROPVAL | -F VALFILE] PATH [PATH [PATH ... ]]

note: Tag: para
en: On a UNIX system, if you want a file to have the executable permission set:
ja: UNIX 上で、あるファイルに実行属性を付けたいときには:

note: Tag: para
en: Perhaps you have an internal policy to set certain properties for the benefit of your coworkers:
ja: 多分、共同作業者の便宜を考えると、ある属性を設定 するには内部的なポリシーがなくてはなりません:

note: Tag: para
en: If you made a mistake in a log message for a particular revision and want to change it, use <option>--revprop</option> and set <literal>svn:log</literal> to the new log message:
ja: 特定のリビジョンのログメッセージを間違ってしまい、それを変更したいとき、 <option>--revprop</option> を使って、<literal>svn:log</literal> に新し いメッセージを設定します:

note: Tag: para
en: Or, if you don't have a working copy, you can provide a URL.
ja: あるいは、作業コピーを持っていない場合でも、URLを設定することが できます。

note: Tag: para
en: Lastly, you can tell propset to take its input from a file. You could even use this to set the contents of a property to something binary:
ja: 最後に、属性値をファイルを入力として設定することもできます。 この方法で、属性値にバイナリ値を設定することさえできます:

note: Tag: para
en: By default, you cannot modify revision properties in a Subversion repository. Your repository administrator must explicitly enable revision property modifications by creating a hook named <literal>pre-revprop-change</literal>. See <xref linkend="svn.reposadmin.create.hooks"/> for more information on hook scripts.
ja: デフォルトではSubversionリポジトリ中のリビジョン属性は変更 できません。リポジトリ管理者は<literal>pre-revprop-change</literal>という 名前のフックを作ることで明示的にリビジョン属性の 修正を有効にしなくてはなりません。 フックスクリプトについて詳しくは <xref linkend="svn.reposadmin.create.hooks"/> を見てください。

note: Tag: refpurpose
en: Remove <quote>conflicted</quote> state on working copy files or directories.
ja: 作業コピーのファイルまたはディレクトリの <quote>衝突</quote> 状態を取り除きます。

note: Tag: para
en: Remove <quote>conflicted</quote> state on working copy files or directories. This routine does not semantically resolve conflict markers; it merely removes conflict-related artifact files and allows <replaceable>PATH</replaceable> to be committed again; that is, it tells Subversion that the conflicts have been <quote>resolved</quote>. See <xref linkend="svn.tour.cycle.resolve"/> for an in-depth look at resolving conflicts.
ja: 作業コピーのファイルまたはディレクトリの <quote>衝突</quote> 状態を取り除きます。 このコマンドは衝突マーカを意味的に解消するのではなく、単に 衝突に関係した中間ファイルを削除して、<replaceable>PATH</replaceable>でもう一度コミットする だけです。つまりSubversionにその衝突は既に<quote>解消された</quote>と伝えます。 衝突の解消についての詳細は <xref linkend="svn.tour.cycle.resolve"/> を見てください。

note: Tag: para
en: If you get a conflict on an update, your working copy will sprout three new files:
ja: 更新操作中に衝突があった場合、作業コピーは三つの新しいファイルを 作ります:

note: Tag: para
en: Once you've resolved the conflict and <filename>foo.c</filename> is ready to be committed, run <command>svn resolved</command> to let your working copy know you've taken care of everything.
ja: 衝突を解消し、<filename>foo.c</filename> のコミットの準備が できた状態にある場合、<command>svn resolved</command> は あなたの作業コピーに、注意しなくてはならないすべてのことを 伝えます。

note: Tag: para
en: You <emphasis>can</emphasis> just remove the conflict files and commit, but <command>svn resolved</command> fixes up some bookkeeping data in the working copy administrative area in addition to removing the conflict files, so we recommend that you use this command.
ja: 単に衝突ファイルを削除してからコミットすることも<emphasis>できます</emphasis> が <command>svn resolved</command> は作業コピー管理領域の記録として、衝突ファイルを削除した ことも付け加えるので、このコマンドを使うのをお勧めします。

note: Tag: refpurpose
en: Undo all local edits.
ja: ローカルファイルへのすべての編集を取り消します。

note: Tag: para
en: Reverts any local changes to a file or directory and resolves any conflicted states. <command>svn revert</command> will not only revert the contents of an item in your working copy, but also any property changes. Finally, you can use it to undo any scheduling operations that you may have done (e.g. files scheduled for addition or deletion can be <quote>unscheduled</quote>).
ja: ファイル、ディレクトリに対する変更をすべて取り消して 衝突の状態を解消します。<command>svn revert</command>は 作業コピーのアイテムの内容だけではなく、属性の変更も取り消します。 さらに既にやった予告操作を取り消すのにも使えます。 (たとえば、ファイルにたいする追加または削除の予告 も<quote>取り消され</quote>ます。

note: Tag: para
en: Discard changes to a file:
ja: ファイルに対する変更の取り消し:

note: Tag: para
en: If you want to revert a whole directory of files, use the <option>--recursive</option> flag:
ja: ディレクトリ全体を取り消したい場合は、 <option>--recursive</option> フラグを使います:

note: Tag: para
en: Lastly, you can undo any scheduling operations:
ja: 最後に、どの予告操作も取り消すことができます:

note: Tag: para
en: If you provide no targets to <command>svn revert</command>, it will do nothing&mdash;to protect you from accidentally losing changes in your working copy, <command>svn revert</command> requires you to provide at least one target.
ja: <command>svn revert</command> の対象を指定しなければ、それは何もしません&mdash; 間違った修正の破棄から作業コピーを守るために、<command>svn revert</command> 操作は 少なくとも一つの引数を指定するように求めます。

note: Tag: refpurpose
en: Print the status of working copy files and directories.
ja: 作業コピーにあるファイルやディレクトリの状態を表示しす。

note: Tag: para
en: The first six columns in the output are each one character wide, and each column gives you information about different aspects of each working copy item.
ja: 出力の最初の6列のコラムはそれぞれ一文字幅で、作業コピーアイテムごとに いろいろな情報を表示します。

note: Tag: para
en: The first column indicates that an item was added, deleted, or otherwise changed.
ja: 最初のコラムは、アイテムが追加、削除、それ以外の変更、のどの状態かを を示します。

note: Tag: para
en: No modifications.
ja: 変更はありません。

note: Tag: para
en: Item is scheduled for Addition.
ja: アイテムは追加予告されています。

note: Tag: para
en: Item is scheduled for Deletion.
ja: アイテムは削除予告されています。

note: Tag: para
en: Item has been modified.
ja: アイテムは修正されました。

note: Tag: para
en: Item has been replaced in your working copy. This means the file was scheduled for deletion, and then a new file with the same name was scheduled for addition in its place.
ja: アイテムは作業コピー中で置き換えられました。

note: Tag: para
en: The contents (as opposed to the properties) of the item conflict with updates received from the repository.
ja: (属性ではなく)アイテムの内容はリポジトリから 受け取った更新によって衝突した状態にあります。

note: Tag: para
en: Item is being ignored (e.g. with the <literal>svn:ignore</literal> property).
ja: アイテムは無視されている属性です (たとえば、 <literal>svn:ignore</literal>のような)

note: Tag: para
en: Item is not under version control.
ja: アイテムはバージョン管理下にありません。

note: Tag: para
en: Item is missing (e.g. you moved or deleted it without using <command>svn</command>). This also indicates that a directory is incomplete (a checkout or update was interrupted).
ja: アイテムは失われました(これはたとえば、 <command>svn</command>を使わずにファイルを削除したり移動した場合に 起こります)。また、これはディレクトリが不完全であることを示しています (チェックアウトや更新が中断された、など)。

note: Tag: term
en: <term>'~'</term>
ja: <term>'‾'</term>

note: Tag: para
en: Item is versioned as one kind of object (file, directory, link), but has been replaced by different kind of object.
ja: アイテムはある種類のオブジェクト (ファイル、ディレクトリ、リンク)としてバージョン管理されていますが、 別の種類のオブジェクトで置き換えられてしまいました。

note: Tag: para
en: The second column tells the status of a file's or directory's properties.
ja: 二番目のコラムはファイルやディレクトリの 属性の状態を示します。

note: Tag: para
en: Properties for this item have been modified.
ja: このアイテムの属性は修正されました。

note: Tag: para
en: Properties for this item are in conflict with property updates received from the repository.
ja: このアイテムの属性はリポジトリから受け取った属性更新によって 衝突した状態にあります。

note: Tag: para
en: Item is not locked.
ja: アイテムはロックされていません。

note: Tag: para
en: Item is locked.
ja: アイテムはロックされています。

note: Tag: para
en: The fourth column is populated only if the item is scheduled for addition-with-history.
ja: 四番目のコラムはアイテムが追加予告されている場合にのみ 使われます。

note: Tag: para
en: No history scheduled with commit.
ja: コミット待ちの予告はありません。

note: Tag: para
en: History scheduled with commit.
ja: コミット待ちの予告があります。

note: Tag: para
en: The fifth column is populated only if the item is switched relative to its parent (see <xref linkend="svn.branchmerge.switchwc"/>).
ja: 五番目のコラムはアイテムが親に対して相対的に切り替えられた ときにだけ使われます。 (<xref linkend="svn.branchmerge.switchwc"/>を見てください)。

note: Tag: para
en: Item is a child of its parent directory.
ja: アイテムは親ディレクトリの子供です。

note: Tag: para
en: Item is switched.
ja: アイテムは切り替わっています。

note: Tag: para
en: The sixth column is populated with lock information.
ja: 六番目のコラムにはロック情報が表示されます。

note: Tag: para
en: When <option>--show-updates</option> is used, the file is not locked. If <option>--show-updates</option> is <emphasis>not</emphasis> used, this merely means that the file is not locked in this working copy.
ja: <option>--show-updates</option>が指定された場合ファイルはロックされて いません。<option>--show-updates</option>が指定 <emphasis>されない</emphasis> 場合、これは単にこの作業コピー中でファイルがロックされていないことを示すだけです。

note: Tag: para
en: File is locked in this working copy.
ja: ファイルはこの作業コピー中でロックされています。

note: Tag: para
en: File is locked either by another user or in another working copy. This only appears when <option>--show-updates</option> is used.
ja: ファイルは他のユーザあるいは他の作業コピーによってロックされています。 これは<option>--show-updates</option>が指定された場合にだけ現れます。

note: Tag: para
en: The item in your working copy is up-to-date.
ja: 作業コピーのアイテムは最新です。

note: Tag: para
en: A newer revision of the item exists on the server.
ja: サーバにはアイテムのもっと新しいバージョンが 存在します。

note: Tag: para
en: The working copy path is always the final field, so it can include spaces.
ja: 作業コピーのパスは常に最後のフィールドになるので、空白を含むことが できます。

note: Tag: para
en: Only if using <option>--show-updates</option>
ja: <option>--show-updates</option>が指定された場合に のみ発生する

note: Tag: para
en: This is the easiest way to find out what changes you have made to your working copy:
ja: 作業コピーにした変更点を調べるための一番簡単な方法:

note: Tag: para
en: And finally, the most information you can get out of the status subcommand:
ja: 最後に、statusサブコマンドで一番たくさんの情報を得るには:

note: Tag: para
en: For many more examples of <command>svn status</command>, see <xref linkend="svn.tour.cycle.examine.status"/>.
ja: <command>svn status</command> のもっとたくさんの例は <xref linkend="svn.tour.cycle.examine.status"/>にあります。

note: Tag: refpurpose
en: Update working copy to a different URL.
ja: 作業コピーを別のURLに更新します。

note: Tag: para
en: And to switch back, just provide the URL to the location in the repository from which you originally checked out your working copy:
ja: そして、元に戻りたいときには、最初に作業コピーをチェックアウトした リポジトリの場所をURLとして指定するだけです:

note: Tag: para
en: You can just switch part of your working copy to a branch if you don't want to switch your entire working copy.
ja: 作業コピー全体を切り替えたくない場合、その一部だけをブランチに 切り替えることもできます。

note: Tag: para
en: Be careful when using the <option>--relocate</option> option. If you mistype the argument, you might end up creating nonsensical URLs within your working copy that render the whole workspace unusable and tricky to fix. It's also important to understand exactly when one should or shouldn't use <option>--relocate</option>. Here's the rule of thumb:
ja: <option>--relocate</option>オプションの利用には注意してください。 引数を間違って入力すると作業コピー中に意味のない URL 情報ができて しまい、作業コピー全体が利用不能になり、修復にはちょっとしたコツが 必要になってしまいます。また <option>--relocate</option> を 利用すべきか、すべきでないかをはっきりと完全に理解していることも 重要です。以下が原則です:

note: Tag: para
en: If the working copy needs to reflect a new directory <emphasis>within</emphasis> the repository, then use just <command>svn switch</command>.
ja: 作業コピーがリポジトリの <emphasis>中にある</emphasis>新しいディレクトリ に移る場合には、単に<command>svn switch</command>を使う。

note: Tag: para
en: If the working copy still reflects the same repository directory, but the location of the repository itself has changed, then use <command>svn switch --relocate</command>.
ja: 作業コピーは同じリポジトリのディレクトリを指しているが、リポジトリ自身の 場所が移った場合には <command>svn switch --relocate</command>を使う。

note: Tag: refpurpose
en: Unlock working copy paths or URLs.
ja: 作業コピーパスまたは URL をアンロックします

note: Tag: para
en: Unlock each <replaceable>TARGET</replaceable>. If any <replaceable>TARGET</replaceable> is either locked by another user or no valid lock token exists in the working copy, print a warning and continue unlocking the rest of the <replaceable>TARGET</replaceable>s. Use <option>--force</option> to break a lock belonging to another user or working copy.
ja: <replaceable>TARGET</replaceable>それぞれをアンロックします。 <replaceable>TARGET</replaceable>のどれかが他のユーザによってロックされて いたり作業コピー中に正常なロックトークンが存在しない場合は警告を出して 残りの <replaceable>TARGET</replaceable>のアンロックを続けます。 他のユーザまたは作業コピーに属するロックを破壊するには <option>--force</option> を使ってください。

note: Tag: para
en: Unlock two files in your working copy:
ja: 作業コピー中の二つのファイルをアンロックする:

note: Tag: para
en: Unlock a file in your working copy that is currently locked by another user:
ja: 現在別のユーザによってロックされている作業コピー中のファイル をアンロックする:

note: Tag: para
en: Unlock a file without a working copy:
ja: 作業コピーには無関係にファイルをアンロックする:

note: Tag: refpurpose
en: Update your working copy.
ja: 作業コピーの更新。

note: Tag: para
en: Added
ja: 追加

note: Tag: para
en: Deleted
ja: 削除

note: Tag: para
en: Updated
ja: 更新

note: Tag: para
en: Merged
ja: マージ

note: Tag: para
en: A character in the first column signifies an update to the actual file, while updates to the file's properties are shown in the second column.
ja: 最初のコラムの文字は実際のファイルの更新を示しますが、 ファイルの属性の更新状況は二番目のコラムで示します。

note: Tag: para
en: Pick up repository changes that have happened since your last update:
ja: 最後の更新後に起きたリポジトリの修正を取り込みます:

note: Tag: para
en: <command>svnadmin</command> is the administrative tool for monitoring and repairing your Subversion repository. For detailed information, see <xref linkend="svn.reposadmin.maint.tk.svnadmin"/>.
ja: <command>svnadmin</command> は Subversionリポジトリを監視したり修復したりするための管理ツールです。 詳しくは<xref linkend="svn.reposadmin.maint.tk.svnadmin"/>を見てください。

note: Tag: para
en: Since <command>svnadmin</command> works via direct repository access (and thus can only be used on the machine that holds the repository), it refers to the repository with a path, not a URL.
ja: <command>svnadmin</command>は直接リポジトリに対するアクセスに より動作するので(そして、リポジトリが存在するマシン上でのみ利用することが できるので)、URLではなく、パス名によってリポジトリを参照します。

note: Tag: para
en: Bypass the repository hook system.
ja: リポジトリフックシステムを迂回します。

note: Tag: para
en: Removes unused Berkeley DB logs.
ja: 利用していないBerkeley DB ログを削除します。

note: Tag: para
en: Dump a revision only as a diff against the previous revision, instead of the usual fulltext.
ja: リビジョンの全体をダンプするのではなく、以前のリビジョンに対する差分として ダンプします。

note: Tag: para
en: When loading a dump file, root paths at <replaceable>DIR</replaceable> instead of <filename>/</filename>.
ja: ダンプファイルをロードするときルートパスとして<filename>/</filename> のかわりに<replaceable>DIR</replaceable>を使います。

note: Tag: para
en: Specify a particular revision to operate on.
ja: 操作対象となる特定のリビジョンを指定します。

note: Tag: para
en: Do not show normal progress&mdash;show only errors.
ja: 通常の進行状況を表示しません&mdash;エラーのみ表示します。

note: Tag: para
en: When loading a dump file, run the repository's post-commit hook after finalizing each newly loaded revision.
ja: ダンプファイルをロードする時、新規にロードされたそれぞれのリビジョンの完了 処理の後でリポジトリのpost-commitフックを実行します。

note: Tag: para
en: When loading a dump file, run the repository's pre-commit hook before finalizing each newly loaded revision. If the hook fails, abort the commit and terminate the load process.
ja: ダンプファイルをロードする時、新規にロードされたそれぞれのリビジョンの完了 処理の前にリポジトリのpre-commitフックを実行します。フック処理に失敗した 場合、コミットは中断されてロード処理は終了します。

note: Tag: title
en: <command>svnadmin</command> Subcommands
ja: <command>svnadmin</command> サブコマンド

note: Tag: refpurpose
en: Create a new, empty repository.
ja: 新規の空のリポジトリを作ります。

note: Tag: para
en: Create a new, empty repository at the path provided. If the provided directory does not exist, it will be created for you.<footnote><para>Remember, <command>svnadmin</command> works only with local <emphasis>paths</emphasis>, not <emphasis>URLs</emphasis>.</para></footnote> As of Subversion 1.2, <command>svnadmin</command> creates new repositories with the <literal>fsfs</literal> filesystem backend by default.
ja: 指定したパスに新規に空のリポジトリを作ります。 パスが存在しなければ自動的に作られます。 <footnote><para> <command>svnadmin</command> はローカル <emphasis>パス</emphasis>に対してのみ 動作し、<emphasis>URL</emphasis>には働かないことに注意 してください。</para></footnote> Subversion 1.2 では <command>svnadmin</command>はデフォルトで <literal>fsfs</literal>ファイルシステムのバックグラウンドで 新しいリポジトリを作成します。

note: Tag: para
en: Creating a new repository is just this easy:
ja: 新しくリポジトリを作るには単に以下のようにします:

note: Tag: para
en: In Subversion 1.0, a Berkeley DB repository is always created. In Subversion 1.1, a Berkeley DB repository is the default repository type, but an FSFS repository can be created using the <option>--fs-type</option> option:
ja: Subversion 1.0 では Berkeley DB リポジトリが常に作られます。 Subversion 1.1 では Berkeley DB リポジトリがデフォルトですが <option>--fs-type</option>オプションで FSFS リポジトリを作る こともできます:

note: Tag: refpurpose
en: Deltify changed paths in a revision range.
ja: あるリビジョン範囲にある変更パスを差分化します

note: Tag: para
en: It dates from a time when Subversion offered administrators greater control over compression strategies in the repository. This turned out to be a lot of complexity for <emphasis>very</emphasis> little gain, and this <quote>feature</quote> was deprecated.
ja: これは Subversion がリポジトリ中の圧縮方法についてシス テム管理者に対してより大きな制御権限を与えるためのものでした。しかし <emphasis>非常に</emphasis>わずかな利益のために多くの複雑さを導入する ことになることがわかったため、この<quote>機能</quote>は廃止されました。

note: Tag: refpurpose
en: Dump the contents of filesystem to stdout.
ja: ファイルシステムの内容を標準出力にダンプします。

note: Tag: para
en: Dump the contents of filesystem to stdout in a <quote>dumpfile</quote> portable format, sending feedback to stderr. Dump revisions <replaceable>LOWER</replaceable> rev through <replaceable>UPPER</replaceable> rev. If no revisions are given, dump all revision trees. If only <replaceable>LOWER</replaceable> is given, dump that one revision tree. See <xref linkend="svn.reposadmin.maint.migrate"/> for a practical use.
ja: ファイルシステムの内容を<quote>dumpfile</quote>可搬可能形式でダンプし、進行状況 を標準出力に表示します。 リビジョン <replaceable>LOWER</replaceable> から、 <replaceable>UPPER</replaceable>までをダンプします。リビジョンが指定 されなければすべてのリビジョンツリーをダンプします。 <replaceable>LOWER</replaceable>だけが 指定された場合は一つのリビジョンツリーのみダンプします。 実際の使い方については<xref linkend="svn.reposadmin.maint.migrate"/> を見てください。

note: Tag: para
en: By default, the Subversion dumpfile stream contains a single revision (the first revision in the requested revision range) in which every file and directory in the repository in that revision is presented as if that whole tree was added at once, followed by other revisions (the remainder of the revisions in the requested range) which contain only the files and directories which were modified in those revisions. For a modified file, the complete fulltext representation of its contents, as well as all of its properties, are presented in the dumpfile; for a directory, all of its properties are presented.
ja: デフォルトでは、Subversion ダンプファイルの内容は 以下のようになります。まず要求されたリビジョン範囲の最初のリビジョン の内容が出力されます。ここにはそのリビジョンに含まれるすべてのファイルと ディレクトリが、すべて一度にリポジトリに追加されたかのような形式に なります。その後に、(要求されたリビジョン範囲内の)引き続くすべての リビジョンの内容が続きます。ここにはそれぞれのリビジョンで修正された ファイルとディレクトリの情報だけが含まれます。修正されたものがファイルの 場合には、そのファイルの完全な内容と、属性が出力されます。 ディレクトリの場合には、そのすべての属性が出力されます。

note: Tag: para
en: Dump your whole repository:
ja: リポジトリ全体のダンプ:

note: Tag: para
en: Incrementally dump a single transaction from your repository:
ja: リポジトリの一つのトランザクションの 差分ダンプ:

note: Tag: para
en: This subcommand is useful when you're trapped on a desert island with neither a net connection nor a copy of this book.
ja: このサブコマンドはネットワーク接続がうまくいかなくなって この本のコピーが読めなくなったりしてどこかに迷い込んでしまった ようなときに役立ちます。

note: Tag: refpurpose
en: Make a hot copy of a repository.
ja: リポジトリのホットコピーを作ります。

note: Tag: refpurpose
en: Ask Berkeley DB which log files exist for a given Subversion repository (applies only to repositories using the <literal>bdb</literal> backend).
ja: 指定した Subversion リポジトリにどのような Berkeley DB ログファイルが あるか問い合わせます。(<literal>bdb</literal>バックエンドを利用しているリポジトリの場合だけです)。

note: Tag: para
en: Berkeley DB creates logs of all changes to the repository, which allow it to recover in the face of catastrophe. Unless you enable <literal>DB_LOG_AUTOREMOVE</literal>, the log files accumulate, although most are no longer used and can be deleted to reclaim disk space. See <xref linkend="svn.reposadmin.maint.diskspace"/> for more information.
ja: Berkeley DB は障害から復旧できるようにリポジトリの すべての変更点のログをとります。 <literal>DB_LOG_AUTOREMOVE</literal> を有効にしない限りログファイルは蓄積されていきますが、そのほとんどは それ以上利用されることはなく、ディスク領域を確保するために削除可能な ものです。詳細は<xref linkend="svn.reposadmin.maint.diskspace"/>を見てください。

note: Tag: refpurpose
en: Ask Berkeley DB which log files can be safely deleted (applies only to repositories using the <literal>bdb</literal> backend).
ja: Berkeley DB にどのログファイルが安全に削除可能かを問い合わせます。 (<literal>bdb</literal>バックエンドを使っているリポジトリの場合だけです)。

note: Tag: para
en: Remove all unused log files from a repository:
ja: リポジトリからすべての未使用ログを削除するには:

note: Tag: refpurpose
en: Read a <quote>dumpfile</quote>-formatted stream from stdin.
ja: 標準入力から<quote>ダンプファイル</quote>形式 のデータを読み出します。

note: Tag: para
en: Read a <quote>dumpfile</quote>-formatted stream from stdin, committing new revisions into the repository's filesystem. Send progress feedback to stdout.
ja: 標準入力から<quote>ダンプ形式</quote> のデータを読み出し、リポジトリのファイルシステムに新しい リビジョンをコミットします。進行状況は標準出力に表示されます。

note: Tag: title
en: Example
ja: 例

note: Tag: para
en: This shows the beginning of loading a repository from a backup file (made, of course, with <command>svnadmin dump</command>):
ja: これはバックアップファイルからリポジトリをロードする最初の 部分です(もちろんあらかじめ<command>svnadmin dump</command>でダンプして おいたものです):

note: Tag: para
en: Or if you want to load into a subdirectory:
ja: あるいはサブディレクトリにロードしたい場合は:

note: Tag: refpurpose
en: Print descriptions of all locks.
ja: すべてのロック状況を表示します。

note: Tag: para
en: Print descriptions of all locks in a repository.
ja: リポジトリ中のすべてのロックに関する情報を表示します。

note: Tag: refpurpose
en: Print the names of all uncommitted transactions.
ja: コミットされていないすべてのトランザクションの名前の表示。

note: Tag: para
en: List all outstanding transactions in a repository.
ja: リポジトリ中の未解決のトランザクション一覧の表示。

note: Tag: refpurpose
en: Bring a repository database back into a consistent state (applies only to repositories using the <literal>bdb</literal> backend). In addition, if <filename>repos/conf/passwd</filename> does not exist, it will create a default password file .
ja: リポジトリデータベースの一貫した状態への復帰。 (<literal>bdb</literal>バックエンドを使っているリポジトリの場合だけです)。 さらに<filename>repos/conf/passwd</filename>が存在しなければデフォルトの パスワードファイルも作ります。

note: Tag: para
en: Run this command if you get an error indicating that your repository needs to be recovered.
ja: リポジトリは修復される必要があるというエラーメッセージを受け取った ときにはこのコマンドを実行してください。

note: Tag: para
en: Recover a hung repository:
ja: ハングしてしまったリポジトリの修復:

note: Tag: para
en: Recovering the database requires an exclusive lock on the repository. (This is a <quote>database lock</quote>; see <xref linkend="svn.advanced.locking.meanings"/>.) If another process is accessing the repository, then <command>svnadmin recover</command> will error:
ja: データベースの修復にはリポジトリを排他的にロックする必要があります。他 のプロセスがリポジトリにアクセスしている場合、<command>svnadmin recover</command>はエラーになります:

note: Tag: para
en: The <option>--wait</option> option, however, will cause <command>svnadmin recover</command> to wait indefinitely for other processes to disconnect:
ja: しかし <option>--wait</option>オプションを指定すると <command>svnadmin recover</command>は他のプロセスの接続が切れるまで待ちつづけます:

note: Tag: refpurpose
en: Unconditionally remove one or more locks from a repository.
ja: リポジトリにある一つ以上のロックを無条件に取り除きます。

note: Tag: para
en: Remove lock from each <replaceable>LOCKED_PATH</replaceable>.
ja: <replaceable>LOCKED_PATH</replaceable>ごとにロックを取り除きます。

note: Tag: para
en: This deletes the locks on <filename>tree.jpg</filename> and <filename>house.jpg</filename> in the repository at <filename>/svn/repos</filename>
ja: リポジトリ<filename>/svn/repos</filename>にある <filename>tree.jpg</filename>と<filename>house.jpg</filename>に 設定されているロックを削除しています。

note: Tag: refpurpose
en: Delete transactions from a repository.
ja: リポジトリからトランザクションを削除します。

note: Tag: para
en: Remove named transactions:
ja: 名前の付いたトランザクションの削除:

note: Tag: para
en: Fortunately, the output of <command>lstxns</command> works great as the input for <command>rmtxns</command>:
ja: 幸運なことに、<command>lstxns</command> の出力は <command>rmtxns</command>の入力と同じくらいうまく動きます:

note: Tag: para
en: Which will remove all uncommitted transactions from your repository.
ja: これはリポジトリからすべてのコミットされていないトランザクション を削除します。

note: Tag: refpurpose
en: Set the log-message on a revision.
ja: リビジョンにログメッセージを設定します。

note: Tag: para
en: Set the log-message on revision REVISION to the contents of FILE.
ja: FILEの内容をリビジョン REVISIONのログメッセージとして設定します。

note: Tag: para
en: This is similar to using <command>svn propset --revprop</command> to set the <literal>svn:log</literal> property on a revision, except that you can also use the option <option>--bypass-hooks</option> to avoid running any pre- or post-commit hooks, which is useful if the modification of revision properties has not been enabled in the pre-revprop-change hook.
ja: これは、<command>svn propset --revprop</command>を使ってリビジョン上に <literal>svn:log</literal>属性を設定するのと似ていますが、 <option>--bypass-hooks</option>を使ってコミット前後のフックの実行を避ける ことができます。これは pre-revprop-change フック中でリビジョン属性の修正 が有効ではない場合に便利です。

note: Tag: para
en: Revision properties are not under version control, so this command will permanently overwrite the previous log message.
ja: リビジョン属性はバージョン管理下にはないのでこのコマンドは以前の ログメッセージを完全に上書きしてしまいます。

note: Tag: para
en: Set the log message for revision 19 to the contents of the file <filename>msg</filename>:
ja: ファイル<filename>msg</filename>の内容をリビジョン19のログメッセージに設定します:

note: Tag: refpurpose
en: Verify the data stored in the repository.
ja: リポジトリに保管されているデータを検証します。

note: Tag: para
en: Verify a hung repository:
ja: 固まってしまったリポジトリの検証:

note: Tag: para
en: <command>svnlook</command> is a command-line utility for examining different aspects of a Subversion repository. It does not make any changes to the repository&mdash;it's just used for <quote>peeking</quote>. <command>svnlook</command> is typically used by the repository hooks, but a repository administrator might find it useful for diagnostic purposes.
ja: <command>svnlook</command> はSubversionリポジトリの 別の部分を調べるためのコマンドラインツールです。このコマンドは リポジトリには何の変更も加えません&mdash;単に<quote>調べる</quote>ため に利用されます。<command>svnlook</command>はリポジトリフックで利用されるのが 典型的ですが、リポジトリ管理者は診断の目的にも利用できることに気づくかも 知れません。

note: Tag: para
en: Since <command>svnlook</command> works via direct repository access (and thus can only be used on the machine that holds the repository), it refers to the repository with a path, not a URL.
ja: <command>svnlook</command> は直接リポジトリにアクセスする形で実行される ので(そして、それが理由でリポジトリの存在するマシン上でのみ利用することが できるのですが)、URLではなく、パス名称によってリポジトリを参照します。

note: Tag: para
en: If no revision or transaction is specified, <command>svnlook</command> defaults to the youngest (most recent) revision of the repository.
ja: リビジョンやトランザクションが指定されなければ、 <command>svnlook</command> はリポジトリの最新リビジョンを使います。

note: Tag: title
en: <command>svnlook</command> Options
ja: <command>svnlook</command>オプション

note: Tag: para
en: Options in <command>svnlook</command> are global, just like in <command>svn</command> and <command>svnadmin</command>; however, most options only apply to one subcommand since the functionality of <command>svnlook</command> is (intentionally) limited in scope.
ja: <command>svnlook</command> 中のスイッチは <command>svn</command> や<command>svnadmin</command>などと一緒で グローバルに働きますが、ほとんどのスイッチは一つのサブコマンドに しか効果がありません。それは<command>svnlook</command>の機能の 有効範囲が(意図的に)限られているからです。

note: Tag: para
en: Prevents <command>svnlook</command> from printing differences for deleted files. The default behavior when a file is deleted in a transaction/revision is to print the same differences that you would see if you had left the file but removed all the content.
ja: <command>svnlook</command>が削除されたファイルの差異を表示しないようにします。 トランザクション/リビジョン中でファイルが削除されたときのデフォルト 動作は、そのファイルが空のファイルとして残っているときと同じに なります。

note: Tag: para
en: Specify a particular revision number that you wish to examine.
ja: 調べたい特定のリビジョン番号を指定します。

note: Tag: para
en: Specify a particular transaction ID that you wish to examine.
ja: 調べたい特定のトランザクション番号を指定します。

note: Tag: para
en: Show the filesystem node revision IDs for each path in the filesystem tree.
ja: ファイルシステムツリー中の、それぞれのパスごとのファイルシステム ノードリビジョン番号を表示します。

note: Tag: title
en: <command>svnlook</command> Subcommands
ja: <command>svnlook</command> サブコマンド

note: Tag: refpurpose
en: Print the author.
ja: 変更者の表示。

note: Tag: para
en: Print the author of a revision or transaction in the repository.
ja: リポジトリのリビジョンやトランザクションを実行した 人を表示します。

note: Tag: para
en: <command>svnlook author</command> is handy, but not very exciting:
ja: <command>svnlook author</command>は便利ですが、 それほど面白いコマンドではありません:

note: Tag: refpurpose
en: <refpurpose>Print the contents of a file.</refpurpose>
ja: <refpurpose>ファイルの内容を表示します</refpurpose>

note: Tag: para
en: <para>Print the contents of a file.</para>
ja: <para>ファイルの内容を表示します。</para>

note: Tag: para
en: This shows the contents of a file in transaction <literal>ax8</literal>, located at <filename>/trunk/README</filename>:
ja: 以下は<filename>/trunk/README</filename> にあるトランザクション <literal>ax8</literal>中のファイルの内容を表示しています:

note: Tag: refpurpose
en: Print the paths that were changed.
ja: 変更されたパスを表示します。

note: Tag: para
en: Print the paths that were changed in a particular revision or transaction, as well as <quote>svn update-style</quote> status letters in the first two columns:
ja: <quote>svn update-style</quote> の第一ステータス文字と同じように 特定のリビジョンやトランザクションで変更されたパスを表示します:

note: Tag: para
en: Item added to repository.
ja: アイテムはリポジトリに追加されました

note: Tag: para
en: Item deleted from repository.
ja: アイテムはリポジトリから削除されました

note: Tag: para
en: File contents changed.
ja: ファイル内容が変化しました

note: Tag: para
en: File contents and properties changed.
ja: ファイルの内容と属性が変化しました

note: Tag: para
en: Files and directories can be distinguished, as directory paths are displayed with a trailing '<literal>/</literal>' character.
ja: ディレクトリパスの最後には '<literal>/</literal>' がつくのでファイルと ディレクトリは区別することができます。

note: Tag: refpurpose
en: Print the datestamp.
ja: 日付を表示します。

note: Tag: para
en: Print the datestamp of a revision or transaction in a repository.
ja: リポジトリ中の特定リビジョンやトランザクションの日付を表示します。

note: Tag: para
en: This shows the date of revision 40 of a test repository:
ja: これは、テストリポジトリのリビジョン40の日付を表示します:

note: Tag: refpurpose
en: Print differences of changed files and properties.
ja: 変更されたファイル、ディレクトリの差分を表示します。

note: Tag: para
en: Print GNU-style differences of changed files and properties in a repository.
ja: リポジトリ中で変更されたファイル、属性の差分をGNU形式で表示します。

note: Tag: para
en: This shows a newly added (empty) file, a deleted file, and a copied file:
ja: これは、新しく追加されたファイル(空のファイル)、削除されたファイル、コピーされた ファイルを表示します:

note: Tag: para
en: If a file has a non-textual <literal>svn:mime-type</literal> property, then the differences are not explicitly shown.
ja: ファイルが非テキスト的な <literal>svn:mime-type</literal>属性を持っている場合、差分は明示的には表 示されません。

note: Tag: refpurpose
en: Print the directories that were themselves changed.
ja: 変更のあったディレクトリを表示します。

note: Tag: para
en: Print the directories that were themselves changed (property edits) or whose file children were changed.
ja: (属性を編集によって)それ自身に変更があったか、 その子供のファイルに変更があったディレクトリを表示します。

note: Tag: para
en: This shows the directories that changed in revision 40 in our sample repository:
ja: 私たちのサンプルリポジトリ中のリビジョン40で修正された ディレクトリを表示します:

note: Tag: para
en: Displays the help message for svnlook. This command, like its brother <command>svn help</command>, is also your friend, even though you never call it anymore and forgot to invite it to your last party.
ja: svnlook のヘルプを表示します。 <command>svn help</command>のヘルプと同じで、何かがわからなくなったときには常に 役に立ちます。

note: Tag: refpurpose
en: <refpurpose>Print information about the history of a path in the repository (or the root directory if no path is supplied).</refpurpose>
ja: <refpurpose>リポジトリ中のパスの履歴に関する情報を表示します (あるいはパスが指定されなかった場合にはルートディレクトリになります)。</refpurpose>

note: Tag: para
en: <para>Print information about the history of a path in the repository (or the root directory if no path is supplied).</para>
ja: <para>リポジトリ中のパスの履歴に関する情報を表示します (あるいはパスが指定されなかった場合にはルートディレクトリになります)。</para>

note: Tag: para
en: This shows the history output for the path <filename>/tags/1.0</filename> as of revision 20 in our sample repository.
ja: 以下は例として作ったリポジトリのリビジョン20 で見た パス<filename>/tags/1.0</filename>の履歴表示です。

note: Tag: refpurpose
en: <refpurpose>Print the author, datestamp, log message size, and log message.</refpurpose>
ja: <refpurpose>作業者、日付、ログメッセージの大きさ、ログメッセージを表示します。</refpurpose>

note: Tag: para
en: <para>Print the author, datestamp, log message size, and log message.</para>
ja: <para>作業者、日付、ログメッセージの大きさ、ログメッセージを表示します。</para>

note: Tag: para
en: This shows the info output for revision 40 in our sample repository.
ja: これはサンプルリポジトリのリビジョン40に対する info の出力です。

note: Tag: refpurpose
en: If a lock exists on a path in the repository, describe it.
ja: リポジトリ中の特定のパスがロックされている場合、それについての 情報を表示します。

note: Tag: para
en: Print all information available for the lock at <replaceable>PATH_IN_REPOS</replaceable>. If <replaceable>PATH_IN_REPOS</replaceable> is not locked, print nothing.
ja: <replaceable>PATH_IN_REPOS</replaceable>上のロックについて取得できるすべての 情報を表示します。 <replaceable>PATH_IN_REPOS</replaceable>がロックされて いなければ何も表示しません。

note: Tag: para
en: This describes the lock on the file <filename>tree.jpg</filename>.
ja: <filename>tree.jpg</filename>ファイル上のロックに関する 情報を表示しています。

note: Tag: refpurpose
en: <refpurpose>Print the log message.</refpurpose>
ja: <refpurpose>ログメッセージを表示します。</refpurpose>

note: Tag: para
en: <para>Print the log message.</para>
ja: <para>ログメッセージを表示します。</para>

note: Tag: para
en: This shows the log output for revision 40 in our sample repository:
ja: これはサンプルリポジトリのリビジョン40のログ表示です:

note: Tag: refpurpose
en: Print the raw value of a property on a path in the repository.
ja: リポジトリ中のパス上に設定された属性値の生の値を表示します。

note: Tag: para
en: List the value of a property on a path in the repository.
ja: リポジトリ中のパス上に設定された属性値を一覧表示します。

note: Tag: para
en: This shows the value of the <quote>seasonings</quote> property on the file <filename>/trunk/sandwich</filename> in the <literal>HEAD</literal> revision:
ja: 以下では <literal>HEAD</literal> リビジョンにある <filename>/trunk/sandwich</filename> ファイルの<quote>seasonings</quote>属性値を表示しています:

note: Tag: refpurpose
en: Print the names and values of versioned file and directory properties.
ja: バージョン化されたファイルとディレクトリの属性の 名前と値を表示します。

note: Tag: para
en: List the properties of a path in the repository. With <option>--verbose</option>, show the property values too.
ja: リポジトリ中のパスの属性を一覧表示します。<option>--verbose</option> を使って属性値も表示できます。

note: Tag: para
en: This shows the names of properties set on the file <filename>/trunk/README</filename> in the <literal>HEAD</literal> revision:
ja: これは <literal>HEAD</literal>リビジョンにあるファイル<filename>/trunk/README</filename> に設定された属性名を表示しています:

note: Tag: para
en: This is the same command as in the previous example, but this time showing the property values as well:
ja: これは前の例と同じコマンドですが、今回は属性値もいっしょに表示 しています:

note: Tag: refpurpose
en: Print the tree.
ja: ツリーを表示します。

note: Tag: para
en: Print the tree, starting at <replaceable>PATH_IN_REPOS</replaceable> (if supplied, at the root of the tree otherwise), optionally showing node revision IDs.
ja: <replaceable>PATH_IN_REPOS</replaceable> から始まるツリーを表示します。( <replaceable>PATH_IN_REPOS</replaceable> の指定がない場合にはルートから始まるツリーを表示します。)。オプションで ノードリビジョンIDを表示させることもできます。

note: Tag: para
en: This shows the tree output (with node-IDs) for revision 40 in our sample repository:
ja: これは、(ノード番号付きで)サンプルリポジトリのリビジョン40のツリーを 表示したものです:

note: Tag: refpurpose
en: Print the repository's <literal>UUID</literal>.
ja: リポジトリの<literal>UUID</literal>を表示します。

note: Tag: para
en: Print the <literal>UUID</literal> for the repository. the UUID is the repository's <emphasis>u</emphasis>niversal <emphasis>u</emphasis>nique <emphasis>id</emphasis>entifier. The Subversion client uses this identifier to differentiate between one repository and another.
ja: リポジトリの<literal>UUID</literal>を表示します。UUID はリポジトリ の<emphasis>u</emphasis>niversal <emphasis>u</emphasis>nique <emphasis>id</emphasis>entifier(訳者:生成するたびに 常に一意であることが保証されるような性質をもった番号のことです。 この一意性は特定のマシン内に限定されているわけではなく、異なるマシン 間でも一意になるような性質があります)のことです。 Subversion クライアントはあるリポジトリと別のリポジトリを区別する のにこの識別子を使います。

note: Tag: refpurpose
en: Print the youngest revision number.
ja: 最新のリビジョン番号を表示します。

note: Tag: para
en: Print the youngest revision number of a repository.
ja: リポジトリにある最新のリビジョン番号を表示します。

note: Tag: para
en: This shows the youngest revision of our sample repository:
ja: これは、サンプルリポジトリの最新のリビジョン番号を表示しています:

note: Tag: title
en: <command>svnsync</command> Options
ja: <command>svnsync</command> のスイッチ

note: Tag: title
en: <command>svnsync</command> Subcommands
ja: <command>svnsync</command> サブコマンド

note: Tag: para
en: Causes <command>svnserve</command> to run in daemon mode. <command>svnserve</command> backgrounds itself and accepts and serves TCP/IP connections on the svn port (3690, by default).
ja: <command>svnserve</command>がデーモンモードで実行 するようにします。<command>svnserve</command>自身がバックグラウンドで 実行され、svn ポート(通常は 3690)上に TCP/IP 接続を受け付け、接続を 用意します。

note: Tag: para
en: Causes <command>svnserve</command> to listen on the interface specified by <replaceable>HOST</replaceable>, which may be either a hostname or an IP address.
ja: <command>svnserve</command>が <replaceable>HOST</replaceable>で指定されるインターフェー ス上で待ち受けるように指定します。ホスト名か IP アドレスの いずれかで指定できます。

note: Tag: para
en: Causes <command>svnserve</command> to use the stdin/stdout file descriptors, as is appropriate for a daemon running out of <command>inetd</command>.
ja: <command>svnserve</command>が標準入力/標準出力のファ イル記述子を利用するように指定します。<command>inetd</command>と共に 利用する場合に適しています。

note: Tag: para
en: Displays a usage summary and exits.
ja: 利用方法の概略を表示し抜けます。

note: Tag: para
en: Displays version information, a list of repository back-end modules available, and exits.
ja: バージョン情報と、利用可能なリポジトリバックエンドモジュール一覧を 表示してから終了します。

note: Tag: para
en: Sets the virtual root for repositories served by <command>svnserve</command>. The pathname in URLs provided by the client will be interpreted relative to this root, and will not be allowed to escape this root.
ja: <command>svnserve</command>によって提供されるリポジ トリの仮想的なルートを設定します。クライアントによって指定される URL 中のパス名はこのルートに相対的なものと解釈され、その外にアクセスするこ とを許しません。

note: Tag: para
en: Causes <command>svnserve</command> to accept one connection on the svn port, serve it, and exit. This option is mainly useful for debugging.
ja: <command>svnserve</command>が svn ポート上の接続を ひとつだけ受け入れ、サービスを提供後抜けるようにします。この オプションは主にデバッグ時に利用されます。

note: Tag: refpurpose
en: Summarize the local revision(s) of a working copy.
ja: 作業コピーのローカルリビジョンについて簡単に表示します。

note: Tag: para
en: <command>svnversion</command> is a program for summarizing the revision mixture of a working copy. The resultant revision number, or revision range, is written to standard output.
ja: <command>svnversion</command> は作業コピーの混合リビジョン状況を表示します。 リビジョン番号またはリビジョン範囲が標準出力に出力されます。

note: Tag: para
en: <replaceable>TRAIL_URL</replaceable>, if present, is the trailing portion of the URL used to determine if <replaceable>WC_PATH</replaceable> itself is switched (detection of switches within <replaceable>WC_PATH</replaceable> does not rely on <replaceable>TRAIL_URL</replaceable>).
ja: <replaceable>TRAIL_URL</replaceable> を指定した場合は、 <replaceable>WC_PATH</replaceable> 自身がスイッチされた場合の URL の終わりの部分として利用されます。(<replaceable>WC_PATH</replaceable> 内部でのスイッチの検出は <replaceable>TRAIL_URL</replaceable> にはよりません)。

note: Tag: para
en: Omit the usual trailing newline from the output.
ja: 通常は出力する末尾の改行文字を省略します。

note: Tag: para
en: Use the last-changed revisions rather than the current (i.e., highest locally available) revisions.
ja: 現在の(つまりローカルで一番新しい)リビジョンのかわりに 最終的な更新があったリビジョンを使います。

note: Tag: para
en: Print a help summary.
ja: 簡単なヘルプを表示します。

note: Tag: para
en: Print the version of <command>svnversion</command> and exit with no error.
ja: <command>svnversion</command>のバージョンを表示してから プログラムを正常終了します。

note: Tag: para
en: If the working copy is all at the same revision (for example, immediately after an update), then that revision is printed out:
ja: 作業コピーが完全に単一リビジョン状態にある場合(たとえば update コマンドの 直後など)、リビジョンは以下のように表示されます:

note: Tag: para
en: For a mixed-revision working copy, the range of revisions present is printed:
ja: 混合リビジョンの作業コピーの場合には、リビジョン範囲が 表示されます:

note: Tag: para
en: If the working copy contains modifications, a trailing "M" is added:
ja: 作業コピーに修正がある場合には "M" を追加して表示します:

note: Tag: para
en: If the working copy is switched, a trailing "S" is added:
ja: 作業コピーがスイッチされた場合には "S" を追加して表示します:

note: Tag: para
en: Thus, here is a mixed-revision, switched working copy containing some local modifications:
ja: それで、たとえば混合リビジョンであり、作業コピーはスイッチされて いて、さらにローカルな修正があった場合には以下のようになります:

note: Tag: para
en: If invoked on a directory that is not a working copy, <command>svnversion</command> assumes it is an exported working copy and prints "exported":
ja: 作業コピーではないディレクトリで実行されると、 <command>svnversion</command> はそれがエクスポートされた 作業コピーであると仮定し "exported" と表示します:

note: Tag: refname
en: <literal>mod_dav_svn</literal> Configuration Directives
ja: <literal>mod_dav_svn</literal> 設定ディレクティブ

note: Tag: refpurpose
en: Apache configuration directives for serving Subversion repositories through Apache HTTP Server.
ja: Apache の HTTP サーバを通じて Subversion リポジトリを管理する場合の Apache の設定ディレクティブです。

note: Tag: para
en: This section briefly describes each of the Subversion Apache configuration directives. For an in-depth description of configuring Apache with Subversion, see <xref linkend="svn.serverconfig.httpd"/>.)
ja: この節では Subversion に関係した Apache の設定ディレクティブをそれぞれ 簡単に説明します。(Subversion 利用時の Apache の設定についてのより詳しい説明は <xref linkend="svn.serverconfig.httpd"/>を見てください。)

note: Tag: title
en: Directives
ja: ディレクティブ

note: Tag: para
en: This directive must be included in any <literal>Directory</literal> or <literal>Location</literal> block for a Subversion repository. It tells httpd to use the Subversion backend for mod_dav to handle all requests.
ja: このディレクティブは Subversion リポジトリのあるすべての <literal>Directory</literal> あるいは <literal>Location</literal>ブロックに 含めなくてはなりません。すべての要求の処理にたいして mod_dav のバックエンドとして Subversion を使うよう httpd に指示します。

note: Tag: para
en: This directive allows write requests from WebDAV clients to result in automatic commits. A generic log message is auto-generated and attached to each revision. If you enable Autoversioning, you'll likely want to set <literal>ModMimeUsePathInfo On</literal> so that <literal>mod_mime</literal> can set <literal>svn:mime-type</literal> to the correct mime-type automatically (as best as <literal>mod_mime</literal> is able to, of course). For more information, see
ja: このディレクティブは WebDAV クライアントからの書き込み要求を認め、 それが不分割なコミットになるようにします。一般的なログメッセージが 自動生成されリビジョンごとに付与されます。自動バージョン化を有効に する場合、おそらく <literal>ModMimeUsePathInfo On</literal>も 設定したくなるかも知れません。これによって <literal>mod_mime</literal>は 自動的に正しい mime-type を <literal>svn:mime-type</literal>に設定 できるようになります(もちろん <literal>mod_mime</literal>が可能な 範囲で、です)。より詳細は <xref linkend="svn.webdav"/> を見てください。

note: Tag: para
en: This directive specifies the location in the filesystem for a Subversion repository's files. In a configuration block for a Subversion repository, either this directive or <literal>SVNParentPath</literal> must be present, but not both.
ja: このディレクティブは Subversion リポジトリが使うファイルを置くための ファイルシステム中の場所を指定します。Subversion リポジトリのための 設定ブロック中では、このディレクティブか、<literal>SVNParentPath</literal> のどちらか一方が存在しなてくはなりません。しかし両方存在してはいません。

note: Tag: para
en: Specifies the URI component (namespace) for special Subversion resources. The default is <quote><literal>!svn</literal></quote>, and most administrators will never use this directive. Only set this if there is a pressing need to have a file named <filename>!svn</filename> in your repository. If you change this on a server already in use, it will break all of the outstanding working copies and your users will hunt you down with pitchforks and flaming torches.
ja: Subversion 用の特殊なリソースのための URI 名(名前空間)を指定します。 デフォルトは <quote><literal>!svn</literal></quote> で、ほとんどの 管理者は実際にこのディレクティブを使うことはないでしょう。 リポジトリ中で <filename>!svn</filename>という名前のファイルを 使う特殊な事情がある場合にだけ設定します。サーバ上ですでに利用している 値を変更したりすれば、外部にあるすべての作業コピーが壊れてしまい、 あなたはユーザに捕らえられ、何か恐ろしい目にあうでしょう。

note: Tag: para
en: Specifies the URI of an XSL transformation for directory indexes. This directive is optional.
ja: ディレクトリインデックスのための XSL 変換の URI を指定します。 このディレクティブはオプションです。

note: Tag: para
en: Specifies the location in the filesystem of a parent directory whose child directories are Subversion repositories. In a configuration block for a Subversion repository, either this directive or <literal>SVNPath</literal> must be present, but not both.
ja: そのディレクトリのサブディレクトリが Subversion のリポジトリである ような親ディレクトリの、ファイルシステム中での位置を指定します。 Subversion リポジトリの設定ブロック中には、このディレクティブか <literal>SVNPath</literal>のどちらかが存在しなくてはなりません。 しかし両方存在してはいません。

note: Tag: para
en: Control path-based authorization by enabling or disabling subrequests. See <xref linkend="svn.serverconfig.httpd.authz.pathauthzoff"/> for details.
ja: パス名にもとづいた認可を許可したり禁止したりするのに使います。 詳しくは <xref linkend="svn.serverconfig.httpd.authz.pathauthzoff"/>を見てください。

note: Tag: title
en: Unversioned Properties
ja: バージョン化されない属性

note: Tag: title
en: Repository Hooks
ja: リポジトリのフック

note: Tag: primary
en: repository
ja: リポジトリ

note: Tag: para
en: repository path
ja: リポジトリパス

note: Tag: para
en: access control
ja: アクセス制御

note: Tag: para
en: commit notification, tool integration
ja: コミット通知、ツール連携

note: Tag: para
en: name of the property changed
ja: 属性名が変化しました

note: Tag: para
en: propchange notification
ja: 属性の変更通知

note: Tag: para
en: lock notification
ja: ロック通知

note: Tag: para
en: unlock notification
ja: ロック解除通知

note: Tag: para
en: The problem with such FAQs is that they are not, in a literal sense, FAQs at all. No one ever called the tech support line and asked, <quote>How can we maximize productivity?</quote>. Rather, people asked highly specific questions, like, <quote>How can we change the calendaring system to send reminders two days in advance instead of one?</quote> and so on. But it's a lot easier to make up imaginary Frequently Asked Questions than it is to discover the real ones. Compiling a true FAQ sheet requires a sustained, organized effort: over the lifetime of the software, incoming questions must be tracked, responses monitored, and all gathered into a coherent, searchable whole that reflects the collective experience of users in the wild. It calls for the patient, observant attitude of a field naturalist. No grand hypothesizing, no visionary pronouncements here&mdash;open eyes and accurate note-taking are what's needed most.
ja: このような FAQ の問題点は、文字通り FAQ でも何でもないというところ です。技術サポートに電話をして<quote>どうやったら生産性が最大になる のでしょうか?</quote>などと聞く人は一人もいないのです。そうではなく、 本当はもっとずっと具体的な質問がしたいのです、たとえば<quote>どうやったら カレンダーシステムを変更して一日前でなく、二日前に通知するように できますか?</quote>のような。しかし本当の問題点を明らかにするより、 仮想的な FAQ を作るほうがずっとやさしいのです。本当の FAQ を作るには 忍耐強い、組織的な努力が必要なのです: ソフトウェアの一生を通じて やってくる問いを追いかけ、それに対する答えを見守り、それらすべてを 集めて経験の浅いユーザの集約的な経験を反映するように検索可能な形に まとめる必要があります。それは忍耐が必要で、自然主義者のように物事 を黙って観察する態度が必要になります。ここには権威に基づいた仮定や 希望的な観測が入り込む余地はありません&mdash;開かれた態度と正確に 物事を記録する態度こそが必要なのです。

note: Tag: para
en: What I love about this book is that it grew out of just such a process, and shows it on every page. It is the direct result of the authors' encounters with users. It began with Ben Collins-Sussman's observation that people were asking the same basic questions over and over on the Subversion mailing lists: What are the standard workflows to use with Subversion? Do branches and tags work the same way as in other version control systems? How can I find out who made a particular change?
ja: この本について私が気に入っているところは、そんな過程を通じて絶えず 本が育っていくところであり、それはすべてのページに現れています。 この本はユーザに対する著者の対峙そのものの結果なのです。それは Subversion メーリングリストで繰り返し問われた基本的な質問を Ben Collins-Sussman が観察することから始まりました: Subversion を使う場合の標準的なワークフローとはいったいどのような ものなのだろうか? ブランチやタグは他のバージョン管理システムと 同じように機能するのだろうか? 誰が特定の変更を加えたということを どうやって把握すればよいのだろうか?

note: Tag: para
en: Frustrated at seeing the same questions day after day, Ben worked intensely over a month in the summer of 2002 to write <citetitle>The Subversion Handbook</citetitle>, a sixty page manual that covered all the basics of using Subversion. The manual made no pretense of being complete, but it was distributed with Subversion and got users over that initial hump in the learning curve. When O'Reilly and Associates decided to publish a full-length Subversion book, the path of least resistance was obvious: just expand the Subversion handbook.
ja: 毎日毎日同じ質問を目にすることに強い不満を感じ、Ben は 2002 年の 夏に一ヵ月以上かけて <citetitle>The Subversion ハンドブック</citetitle> を書き上げました。これは 60 ページのマニュアルで、Subversion を利用 する際のすべての基本を扱っていました。マニュアルは完成したような 顔をしませんでしたが、Subversion と共に配布され、学習曲線の最初の 障害を取り除きました。O'Reilly and Associates が完全な Subversion の本を出版しようと決めたとき一番手っ取り早い方法は明らかでした: 単に Subversion ハンドブックを拡張すればよかったのです。

note: Tag: para
en: The three co-authors of the new book were thus presented with an unusual opportunity. Officially, their task was to write a book top-down, starting from a table of contents and an initial draft. But they also had access to a steady stream&mdash;indeed, an uncontrollable geyser&mdash;of bottom-up source material. Subversion was already in the hands of thousands of early adopters, and those users were giving tons of feedback, not only about Subversion, but about its existing documentation.
ja: 新しい本の三人の共著者は普通ではない幸運に恵まれていました。醐ｷｺ�には 彼らの仕事は本をトップダウンに書き下すために目次を作ることからはじめ、 最初の版を作ることでした。しかし彼らはまた確固とした&mdash; 確かにそれは制御不能な形でわきあがるような性質のものでしたが&mdash; 生の素材に直接触れることもしました。Subversion はすでに何千と言う 初期ユーザの手にあり、それらのユーザは無数のフィードバックをもたらし それは Subversion 本体のみならず、すでに存在しているドキュメントに 対してもそうなのでした。

note: Tag: para
en: Of course, no one can promise that this book will answer every question you have about Subversion. Sometimes, the precision with which it anticipates your questions will seem eerily telepathic; yet occasionally, you will stumble into a hole in the community's knowledge, and come away empty-handed. When this happens, the best thing you can do is email <email>users@subversion.tigris.org</email> and present your problem. The authors are still there, still watching, and they include not just the three listed on the cover, but many others who contributed corrections and original material. From the community's point of view, solving your problem is merely a pleasant side effect of a much larger project&mdash;namely, slowly adjusting this book, and ultimately Subversion itself, to more closely match the way people actually use it. They are eager to hear from you not merely because they can help you, but because you can help them. With Subversion as with all active free software projects, <emphasis>you are not alone</emphasis>.
ja: もちろん、誰もこの本がSubversion についてのすべての疑問に 答えられるとは約束できる人はいません。質問の期待に、ときどき テレパシーのような精密さで答えることがあるかと思えば、Subversion コミュニティーの知識の中の落とし穴にはまりこんでしまい、手ぶらで 出てくるようなことも、しばしばおこるでしょう。そんな時の一番よい 方法は、<email>users@subversion.tigris.org</email>にメールを 送って自分の問題を示すことです。著者らはまだそこにいますし、依然と してリストを監視していますし、本の扉に書かれた三人以外にもたくさんの 人が誤りの訂正や最初の資料について貢献してくれています。コミュニティー の観点から言うと、あなたの問題の解決は単にもっとずっと大きなプロジェクト の喜ばしい副作用でしかありません&mdash; そのプロジェクトとはつまり、 ゆっくりとこの本の内容を調整し、そして最終的には Subversion そのものが 実際に利用する人々に、より役立つものにすることです。皆は単にあなたを 助けることができるということだけではなく逆に皆を助けるということができる という理由であなたの話しによろこんで耳を貸すでしょう。これはSubversion も 他のすべての活発なフリーソフトウェアプロジェクトでも同じです。 <emphasis>あなたは一人ではないのです</emphasis>。

note: Tag: para
en: Let this book be your first companion.
ja: どうかこの本をあなたの最良の共とせんことを。
