サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
TGS2024
www.caldron.jp/~nabetaro
説明作業コピーやリポジトリ中のファイルをコピーします。SRC と DST は、作業コピー (WC) 上のパスでも、URLでもかまいません。 WC -> WC追加用に項目をコピーし、追加準備をします (履歴含む)。WC -> URLWC のコピーを、直接 URL にコミットします。URL -> WCURL を WC にチェックアウトし、追加準備をします。URL -> URL完全なサーバ上でののコピーです。通常ブランチやタグに利用します。
さて、あなたとSallyはプロジェクト上の平行したブランチで作業しています。 あなたは自分のプライベートなブランチで作業していて、Sally は trunk、あるいは、開発の主系の上で作業していると します。たくさんの貢献者がいるようなプロジェクトでは、ほとんどの人たちは trunkのコピーを持っているのが普通です。trunk を壊してしまうかも知れない ような長い期間をかけての変更を加える必要がある場合は常に、標準的な手続き としてはまずプライベートなブランチを作り、すべての作業が完了するまで変更 点をそのブランチにコミットします。そのようなやり方の利点としては、二人の作業はお互いに干渉しないところです。 欠点は二人の作業内容はすぐにひどく 違っていって しまうことです。「引きこもり」戦略の問題の一つは自分のブランチの作業が完了するときに起こることを思い出してください。恐ろしくたくさんの
別のバージョン管理の概念に、タグがあります。 タグはある時点でのプロジェクトの「スナップショット」です。Subversion ではこのアイディアは既にさまざまな場所にあるように見えます。それぞれ のリポジトリリビジョンはまさにそれです—つまり、それはコミット直後の ファイルシステムのスナップショットです。しかし、人はしばしばタグに対して人間になじみのある名前を付けたいと 思うものです。たとえば、「release-1.0」のような。また、ファイルシステム のもっと小さなサブディレクトリのスナップショットがほしいこともあります。 結局、あるソフトの一部のrelease-1.0 がリビジョン4822の特定のサブディレクトリ であることを思い出すのは簡単ではありません。 もう一度、svn copy の助けを借ります。 もしHEADリビジョンの/calc/trunk のスナップ ショットを作りたいと
製作著作 © 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato This work is licensed under the Creative Commons Attribution License. To view a copy of this license, visit http://creativecommons.org/licenses/by/2.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
書式svnadmin dump REPOS_PATH [-r LOWER[:UPPER]] [--incremental] 説明ファイルシステムの内容を、「ダンプファイル」 可搬形式で標準出力にダンプし、進行状況を標準エラー出力に表示します。リビジョン LOWER から、リビジョン UPPER までをダンプします。リビジョンを指定しなければ、すべてのリビジョンツリーをダンプします。LOWER だけ指定した場合、一つのリビジョンツリーをダンプします。実際の使い方については、リポジトリデータを別の場所へ移動項 をご覧ください。デフォルトでは、Subversionの ダンプファイルストリームは、 ツリー全体を一度に追加したかのように、単一リビジョン (要求したリビジョン範囲の先頭リビジョン) のリポジトリにある全ファイル・ディレクトリを含みます。続いて、その他のリビジョン (要求した範囲の残りの
Subversion では、ユーザが任意の名前のバージョン管理下の属性を、ファイルやディレクトリに対して設定でき、またバージョン管理外の属性をリビジョンに設定できます。名前が svn: (Subversion が自分で使用するため予約) で始まる属性にのみ、制限があります。Subversion の動作を制御するため、ユーザがこの属性を設定している場合、新しい svn: 属性を設定しないかもしれません。 svn:executableファイルに設定すると、クライアントは Unix にある作業コピーのファイルを実行可能にします。ファイルの実行権項 をご覧ください。svn:mime-typeファイルに設定すると、この値はファイルの mime-type を表します。これによりクライアントは、更新時に行う行ベースの文脈マージが安全かどうか判断でき、Web ブラウザで取得した際のファイルの扱い方も判断で
--diff-cmdと--diff3-cmd オプションや 同じような名前の実行時環境パラメータ(config項参照)がある ので、Subversion で外部差分ツール(あるいは 「diff」)とマージツールを 使うのは簡単なことだという間違った考えを持ってしまうかも知れません。 Subversion ではそのようなよく知られたほとんどのツールを使うことが できますが、このような設定に必要な努力はそれほど簡単ではないことが よくあります。Subversion と外部 diff と merge ツールは Subversion の唯一の文脈差分 を出力する能力が GNU の diffutils の連携した呼び出しだけであった ころに由来しています。具体的には diff と diff3 ユーティリティーです。Subversion が必要とする ような動作をさせるには、そのようなユーティリティー
ブランチの作り方とsvn mergeにはいくつもの異なったやり方があり、この節では あなたが出くわしそうな一番よくあるパターンについて説明します。 いま、考えてきた例を完結させるため、少し時間が経過したとします。何日か 経過し、たくさんの変更がtrunkにもあなたのプライベートなブランチにも 起こったとましす。そしてあなたはプライベートなブランチ上での作業を 終えたとしましょう; 機能追加、またはバグフィッックスが完了し、他の 人がその部分を使えるようにするために、あなたのブランチ上の変更点の すべてを trunk にマージしたいとします。さて、このような状況では、どのようにしてsvn merge を使えば良いのでしょうか? このコマンドは二つのツリーを比較し、その差分を 作業コピーに適用するものであったことを思い出してください。変更点 を受け取るためには、あなたはtrunkの作業コピーを
説明作業コピーのファイルやディレクトリの「競合」状態を解決します。この処理は競合マーカを意味的に解決するわけではありませんが、--accept 引数で指定したバージョンで、PATH を置き換え、競合に関係する中間ファイルを削除します。これにより PATH をもう一度コミットできるようにします。つまり、その競合は既に「解決された」と Subversion に伝えます。あなたが希望する解決法により、--accept コマンドに以下の引数を渡せます。 base作業コピーを更新する前の、BASE リビジョンのファイルを選択します。これは、最後の編集を行う前のチェックアウトしたファイルです。working手動で競合解決を行ったと仮定し、現在作業コピーにあるファイルを、このファイルのバージョンとして選択します。mine-full競合したすべてのファイルを、svn update を実行する直前にあったフ
あなたの Subversion リポジトリはタイムマシンのようです。いままでコミットされたすべての変更を記録し、ファイルやディレクトリ、それに付随したメタデータの以前のバージョンを見ることによって履歴を調べることができます。ひとつの Subversion コマンドを使って、過去の任意の日付やリビジョン番号のリポジトリの状態をチェックアウト (あるいは既にある作業コピーを復元) することができます。しかし、過去に戻るのではなく、 単に過去がどうだったかをちょっと覗いてみたいこともよくあります。リポジトリからの履歴データをあつかうためのコマンドが、いくつかあります。 svn logリビジョンに付随した日付、修正者つきのログメッセージと、各リビジョンでどのパスが変更されたかといった、全般的な情報を表示します。svn diffここの変更の詳細を行レベルで表示します。svn cat特定のリビジョン番
ブランチ、タグ、マージはほとんどすべてのバージョン管理システムで 共通の概念です。もしあまりなじみがないのであれば、この章は良い とっかかりになるでしょう。既に詳しいのであれば、これらの概念 をSubversionがどのように実装しているかを知るのに興味深い章である ことがわかるでしょう。ブランチ化は、バージョン管理の基本にあります。Subversionで自分の データをマージするときには、この機能はときどき必要となる機能です。 この章では、あなたがSubversionの基本コンセプトを既に理解している ことを前提とします(第1章)。
書式diff [-c M | -r N[:M]] [TARGET[@REV]...]diff [-r N[:M]] --old=OLD-TGT[@OLDREV] [--new=NEW-TGT[@NEWREV]] [PATH...]diff OLD-URL[@OLDREV] NEW-URL[@NEWREV] 説明二つのパス間の差分を表示します。svn diffには、以下の使い方があります。作業コピーの手元の変更を表示するには、ただ svn diff' としてください。REV の二つのリビジョン間に現れる、TARGET にされた変更を表示します。TARGET はすべて作業コピーのパスか、すべて URL です。TARGET が作業コピーのパスの場合、N のデフォルト値は BASE で、M のデフォルトは作業コピーです。URL の場合、N は指定せねばならず、M のデフォルト値は HEAD です。
名前mod_dav_svn 設定ディレクティブ — Apache の HTTP サーバを通じて Subversion リポジトリを提供する、Apache 設定ディレクティブです。 説明この節では、Subversion の Apache 設定ディレクティブを、それぞれ簡単に説明します。Subversion 利用時の Apache の設定について、掘り下げた説明は httpd (Apache HTTP サーバ)項 をご覧ください。 DAV svnSubversion リポジトリ用の Directory ブロックや Location ブロックに含めなくてはなりません。すべての要求の処理に対して、mod_dav のバックエンドとして Subversion を使うよう httpd に指示します。SVNAllowBulkUpdates On|Off更新形式の REPORT リクエストに対する、すべてを
svndumpfilter は、Subversion のダンプファイルから、複数のプレフィックスで始まる包含・除外パス指定により、履歴を削除するコマンドラインユーティリティです。詳細は、svndumpfilter項 をご覧ください。 --drop-empty-revsフィルタリングの結果リビジョンが空になった場合 (リポジトリで変更がなくなった場合など)、そのリビジョンを最終的なダンプファイルから削除します。--renumber-revsフィルタリング後に、残ったものに対して、リビジョン番号を付け直します。--skip-missing-merge-sourcesフィルタリングの一部として、削除されたマージ元をスキップします。このオプションを指定しないと、保持しているパスのマージ元がフィルタリングによって削除された場合、svndumpfilter はエラーを発生して終了します。--prese
リビジョン項 で説明したように、Subversion のリビジョン番号は、(バージョン管理下のデータに変更を加えてコミットするたびに大きくなる整数という) とても簡単なものです。さらに、全リビジョンで何がおきたか、ずっと前から憶えていなくても時間はかかりません。幸い典型的な Subversion のワークフローでは、Subversion の操作を行う際に、任意のリビジョンを指定する必要はまずありません。リビジョン指定子が必要な操作を行うためには、一般的にはコミットメール (他の Subversion 操作の出力結果) にあるリビジョン番号や、特定の番号を意味する文字列を指定します。しかし時には、憶えていなかったりすぐに手に入らないリビジョン番号を、ピンポイントで指定する必要があります。そのため、整数のリビジョン番号に加えて、svn には、他にもリビジョン指定子の形式があります。リビジョンキ
You are reading Version Control with Subversion (for Subversion 1.5), by Ben Collins-Sussman, Brian W. Fitpatrick, and C. Michael Pilato. This work is licensed under the Creative Commons Attribution License v2.0. To submit comments, corrections, or other contributions to the text, please visit http://www.svnbook.com/.
チームで作業しているプロジェクトでは、前回更新後にプロジェクトの他のメンバーが加えた変更を受け取るため、作業コピーを更新したくなります。svn update を使って、自分の作業コピーをリポジトリの最新バージョンと同期させてください。 $ svn update U foo.c U bar.c リビジョン 2 に更新しました。 この場合、あなたが最後に更新してから、誰か別の人が foo.c と bar.c の両方に加えた変更をコミットしており、Subversion は、この変更をあなたの作業コピーに加えるため更新しました。svn update で、サーバが作業コピーに変更を送信する際、作業コピーを最新にするために Subversion が行った処理の内容を、各項目の前に 1 文字で表します。その文字の意味を知るには、svn help update を実行してください。 さて、これで自分の作業
As you saw in リビジョン項, revision numbers in Subversion are pretty straightforward—integers that keep getting larger as you commit more changes to your versioned data. Still, it doesn't take long before you can no longer remember exactly what happened in each and every revision. Fortunately, the typical Subversion workflow doesn't often demand that you supply arbitrary revisions to the Subversion ope
オプション--revision (-r) REV --non-recursive (-N) --quiet (-q) --diff3-cmd CMD --relocate FROM TO --username USER --password PASS --no-auth-cache --non-interactive --config-dir DIR 例vendors-with-fix から分岐した vendors というディレクトリ内にいて、そのブランチの作業コピーに移りたい場合は以下のようにします。$ svn switch http://svn.red-bean.com/repos/branches/vendors-with-fix . U myproj/foo.txt U myproj/bar.txt U myproj/baz.c U myproj/qux.c リビジョン 31 に更
製作著作 © 2002, 2003, 2004, 2005, 2006, 2007, 2008 Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato This work is licensed under the Creative Commons Attribution License. To view a copy of this license, visit http://creativecommons.org/licenses/by/2.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
オプション--revision (-r) REV --quiet (-q) --non-recursive (-N) --username USER --password PASS --no-auth-cache --non-interactive --ignore-externals --config-dir DIR 例mine と呼ばれるディレクトリに、作業コピーをチェックアウトします。$ svn checkout file:///tmp/repos/test mine A mine/a A mine/b リビジョン 2 をチェックアウトしました。 $ ls mine 二つの異なるディレクトリを、二つの別々の作業コピーにチェックアウトします。$ svn checkout file:///tmp/repos/test file:///tmp/repos/quiz A test/a A t
ソフトウェアを開発する場合が典型的な例ですが、バージョン管理で保守しているデータが しばしば誰かのほかのデータに密接に関係しているか、あるいは依存している ことがあります。一般的にプロジェクトで要求されることは、プロジェクトの 安定性を損なうことなく、外部の資源によって提供されるデータをできる限り 最新に保つことです。この考え方は、あるグループによって作られた情報が もう1つのグループによって作られるものに影響を与える場合、常に成り立ちます。たとえば、ソフトウェア開発者がサードパーティー製のライブラリを利用する アプリケーションの開発に取り組んでいるとします。SubversionはApache ポータブル 実行時ライブラリと、ちょうどそのような関係を持っています。 (Apache Portable Runtime ライブラリ項参照)。Subversionのソースコードは すべての可搬性の要
あなたの仕事が、何かのハンドブックを扱う企業の一部署で、ドキュメントの 管理をすることだとします。ある日別の部署から同じハンドブックが必要 なのだが、ある部分を「ちょっとだけ」変えたものがほしい、ほんの少しだけ 業務形態に違いがあるから、といわれたとします。この状況で、あなたはどうしなくてはならないでしょうか? 答えはあたりまえです: ドキュメントのコピーを作って二つのコピーを 別々に管理することにします。それぞれの部署が小さな変更を依頼して くるたび、一方を修正したり、もう一方を修正したりします。両方のコピーに同じ修正を加えたいこともよくあります。たとえば 最初のコピーにスペルミスがあったとします。もう一方のコピーにも おそらく同じ間違いがあるでしょう。両方のドキュメントはほとんど同じ なのですから。二つはほんの少し違っているだけです。これは ブランチの基本的な概念です— つまり、一つの
オプション--revision (-r) REV --quiet (-q) --verbose (-v) --targets FILENAME --stop-on-copy --incremental --limit NUM --xml --username USER --password PASS --no-auth-cache --non-interactive --config-dir DIR 例最上位で svn log を実行することによって作業コピー中の変更されたすべての パスのログメッセージを見ることができます。$ svn log ------------------------------------------------------------------------ r20 | harry | 2003-01-17 22:56:19 +0900 (金, 17 1月 20
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
書式svn merge [-c M | -r N:M] SOURCE[@REV] [WCPATH]svn merge sourceURL1[@N] sourceURL2[@M] [WCPATH]svn merge sourceWCPATH1@N sourceWCPATH2@M [WCPATH] 説明最初の形式と二番目の形式ではソースとなるパス (最初の形式ではURL、二番目の形式では作業コピーパス) はリビジョン N と M で指定され、この二つを比較します。リビジョンを省略すると HEAD をデフォルトとします。「-c M」 オプションは、N = M-1 の状態の 「-r N:M」 と等価です。「-c -M」 は逆 (N = M-1 の状態の 「-r M:N」) になります。三番目の形式では SOURCE は URL か作業コピーの項目で、その場合、対応した URL を利用します。この
Apache HTTP Server は 「非常にいろいろなことをしてくれる」 ネットワークサーバ でSubversionの機能も上げることができます。カスタムモジュールを使って httpdはSubversion リポジトリをWebDAV/DeltaVプロトコル 経由でクライアントから利用可能にします。WebDAV/deltaVプロトコルは HTTP 1.1 の拡張です(http://www.webdav.org/ により詳しい情報が あります)。このプロトコルはワールドワイドウェブの核心である、 広く利用可能なHTTP プロトコルに対して、書き込み—特にバージョン管理下の書き込み—機能を付け加えます。結果は標準化された、堅牢なシステム を構成することができ、それは Apache 2.0 の一部としてパッケージ化されて います。また Apache 2.0 はさまざまなオペレーティングシステ
次のページ
このページを最初にブックマークしてみませんか?
『www.caldron.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く