ラベル Subversion の投稿を表示しています。 すべての投稿を表示
ラベル Subversion の投稿を表示しています。 すべての投稿を表示

2009-10-07

Git リポジトリーを Subversion にリポジトリー追加 (Git-svn の応用)

Git で管理していたプロジェクトを、Google Codes (Subversion) にも突っ込んだ。面倒だったので、ちとメモ。

Git repository の作成

まずは Git repository の作成。lpaldb というプロジェクトを作る。

$ mkdir lpaldb
$ cd lpaldb
$ touch README
$ edit index.html
$ ...
$ git init
$ git add .
$ git commit -m 'first commit'
$ cd ..

Google Codes のレポジトリー

Google Codes の Hackathon 用リポジトリーは、複数のプロジェクトを次のやうに管理している。

/branches
/tags
/trunk
  /Hackathon-Title
  ...
  /gae20090411
  /gae200906
  /html5_20091003
/wiki

trunk 以下のハッカソンごとのプロジェクトを。更にその下の各人のプロジェクトを置く形式。

今回は、/trunk 以下の html5_20091003 の下に自分のプロジェクト lpaldb を突っ込む。

Git Svn

Git Svn を使うと、Git で Svn のリポジトリーを操作できる。

ただ、hackathon-jp はとても大きなリポジトリーなので、全てのリポジトリーをローカルに持って来るのは大変。必要なコードも一部だけなので、それは避けたい。

そこで、/trunk/html5_2009103 以下だけを取って来た。git svn clone に Trunk を指定する -T オプションを使う。

$ git svn clone https://hackathon-jp.googlecode.com/svn/trunk -T html5_20091003 html5

これで html5 というディレクトリーが出来る。

これにさっきの git repository を追加する。

$ cd html5
$ git fetch ../lpaldb master:lpaldb

lpaldb (git) を lpaldb branch として html5 に取り込み。

$ git checkout lpaldb
$ mkdir lpaldb
$ git mv html lpaldb
$ git mv README lpaldb
$ ...
$ git commit -m 'Move lpaldb source into lpaldb dir'

lpaldb branch をきれいにしたら、master ブランチに merge。その後、本家 svn repository へアップする。

$ git checkout master
$ git merge lpaldb
$ git svn dcommit

これでお終い。フゥ、一苦労。もっと楽な方法があったら教えて下さい。

2009-01-27

Git-svn 最初の一歩

Git から Subversion リポジトリーをいじれるという話なので、試してみた。

Svn リポジトリーと通信する時は git svn SUBCOMMAND を使い、ローカル・リポジトリーをいじる時は git の素のコマンドを使えるっぽい。

インストール

Ubuntu ならパッケージで一発インストール。

$ sudo apt-get install git-svn

使い方

help

まずはヘルプの表示方法。

$ man git-svn

もしくは

$ git help svn
checkout

git svn clonesvn checkout に相当する。使い方:

$ git svn clone URI

今回、Google Code にホスティングしている自分のプロジェクトを取って来た。

$ git svn clone https://texsymb.googlecode.com/svn/trunk/ texsymb --username masayuki.ataka

--username オプションも、ちゃんと使えるね。

ローカルで作業

ローカルで作業する分には、git のコマンドが使える。

$ git log
...                         # ログがズラズラと...
$ git branch
* master                    # Git のブランチが確認できる
$ git checkout -b test
Switched to a new branch "test"
$ git branch
  master
* test                      # test ブランチ作ってみた
$ gitk                      # gitk で開発の流れも GUI 化できる 

ファイルを編集したら、git add 後に git commit。ここら辺は、Git の普段の操作と変わんない。

$ cd texsymb
$ touch README
$ git add README                                   # New file を add して
$ git commit -m 'Add new file README'              # commit
Created commit a27bf67: Add new file README
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README
$ git log
commit a27bf67ef702ff983f99713f7d4d2812b3d3476e
Author: ataka <masayuki.ataka@gmail.com>
Date:   Tue Jan 27 05:08:01 2009 +0900

    Add new file README
...

git svn log を使うと、Subversion 形式のログを読める。

