SVNはSubversionという名のソフト(システム?)で、ソースコードの管理および公開・ダウンロードを助けてくれるものです。
OSASK計画ではSourceforge.jpが貸し出してくれているSVNを活用しています。
ソースコードはどんどん変更されていきますよね?。でも、逆に修正したらバグが出てしまったので前のものからやり直したいなんてこともよく起こります。歴代のソースはできるだけキチンと名前を付けて残しておきたいものですが、そうなると数も膨大になり、また管理もすごくややこしくなってしまいます。
さらには、オープンソースの場合、「前のバージョンのソースほしいんだけど」なんて要望もされたり。もう大変!
SVNはこの問題の多くを解決してくれるものです。
この時点で、まぁバイナリはちゃんとzipかなにかに圧縮してどこかにアップロードしますよね。もちろんソースもそうしてもいいのですが・・・
オイラは、「Ver 4.7.1のソースはSVNにあります。リビジョン11がそうです。」とだけ宣言すればそれでOKになります。ソースがほしい人はSVNのページにアクセスし、リビジョン11(あるいはこの時点での最新リビジョンと指定して)をダウンロードすれば、Ver 4.7.1のソースが手に入ります。
例1のようなことを繰り返してゆきました。OSAKAはVer4.7.18までバージョンアップ。修正は小さいものも含め、数十回も行われ、リビジョンは85になっています。
ある人が、「悪いんだけど、Ver4.7.2のソースがほしいんだけど」と言ってきたとします。
普通なら、オイラはHDD内を探してソースを再圧縮し、どこかにアップロードしなくてはいけません。面倒だし、間違えてしまうなんてこともありえますよね。
しかし、SVNには歴代のソースの差分が全て記録されています。オイラがやることはひとつだけ。「Ver4.7.2の時点のソースは、リビジョン何番だっけ?」という調査だけです。手元になくても、ちゃんとSVNのコメントは残っていますのでそれを見れば解ります。
相手に、「わかりました。SVNの、リビジョン18がそうです。リビジョン18を指定してダウンロードしてください」と伝えればそれでOKとなります。
リビジョン135の段階で、OSAKAはVer4.7.26になり、公開をしました。オイラは新バージョン、4.7.27に向けて再び修正を開始。
煮詰まってしまいました。リビジョン140の段階でどうしても解らなくなってしまい、コミュニティの猛者に助けを求めます。「xxxの所がどうしてもうまく動かない。誰か助けて!」
アドバイスをしてあげようという人が現れます。当然ですが、彼に、このまだうまく動かないソースを渡さないといけません。しかし、一回一回、圧縮して番号を振ってアップロード・・・こっちが面倒なだけではなく、相手も面倒。どこをどう直したのかもいちいち書かなくてはならず、お互いに煩雑になります。
オイラは彼に、「SVNの最新リビジョンです」とだけ伝えます。彼はSVNから「最新」を指定してダウンロードすれば、オイラと同じソースが入手できます。・・・見ると、問題点が見つかりました。Wikiや掲示板で、修正案を伝えてくれました。
オイラはアドバイスに従い、一部を修正。・・・しかし、別の部分との兼ね合いで、やはりまだ正常に動かないです。オイラは再び、その、修正したソースをSVNに送信します。そして彼に、「SVNに上げました」とだけ伝えます。彼も、特に難しいことをせず、「最新」を指定してダウンロードすれば丸々手にはいりますし、その時に「どこのファイルを修正したのか?」もわかります。
これが数十回繰り返され、ようやくバグが取れました。リビジョンは139になっていました。
オイラは「139がVer4.7.27のソースです」とだけ公言すればそれでOK。さらに、修正を始めます。
SVNはちょうどディレクトリのように階層的に場所を作ることができます。OSASK計画のSVNのトップはここです。
http://svn.osask.net/[2]
OSASK計画ではとりあえず、これら4つのソフトのソースをSVNに置いています。OSASKのディレクトリ?をクリックし、降りてみます。
OSASKディレクトリ?には、さらに上記二つのディレクトリがあります。
(たぶん、「トランク」でしょう。)
trunkディレクトリは、通常、どんどん修正されたソースが放り込まれていく場所です。その意味では、もっとも新しい、最新のソースがある場所といえます。
当然、歴代のものも全部あることになります
タグ。荷札や目印という意味でしょうか?
例3をみてみてください。最新のソースと言っても、それがちゃんとしたものとは限りません。まだ修正が完全ではなく、動かないということだってありえます。
たとえばこんな感じ。
rev | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 |
Ver4.7.1完成! | 修正 | あれ?バグだ! | こうかなぁ。まだ直らない | 直った! | だめだ直ってない! | やった!今度こそ直った! | Ver4.7.2完成! | 修正 | ちょっと試し。多分動かない |
この場合、一般の人が必要なのは、
という情報ですよね? でも、これをどこか別の場所に書いておいたりするってのも面倒だし、不便ですよね?
そこで、tags内に、「Ver4.7.1」なんてディレクトリを作り、そこにリビジョン11へのリンク?を作っておくのです。
こうしておけば、ただ単純に正式リリースのソースが一発でほしいという人は、tagsに降りてみればすぐにダウンロードが開始できるわけです。
実際にやってみましょう。
最新ですからtrunkに降ります。
もう一度言いますが、最新ということは作りかけやバグがあるとも言えるのでご注意を
ずらーっと並んだ画面が出てきたはずです。これが28GO_Kのファイル郡です。
横にある情報はなに???
さてダウンロードです。これらを一個一個ダウンロードする? いえいえ! まぁ別にそれでもいいのですが
一番下を見てください。「Download GNU tarball」というリンクがあるでしょう? これをクリックすると、今見えているファイルを全部自動的にtgzアーカイブに圧縮してダウンロードしてくれます。
このソフトの仕様で、圧縮形式は.tar.gz以外使えませんので、これに対応した解凍ソフトが必要になりますので別途ご用意ください。ちなみにオイラはLhaz[13]を愛用しています
trunkは上記の通り、最新と言えば聞こえはいいですが問題があることがあります。また、時には古いバージョンのソースがほしいこともありますね。
この場合はtagsに降りてみてください。
ほら。さらに、リリース名のディレクトリがあるでしょう? ここに降りて「Download GNU tarball」をクリックすれば、該当バージョンのソースが手に入るというわけです。
なんらかの理由で、最新でもない。正式リリース版でもない。ある特定のリビジョンのソースがほしいとします。
例えば、オイラがリビジョン185でVer4.7.2を完成させたらしいが、どういう修正をしたのかが知りたいなんて場合。一個前の、リビジョン184がほしいなんてね
まず、trunkに降ります。
trunkに降りただけだと、最新のリビジョンの状態で表示されます。もしリビジョンが220になっていれば、220の状態のソースが表示されます。このまま「Download GNU tarball」をクリックしても、リビジョン220が落ちてくるだけですね。
上の方を見てください。「Sticky Revision:」というところがありますね。ここに、特定のリビジョン番号を入れてsetボタンを押すと、そのリビジョンの状態に切り替えることができます。
切り替わった後で「Download GNU tarball」を押せば、そのリビジョンのソースが落ちてくるというわけです。
(This host) = http://osask.net