SVN のソース :: OSASK計画

• 差分^[1] を表示
• SVN^[2] へ行く。

*なんですかそれは？ [#xabf8116]

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

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

http://svn.osask.net/

*簡単な説明 [#r9f60140]
ソースコードはどんどん変更されていきますよね？。でも、逆に修正したらバグが出てしまったので前のものからやり直したいなんてこともよく起こります。歴代のソースはできるだけキチンと名前を付けて残しておきたいものですが、そうなると数も膨大になり、また管理もすごくややこしくなってしまいます。~
COLOR(blue){さらには、オープンソースの場合、「前のバージョンのソースほしいんだけど」なんて要望もされたり。もう大変！}

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

**例１ [#c76b66c7]
-まず、オイラが「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 [#r5eb9bd7]
例１のようなことを繰り返してゆきました。OSAKAはVer4.7.18までバージョンアップ。修正は小さいものも含め、数十回も行われ、リビジョンは85になっています。

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

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

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

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

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

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

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

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

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

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

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


*OSASK計画のSVNの実際 [#re9b264d]
**技術的な慣習 [#of3c8a32]
SVNはちょうどディレクトリのように階層的に場所を作ることができます。OSASK計画のSVNのトップはここです。~
http://svn.osask.net/
-OSASK
-OSAKA
-28GO
-hijk

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

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

***trunk [#gacbd207]
（たぶん、「トランク」でしょう。）~
trunkディレクトリは、通常、どんどん修正されたソースが放り込まれていく場所です。その意味では、''もっとも新しい、最新のソースがある場所''といえます。

COLOR(blue){当然、歴代のものも全部あることになります}

***tags [#gae2e801]
タグ。荷札や目印という意味でしょうか？

例3をみてみてください。最新のソースと言っても、それがちゃんとしたものとは限りません。まだ修正が完全ではなく、動かないということだってありえます。

たとえばこんな感じ。

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

この場合、一般の人が必要なのは、
-Ver4.7.1のソースはリビジョン11である
-Ver4.7.2のソースはリビジョン18である

という情報ですよね？　でも、これをどこか別の場所に書いておいたりするってのも面倒だし、不便ですよね？

そこで、tags内に、「Ver4.7.1」なんてディレクトリを作り、そこにリビジョン11へのリンク？を作っておくのです。~
こうしておけば、ただ単純に正式リリースのソースが一発でほしいという人は、tagsに降りてみればすぐにダウンロードが開始できるわけです。


**28GOのソースをダウンロードしてみる [#b1927de7]
実際にやってみましょう。

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

**最新のものをダウンロードしてみる [#pb15bbae]
最新ですからtrunkに降ります。~
COLOR(red){もう一度言いますが、最新ということは作りかけやバグがあるとも言えるのでご注意を}

ずらーっと並んだ画面が出てきたはずです。これが28GO_Kのファイル郡です。

横にある情報はなに？？？
-''Rev.''
--リビジョン番号です。おや？ばらつきがありますね？。リビジョンは修正されるごとに上がります。沢山のファイルがあるソースの場合、全部が全部修正されるわけではありません。あるファイルはもうずぅっと修正されていないなんてこともあります。なので、「readme.txt はリビジョン152で最新。つい最近修正された」とか、「memo.txtはリビジョン18。18の頃からずっと修正がされていない」なんてのが解るわけです。
-''Age''
--世代です。大まかに、そのファイルが最後に修正されてからどのくらい時間が経っているのか解るようになっています。
-''Author''
--送信者といったところでしょうか。複数の人で修正等を行っている場合に、そのファイルを修正し、送信したのが誰かという情報です。（OSASK計画では事実上、hideyosiだけが行っている形になっています)
-''Last log entry''
--リビジョン番号と連動したコメントです。そのリビジョンになる（新しく修正され、送信された）場合に、送信者がコメントをつけておくのですが、そのコメントです。

さてダウンロードです。これらを一個一個ダウンロードする？　いえいえ！　COLOR(blue){まぁ別にそれでもいいのですが}

一番下を見てください。「Download GNU tarball」というリンクがあるでしょう？　これをクリックすると、今見えているファイルを全部自動的にtgzアーカイブに圧縮してダウンロードしてくれます。

COLOR(blue){このソフトの仕様で、圧縮形式は.tar.gz以外使えませんので、これに対応した解凍ソフトが必要になりますので別途ご用意ください。ちなみにオイラは[[Lhaz>http://www.chitora.jp/lhaz.html]]を愛用しています}

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

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

-28GO_K_src_0030/
-K_0031/
-k_0032/

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


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

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

まず、trunkに降ります。

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

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

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

• SVN のバックアップ一覧^[4]
• SVN のバックアップソース(No. All)
  • 1: 2010-02-04 (木) 11:01:11^[5] lina^[6]
  • 2: 2010-02-04 (木) 13:49:12^[7] lina^[6]
  • 現: 2024-01-08 (月) 12:58:51 lina^[6]