$ git svn log
------------------------------------------------------------------------
r8 | masayuki.ataka | 2007-02-08 19:22:13 +0900 (木, 08  2月 2007) | 2 lines

TeX-symb is now minor mode.

ただし、ローカルに git commit した分のログは読めないみたい。

リポジトリーに commit

git-svn dcommitsvn commit に相当する。

$ git svn dcommit

って、まだ試してない ^^; ローカルの git commit 分を一気にリポジトリーにコミットしてくれるらしい。

リポジトリーから update

リポジトリーの変更分を取って来る方法。

$ git svn rebase

こちらも、まだ試してない。

man を斜め読みした感じだと、git-pull (と git-merge) は開発ブランチが分岐してしまうので、よろしくないらしい。Svn リポジトリーに取り込むのが大変みたい。なので、git-rebase が良いのだとか。

ここら辺、Git の merge と rebase が分かってないので、勉強する必要あるなぁ。

Fetch

ちと git, git なお話。

git branch -r すると、git-svn というブランチにリモート・リポジトリーが保存されてるっぽい。

$ git branch -r
git-svn

git svn fetch コマンドで、リモートの変更を git-svn ブランチに取り込めるんじゃないかな?

$ git svn fetch

そうすれば、git svn rebase する前に、リモートでの変更分を確認できる (気がする)。後で試そう。

$ git log git-svn
$ git svn rebase -l

あとがき

これが使い込なせると、Google Code 上にある svn リポジトリーをいじれるようになるなぁ。すると、色々止まってたプロジェクトも再開できるかもしれない :p

2007-02-07

Subversion で Berkeley DB のエラー (とその対処)

Fedora Core 2 で管理している Subversion のリポジトリーを、Ubuntu 6.10 に移したところ、エラーが出て svn checkout が出来なかった。原因は、Berkeley DB のバージョンが違ったことにあるらしい。対処法をメモしておく。ちなみに、Fedora Core 2 の Subversion はバージョン 1.0.2。Ubuntu 6.10 は 1.4.3。

まずは、やったこととエラー・メッセージ。tex-symb というプロジェクトのリポジトリーをコピーした。

from.machine$ tar czvf tex-symb.tar.gz ~/repos/svn/tex-symb
from.machine$ scp tex-symb.tar.gz to.machine:~/
from.machine$ ssh to.machine
to.machine$ cd ~/repos/svn
to.machine$ tar xzvf tex-symb.tar.gz
to.machine$ cd ~/program/2007
to.machine$ svn checkout file:///home/ataka/repos/svn/tex-symb/trunk tex-symb
--- Error Message ---
DB_VERSION_MISMATCH: Database environment version mismatch
svn: bdb: Program version 4.3 doesn't match environment version
...

対処

Subversion の FAQ に答えが載ってた。

こちらを参考に。svnadmin recover を実行後 db/ ディレクトリー下の __db.00* ファイルを削除した。

$ svn recover ~/repos/svn/tex-symb/
$ rm ~/repos/svn/tex-symb/db/__db.00*

FAQ には「svnadmin list-unused-dblogs /path/to/repeository で表示されるログ・ファイルも削除する」と書いてあるけど、ぼくの環境ではログ・ファイルは一つも表示されなかった。

これで、古いレポジトリーも新しい環境で checkout できるようになった。

蛇足: Ubuntu への Subversion 1.4.3 のインストール

Ubuntu へ Subversion 1.4.3 をインストールする方法は、ひげぽんさんのサイトを参考にした。

2007-02-06

Subversion Quick Start

バージョン管理システムの Subversion を使い始めた。今まで、Bazaar やら darcs やら GNU Arch に手を出していたけれど、バージョン管理ホスティング・サービスの多くが Subversion ベースな状況を鑑み、潮時かなと観念した次第。

Subversion 公認のこちらのサイト (文献) を参考に勉強を始めてる。

クイック・スタート

とりあえず、今、tex-symb.el という単独のファイル (このファイルは今までバージョン管理はしていなかった) を Subversion で管理したい。新規のプロジェクト 作成の手順をメモしておく。

リポジトリの作成

~/svn/tex-symb を、tex-symb.el のリポジトリーにする。

