なんですかそれは？ [SVN]

ページへ戻る

+ Links

印刷

ページ内コンテンツ

なんですかそれは？
簡単な説明
- 例１
- 例2
- 例3
OSASK計画のSVNの実際

なんですかそれは？

SVNはSubversionという名のソフト(システム？）で、ソースコードの管理および公開・ダウンロードを助けてくれるものです。

OSASK計画ではSourceforge.jpが貸し出してくれているSVNを活用しています。

http://svn.osask.net/

簡単な説明

ソースコードはどんどん変更されていきますよね？。でも、逆に修正したらバグが出てしまったので前のものからやり直したいなんてこともよく起こります。歴代のソースはできるだけキチンと名前を付けて残しておきたいものですが、そうなると数も膨大になり、また管理もすごくややこしくなってしまいます。

さらには、オープンソースの場合、「前のバージョンのソースほしいんだけど」なんて要望もされたり。もう大変！

SVNはこの問題の多くを解決してくれるものです。

例１

まず、オイラが「OSAKA Ver 4.7」というソフトを完成させました。この時点でのソースを公開したいとします。
SVNにソースを送信します。SVNはこれを受け取って記憶してくれます。この時、コメント及びリビジョン番号というものが自動的に付加されます。
- リビジョン番号はバージョン番号とは関係ありません。一回でも修正すれば番号が上がります。
Ver4.7は無事公開が済みました。オイラはVer4.7.1に向けてソースに手を入れ始めます。ソースはSVNのモノとは別のものになります。
修正が終わり、頃合を見計らって再びSVNに送信して記憶します。SVN内のソースはオイラの手元のものと同じに修正され、リビジョン番号も上がります。オイラは修正箇所が後から解るように、「Makefileの一部を修正」とコメントを打ち込んでおきます。
10回これを繰り返しました。ようやくバグが取れ、Ver4.7.1として発表できるようになりました。（リビジョン番号は11になっていました）

この時点で、まぁバイナリはちゃんとzipかなにかに圧縮してどこかにアップロードしますよね。もちろんソースもそうしてもいいのですが・・・

オイラは、「Ver 4.7.1のソースはSVNにあります。リビジョン11がそうです。」とだけ宣言すればそれでOKになります。ソースがほしい人はSVNのページにアクセスし、リビジョン11（あるいはこの時点での最新リビジョンと指定して）をダウンロードすれば、Ver 4.7.1のソースが手に入ります。

例2

例１のようなことを繰り返してゆきました。OSAKAはVer4.7.18までバージョンアップ。修正は小さいものも含め、数十回も行われ、リビジョンは85になっています。

ある人が、「悪いんだけど、Ver4.7.2のソースがほしいんだけど」と言ってきたとします。

普通なら、オイラはHDD内を探してソースを再圧縮し、どこかにアップロードしなくてはいけません。面倒だし、間違えてしまうなんてこともありえますよね。

しかし、SVNには歴代のソースの差分が全て記録されています。オイラがやることはひとつだけ。「Ver4.7.2の時点のソースは、リビジョン何番だっけ？」という調査だけです。手元になくても、ちゃんとSVNのコメントは残っていますのでそれを見れば解ります。

相手に、「わかりました。SVNの、リビジョン18がそうです。リビジョン18を指定してダウンロードしてください」と伝えればそれでOKとなります。

例3

リビジョン135の段階で、OSAKAはVer4.7.26になり、公開をしました。オイラは新バージョン、4.7.27に向けて再び修正を開始。

煮詰まってしまいました。リビジョン140の段階でどうしても解らなくなってしまい、コミュニティの猛者に助けを求めます。「xxxの所がどうしてもうまく動かない。誰か助けて！」

アドバイスをしてあげようという人が現れます。当然ですが、彼に、このまだうまく動かないソースを渡さないといけません。しかし、一回一回、圧縮して番号を振ってアップロード・・・こっちが面倒なだけではなく、相手も面倒。どこをどう直したのかもいちいち書かなくてはならず、お互いに煩雑になります。

オイラは彼に、「SVNの最新リビジョンです」とだけ伝えます。彼はSVNから「最新」を指定してダウンロードすれば、オイラと同じソースが入手できます。・・・見ると、問題点が見つかりました。Wikiや掲示板で、修正案を伝えてくれました。

オイラはアドバイスに従い、一部を修正。・・・しかし、別の部分との兼ね合いで、やはりまだ正常に動かないです。オイラは再び、その、修正したソースをSVNに送信します。そして彼に、「SVNに上げました」とだけ伝えます。彼も、特に難しいことをせず、「最新」を指定してダウンロードすれば丸々手にはいりますし、その時に「どこのファイルを修正したのか？」もわかります。

これが数十回繰り返され、ようやくバグが取れました。リビジョンは139になっていました。

オイラは「139がVer4.7.27のソースです」とだけ公言すればそれでOK。さらに、修正を始めます。

OSASK計画のSVNの実際

技術的な慣習

SVNはちょうどディレクトリのように階層的に場所を作ることができます。OSASK計画のSVNのトップはここです。

http://svn.osask.net/

OSASK
OSAKA
28GO
hijk

OSASK計画ではとりあえず、これら4つのソフトのソースをSVNに置いています。OSASKのディレクトリ？をクリックし、降りてみます。

tags
trunk

OSASKディレクトリ？には、さらに上記二つのディレクトリがあります。

trunk

（たぶん、「トランク」でしょう。）

trunkディレクトリは、通常、どんどん修正されたソースが放り込まれていく場所です。その意味では、もっとも新しい、最新のソースがある場所といえます。

当然、歴代のものも全部あることになります

28GOのソースをダウンロードしてみる

実際にやってみましょう。

まずは、http://svn.osask.net/ に行きます。OSASK計画のSVNのトップです。
「28GO」をクリックして、降りてみます。
あれれ？
28GOはさらに28GO_G、28GO_K、28GO_Pという3つにわかれています。とりあえず今回は、28GO_Kをクリックして降りてみてください。
trunk、tagsが出てきましたね。（branchesというのがありますが、これは無視してください）

リリースされたソースがほしい

trunkは上記の通り、最新と言えば聞こえはいいですが問題があることがあります。また、時には古いバージョンのソースがほしいこともありますね。

この場合はtagsに降りてみてください。

28GO_K_src_0030/
K_0031/
k_0032/

ほら。さらに、リリース名のディレクトリがあるでしょう？　ここに降りて「Download GNU tarball」をクリックすれば、該当バージョンのソースが手に入るというわけです。

特定のリビジョンのソースがほしい

なんらかの理由で、最新でもない。正式リリース版でもない。ある特定のリビジョンのソースがほしいとします。

例えば、オイラがリビジョン185でVer4.7.2を完成させたらしいが、どういう修正をしたのかが知りたいなんて場合。一個前の、リビジョン184がほしいなんてね

まず、trunkに降ります。

trunkに降りただけだと、最新のリビジョンの状態で表示されます。もしリビジョンが220になっていれば、220の状態のソースが表示されます。このまま「Download GNU tarball」をクリックしても、リビジョン220が落ちてくるだけですね。

上の方を見てください。「Sticky Revision:」というところがありますね。ここに、特定のリビジョン番号を入れてsetボタンを押すと、そのリビジョンの状態に切り替えることができます。

切り替わった後で「Download GNU tarball」を押せば、そのリビジョンのソースが落ちてくるというわけです。

Last-modified: 2010-02-08 (月) 00:00:00 (JST) (319d) by lina

rev	11	12	13	14	15	16	17	18	19	20
	Ver4.7.1完成！	修正	あれ？バグだ！	こうかなぁ。まだ直らない	直った！	だめだ直ってない！	やった！今度こそ直った！	Ver4.7.2完成！	修正	ちょっと試し。多分動かない

SVN :: OSASK計画