Loading article…
Apache Subversion（コマンド名svnにちなんでSVNと略されることが多い）は、 Apacheライセンスの下でオープンソースとして配布されているバージョン管理システムです。[ 1 ]ソフトウェア開発者は、ソースコード、Webページ、ドキュメントなどのファイルの現在および過去のバージョンを管理するためにSubversionを使用します。その目標は、広く使用されているConcurrent Versions System （CVS）とほぼ互換性のある後継システムとなることです。
オープンソースコミュニティはSubversionを広く使用してきました。たとえば、Apache Software Foundation、FreeBSD、SourceForgeなどのプロジェクト、および2006年から2019年までのGCCなどです。[ 2 ] CodePlexは以前はSubversionリポジトリの一般的なホストでした。
Subversionは2000年にCollabNet Inc.によって作成され、世界中の貢献者コミュニティによって構築および使用されているトップレベルのApacheプロジェクトでした。[ 3 ]
CollabNet は2000 年に Subversion プロジェクトを設立しました。これは、 CVSとよく似た動作をするが、CVS のバグを修正し、CVS に欠けているいくつかの機能を提供するオープンソースのバージョン管理システムを作成する取り組みでした。 [ 4 ] 2001 年までに Subversion は十分に進歩し、独自のソースコードをホストできるようになり、[ 4 ] 2004 年 2 月にバージョン 1.0 がリリースされました。[ 5 ] 2009 年 11 月に Subversion は Apache Incubator に受け入れられました。これは、標準的なトップレベルの Apache プロジェクトになるためのプロセスの始まりとなりました。[ 6 ] 2010 年 2 月 17 日にトップレベルの Apache プロジェクトになりました。[ 7 ]
リリース日は、すべてのリリース履歴を記録するApache SubversionのCHANGESファイル[ 26 ]から抽出されます。
Subversionは2種類のレポジトリストレージを提供します。
Subversion の初期開発ではBerkeley DBパッケージが使用されていました。データベースにアクセスするプログラムがクラッシュしたり強制終了したりした場合、Subversion は Berkeley DB の使用に関していくつかの制限があります。データの損失や破損は発生しませんが、Berkeley DB がジャーナルを再生して未解決のロックをすべてクリーンアップしている間、リポジトリはオフラインのままになります。Berkeley DB リポジトリで Subversion を使用する最も安全な方法は、共有ファイルシステムではなく、単一のサーバー プロセスを 1 人のユーザーとして実行することです。[ 27 ] Berkeley DB バックエンドはバージョン 1.8 で非推奨になりました。[ 28 ]
2004年に、FSFSという新しいストレージサブシステムが開発されました。これは、ログ記録が少ないため、多数のファイルを含むディレクトリでBerkeley DBバックエンドよりも高速に動作し、ディスク容量も少なくて済みます。[ 27 ]
Subversion 1.2以降、FSFSは新規リポジトリのデフォルトのデータストアとなった。
「FSFS」という名称の語源は、Subversionがリポジトリストレージシステムを指す際に「ファイルシステム」という用語を使用していることに由来します。FSFSは、Berkeley DBのような構造化されたシステムではなく、オペレーティングシステムのファイルシステム内に直接コンテンツを保存します。したがって、FSFSは「ファイルシステムの上に構築されたSubversionファイルシステム」と言えます。
FSXと呼ばれる新しいファイルシステムは、FSFSのいくつかの制限を取り除くために開発中です。バージョン1.9で追加されましたが、製品版として使用できるとは考えられていませんでした。[ 29 ]バージョン1.14の時点では、まだ実験版としてマークされています。[ 30 ]
Subversionリポジトリへのアクセスは、以下の方法で行うことができます。
これら3つの手段はすべて、FSFSとBerkeley DBの両方のリポジトリにアクセスできます。
クライアントの 1.x バージョンは、どの 1.x サーバーとも連携できます。新しいクライアントとサーバーには追加機能とパフォーマンス機能がありますが、古いクライアント/サーバーへのフォールバックサポートも備えています。[ 32 ]
Subversionシステムは内部的に、レイヤー状に配置された複数のライブラリで構成されています。それぞれのライブラリは特定のタスクを実行し、開発者は必要な複雑さと特異性のレベルに応じて独自のツールを作成できます。
Subversionファイルシステムは「二次元」と見なすことができる。[ 33 ]ファイルシステム項目を明確に指定するために2つの座標が使用される。
Subversionファイルシステムでは、各リビジョンにそれぞれルートディレクトリがあり、そのルートディレクトリを使って該当リビジョンの内容にアクセスします。ファイルは最新の変更へのリンクとして保存されるため、Subversionリポジトリは非常にコンパクトです。システムが消費するストレージ容量は、リビジョンの数ではなく、変更の数に比例します。
Subversionファイルシステムは、トランザクションを使用して変更のアトミック性を維持します。トランザクションは、ファイルシステムの特定のリビジョン（必ずしも最新リビジョンとは限りません）に対して動作します。トランザクションには独自のルートがあり、そこで変更が行われます。その後、トランザクションはコミットされて最新のリビジョンになるか、中止されます。トランザクションは実際には長期間存続するファイルシステムオブジェクトです。クライアントはトランザクションをコミットまたは中止する必要はなく、トランザクションを開始して終了し、その後トランザクションを再度開いて使用を続けることもできます。理論的には、複数のクライアントが同じトランザクションにアクセスしてアトミックな変更を共同で実行できますが、現在この機能を公開しているクライアントはありません。
Subversionファイルシステムの重要な機能の一つにプロパティがあります。プロパティとは、名前と値のペアで表されるテキストです。ほとんどのプロパティはファイルシステムのエントリ（ファイルやディレクトリなど）に存在します。これらは、ファイルシステムへの他の変更と同様にバージョン管理されます。Subversionクライアントは組み込みプロパティ用に「svn:」というプレフィックスを予約していますが、カスタムプロパティを定義するために他の名前を使用することもできます。
.cvsignore。Subversion はリビジョン自体にもプロパティを使用します。ファイルシステムのエントリのプロパティと同様に、名前は完全に任意で、Subversion クライアントは特定のプロパティに「svn:」という接頭辞を付けて使用します。ただし、これらのプロパティはバージョン管理されておらず、pre-revprop-change フックで許可されていれば後で変更できます。[ 36 ]
Subversion はPerforce [ 37 ]のファイル間ブランチング モデルを使用してブランチとタグ付けを実装します。ブランチは開発の独立したラインです。[ 38 ]タグ付けとは、リポジトリを特定の時点でラベル付けして、将来簡単に見つけられるようにすることです。Subversion では、ブランチとタグの違いは、それらの使用方法だけです。
新しいブランチまたはタグは、「 svn copy 」コマンドを使用して作成します。このコマンドは、オペレーティングシステムのネイティブなメカニズムの代わりに使用する必要があります。コピーされたディレクトリはリポジトリ内の元のディレクトリにリンクされ、履歴が保持されます。また、コピーされたディレクトリはリポジトリ内でほとんど余分な容量を消費しません。
各ブランチのすべてのバージョンは、コピー時点までのファイルの履歴と、それ以降に加えられた変更を保持しています。変更内容をメインブランチにマージしたり、ブランチ間でマージしたりすることも可能です。
Subversionの既知の問題により、ファイルおよびディレクトリ名の変更操作の実装に影響が出ています。2014年現在Subversion では、ファイルやディレクトリの名前変更は、新しい名前への「コピー」に続いて古い名前の「削除」として実装されます。名前だけが変更され、編集履歴に関するすべてのデータはそのまま残り、Subversion は「ツリー」の古いリビジョンでは古い名前を引き続き使用します。ただし、通常のコミットとブランチのマージの両方で、移動が他の場所で行われた編集と競合すると、Subversion は混乱する可能性があります。[ 39 ] [ 40 ] Subversion 1.5 リリースでは、これらのシナリオの一部に対処しましたが、他のシナリオは問題が残りました。[ 41 ] Subversion 1.8 リリースでは、クライアントで移動を第一級の操作にすることでこれらの問題の一部に対処しましたが、リポジトリでは依然としてコピー+削除として扱われます。[ 42 ]
2013年現在Subversionには、リポジトリ管理機能がいくつか欠けています。たとえば、リポジトリを編集して特定のデータの履歴レコードをすべて完全に削除したい場合があります。Subversionには、これを簡単に実現するための組み込みサポートがありません。[ 43 ]
Subversion はローカル マシンにデータの追加コピーを保存しますが、これは非常に大きなプロジェクトやファイル、または開発者が複数のブランチで同時に作業する場合に問題となる可能性があります。バージョン 1.7 より前のバージョンでは、.svnグローバル検索/置換操作などの不適切なユーザー操作によってクライアント側のこれらのディレクトリが破損する可能性がありました。[ 44 ]バージョン 1.7 以降、Subversion は作業領域ごとに単一の中央集中型の.svnフォルダを使用します。[ 45 ]
Subversion はファイルの最終更新日時を保存しません。そのため、Subversion リポジトリからチェックアウトされたファイルには (リポジトリ内の最終更新日時ではなく) の「現在」の日付が付き、リポジトリにチェックインされたファイルには (チェックインされたファイルの最終更新日時ではなく) チェックインの日付が付きます。これは必ずしも望ましい動作とは限りません。[ 46 ] この問題を解決するために、最終更新日時やその他のファイルシステムのメタデータを保持できるサードパーティ製のツールが存在します。[ 47 ] [ 48 ]ただし、チェックアウトされたファイルに現在の日付を付けることも重要です。make (1) などのツールは、このようにして変更されたファイルを認識し、再構築します。
Subversionは、中央集権型のバージョン管理モデルを採用しています。Subversionの設計者の1人であるベン・コリンズ＝サスマンは、中央集権型モデルは「自信のないプログラマー」が開発中に他のチームメンバーから自分の作業を隠すことを防ぐのに役立つと考えています。 [ 49 ]バージョン管理システムのユーザーの中には、中央集権型モデルを有害だと考える人もいます。有名な例として、リーナス・トーバルズはSubversionのモデルとその開発者を批判しました。[ 50 ]
Subversion は、HFS+ファイルシステムによって実行されるファイル名の正規化をうまく処理できないことがよくあります。そのため、名前にアクセント付き文字を含むファイルが HFS+ 以外のファイルシステム上のリポジトリに追加され、その後 HFS+ でリポジトリが使用されると問題が発生する可能性があります。[ 51 ]
どのバージョン管理システムでも、リビジョン番号を覚えるのは困難です。そのため、ほとんどのシステムでは、ユーザーフレンドリーな参照としてシンボリックタグを提供しています。Subversionにはそのような機能はなく、代わりに推奨されている方法は性質が大きく異なります。Subversionでは、履歴上のポイントへの参照としてタグを実装する代わりに、リポジトリツリー内の既知のサブディレクトリ（" "）にスナップショットコピーを作成することを推奨しています。使用できる事前定義された参照は、、、およびのみです。tags/HEADBASEPREVCOMMITTED
この歴史を宇宙に投影する手法には、複数の問題点がある。
svn diff -r tag1:tag2 myfile機能しません。これを実現するには、名前だけでなくスナップショットへの URL/パスを知って入力する必要があるため、少し複雑になります。svn diff <URL-TO-TAG1>/myfile <URL-TO-TAG2>/myfileたとえば、などの他の操作はsvn log -r tag1:tag2 myfile不可能です。tags/サブディレクトリをどのレベルに作成するかを決定するのが難しい場合が多いのです。 このような問題に対処するため、Subversion メーリングリストの投稿者たちは、「ラベル」または「エイリアス」と呼ばれる新機能を提案している。[ 52 ] SVN ラベルは、 CVSやGitなどの他のシステムの「タグ」により近いものとなるだろう。Subversion にはグローバルなリビジョン番号があるため、ラベルからリビジョンへの実装は非常に簡単に行える。しかし、2013 年現在、進展はなく、シンボリックタグは最も望まれている機能のリストには含まれていない。[ 53 ]
CollabNet はSubversion への関与を継続していますが、プロジェクトは独立したオープンソースコミュニティとして運営されています。2009 年 11 月、プロジェクトは Apacheソフトウェア財団の取り組みの一部となることを目指して Apache インキュベーターに受け入れられました。[ 54 ] 2010 年 3 月以降、プロジェクトは正式に Apache Subversion として知られ、Apache トップレベルプロジェクトの一部となっています。[ 55 ]
2009年10月、WANdiscoはSubversionの中核コミッターの採用を発表し、同社がSubversionプロジェクトの主要な企業スポンサーとなることを表明した。これには、2008年初頭からSubversion Corporationの社長であり、Subversionプロジェクトのリリースマネージャーを務めていたHyrum Wrightも含まれており、彼はオープンソースチームを率いるために同社に入社した。[ 56 ]
Subversionのオープンソースコミュニティはバイナリを提供していませんが、潜在的なユーザーはボランティアからバイナリをダウンロードできます。[ 57 ] SubversionプロジェクトにはSubversionで使用するための公式のグラフィカルユーザーインターフェイス（GUI）は含まれていませんが、サードパーティはさまざまなGUIと、さまざまな追加の補助ソフトウェアを開発しています。
2009年に発表された作業には、SubversionJ（Java API ）と、 Perforceが提供するものと同様のObliterateコマンドの実装が含まれていました。これらの機能強化はどちらもWANdiscoによって後援されました。[ 58 ]
Subversionのコミッターは通常、常に少なくとも1つか2つの新機能を積極的に開発している。2011年10月にリリースされたSubversion 1.7には、パフォーマンスを向上させるための合理化されたHTTPトランスポートと、書き直されたワーキングコピーライブラリが含まれていた。[ 59 ]
2002年、Subversionのロゴを選定するためのデザインコンテストが開催されました。応募作品と各ロゴへの投票結果は、こちらでご覧いただけます。
{{cite web}}: CS1 maint: url-status (リンク)#define SVN_FS_TYPE_FSX "fsx"
実験的なファイルシステムバックエンド。
一般的な本番環境での使用には適していません。推奨される使用シナリオについては、それぞれのリリースノートを参照してください。