$ mkdir ~/svn
$ svnadmin create ~/svn/tex-symb
インポート

/tmp に、とりあえず tex-symb/{branches,tags,trunk} の三つのディレクトリーを作り、trunk ディレクトリーに tex-symb.el をコピーする。複数のファイルがある場合も、全て trunk ディレクトリーにコピー。

そして、その /tmp/tex-symb 以下をリポジトリーにインポートする。

$ mkdir -p /tmp/tex-symb/branches/
$ mkdir -p /tmp/tex-symb/tags/
$ mkdir -p /tmp/tex-symb/trunk/
$ cp ~/tex-symb.el /tmp/tex-symb/trunk
$ svn import /tmp/tex-symb file:///home/ataka/svn/tex-symb -m 'initial import'
Adding         /tmp/tex-symb/trunk
Adding         /tmp/tex-symb/trunk/tex-symb.el
Adding         /tmp/tex-symb/branches
Adding         /tmp/tex-symb/tags

Committed revision 1.

trunk, branches, tags の三つのディレクトリーは、後でブランチを切ったり、タグを付けたりする時に使うらしい。

作業ディレクトリーの作成

ぼくは、プログラムの作業ディレクトリーを年ごとに分けている。つまり、~/program/2007/PROJECT という感じ。こうしておくと、古いプログラムを見なくて済む。ちょっとした Tips。

で、その ~/program/2007 以下に tex-symb を checkout する。

$ cd ~/program/2007/
$ svn checkout file:///home/ataka/svn/tex-symb/trunk tex-symb
A  tex-symb/tex-symb.el
Checked out revision 1.

checkout の時、file:///.../trunk まで含めること。

ファイルの追加とコミット

ChangeLog ファイルがないことに気付いたので、touch してリポジトリーに追加する。

$ touch ChangeLog
$ svn add ChangeLog
$ svn commit -m 'Add ChangeLog file'

ファイルを編集した時も、svn commit。

$ vi tex-symb.el
$ svn commit -m 'Edit foo'

コミットしたら、アップデートしてログを確認。

$ svn update
At revision 2.
$ svn log
------------------------------------------------------------------------
r2 | ataka | 2007-02-05 17:43:34 +0900 (Mon, 05 Feb 2007) | 1 line

Add ChangeLog file
------------------------------------------------------------------------
r1 | ataka | 2007-02-05 17:31:38 +0900 (Mon, 05 Feb 2007) | 1 line

initial import
------------------------------------------------------------------------

今日はここまで。

2006-06-14

Six Apart が MovableType の開発ソースを公開!

Six Apart は 2006-06-14 現在、同社の主力ブログ作成ツールである Movable Type の次期バージョン (3.3) のベータ・テストを行っている。Movable Type といえば、インストール型ブログ・ツールの雄。ユーザーは Perl で書かれたソース・コードをダウンロードし、公開用のウェブ・サーバーに Movable Type をアップロードして利用する。いわゆる Open Source 系のツールなだけあって、コアなユーザー (ブロガー) が多いのも特徴の一つ。

とはいえ、ユーザーが目にするのは、ベータ版若しくはリリース版のソース・コードだった。

Code repository

ところが、この度、Six Apart はベータ開発中のソース・コードを Subversion で公開すると決めた!

あのバグはいったいいつ直るんだとお嘆きのあなた。今度はどんな機能を実装してるんだと興味津々のあなた。私たちのコードリポジトリをのぞいてみてください。バグが直ってる!?さっそくsvn coしてmakeしてみてください。私たちのリズムを感じてください。

企業の開発するソフトウェアの開発現場を覗けるなんて滅多にないこと。ソフトウェア開発に興味を持っている人には郎報かと。もちろん、次のベータが待てない人にも、よい報せだね。

それにしても、開発中のコードじゃあ、(バグを修正したつもりで) 逆にバグを入れてしまうこともあるわけで、下手するとブログの記事を全部壊してしまう可能性もないわけじゃあない。そういう下手は打たないって自信と技術力があるからこそ、ベータとはいえ開発中のコードを公開できるんでせうね。Six Apart の勇気に拍手!