スタンダードプランでもsubversionがインストールできるようなので早速やってみる。 インストール手順は以下を参照させていただいた。 http://yabu3.blog76.fc2.com/blog-entry-421.html %cd ~ %mkdir src %mkdir src/subversion %cd src/subversion/ %wget http://ftp.jaist.ac.jp/pub/apache/subversion/subversion-1.7.8.tar.gz %tar xzvf subversion-1.7.8.tar.gz %cd subversion-1.7.8 %./get-deps.sh %./configure --prefix=$HOME/local --with-ssl --without-berkeley-db %vi Makefile
さくらのレンタルサーバ（スタンダード以上）にSubversionをインストールする手順。 すでにあちこちで皆さんが公開してるんですが、自分用の作業メモと投稿時点での最新情報という事で公開します。 本手順ではsvnserve + SSHで接続します。 さくらのレンタルサーバではSSH接続できるのは管理ユーザ（申請時の代表アカウント）だけです。 なので、この手順で「Subversionでソースを共有できるのは管理ユーザのユーザIDとパスワードを知っている人だけ」になります。 複数人数でソース共有をしたい場合はこの点に注意してください。 サーバにSSHでログインし以下のコマンドを実行します。 最新バージョンはApache Subversionで確認してください。投稿時点の最新バージョンは1.6.17でした。 %mkdir ~/local %mkdir -p ~/src/subversion %
社内プロジェクトをSVNからGitLab上で管理されているgitリポジトリに移行してみましたのでその手順をまとめてみます。 まずSVNのワーキングディレクトリで下記を実行します。 $ svn log --xml | grep "<author" | sort -u | perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt 最近のMacではgrep -Pオプションがなくなったらしいので、Gitへの移行の手順から若干アレンジしています。そうしたらusers.txtにSVNにコミットしたユーザの一覧ができるので、名前とメールアドレスを設定していきます。
う〜ん、困った。 あるコミットはUTF-8、またあるコミットはEUC-JPでログを書くなんて…。 修正しようにも $ git rebase -iでは文字化けてしてまってうまくいかない。 ちょっと大げさかもしれないけど、次の方法で修正する。 既存コミットのパッチに書き出す 第1引数にはパッチを作成し始めるコミットを指定する。 今回はすべて書き出すのでmasterを指定。 $ git format-patch masterコマンドを実行するとその場にパッチを作成しようとするので要注意。 patchesなど適当なディレクトリに移動しておくべし。 問題のパッチを修正 さて、以下のようなパッチファイルができた。 $ ls -1 0001-FIXME-xxx-xxx-xxx.patch 0002-FIXME-xxx-xxx-xxx.patch 0003-FIXME-xxx-xxx-xxx.patch
subversionのリポジトリをgitに変換はよくあると思うが、gitのリポジトリをSubversionに変換というのを今回やりたい。 というのも、何度もいっているが、中央には、Subversionで、各ワークをgitで私は使いたいからだ。 （これは、Tracとはviewvcとか、すでに構築してしまった環境を変えるのも面倒というのもある。） しかし、今回はとりあえず、ネットにつながっていない環境で初めてしまったgitのリポジトリをSubversionに変換して、 再度、git-svnで再開したいのだ。 こんな用途を持っている人はあまりいないのか、WEBで方法を探したがすぐには見つからなかったので、 自分なりに、次のような手順でログ情報だけでも取り込むことにした。 Subversionのリポジトリを作成 ここでは、Subversionでのリポジトリを作成する方法は述べない。 で、s
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
差分を作る 作業ディレクトリで、以下を実行する。 $ svn diff -r 10:HEAD > foo.diff patchをあてる $ patch -p0 -E < foo.diff -E オプションを指定すると、パッチ適用後に空のファイルを削除する。 また、patchが当たるファイルを確認したい場合は、--dry-runオプションをつける。 patch -p0 --dry-run < foo.diff このとき、ファイルにpatchは適用されない。 あてたpatchを取り消す -Rオプションで、一応可能。 $ patch -p0 -R < foo.diff 元々-Rオプションは、差分の取り方が逆であったときに利用するオプション。 結果的に取り消すことができるが、そのような目的のオプションではないので、過信しないこと。
このような FAQ の問題点は、文字通り FAQ でも何でもないというところ です。技術サポートに電話をして「どうやったら生産性が最大になる のでしょうか?」などと聞く人は一人もいないのです。そうではなく、 本当はもっとずっと具体的な質問がしたいのです、たとえば「どうやったら カレンダーシステムを変更して一日前でなく、二日前に通知するように できますか?」のような。しかし本当の問題点を明らかにするより、 仮想的な FAQ を作るほうがずっとやさしいのです。本当の FAQ を作るには 忍耐強い、組織的な努力が必要なのです: ソフトウェアの一生を通じて やってくる問いを追いかけ、それに対する答えを見守り、それらすべてを 集めて経験の浅いユーザの集約的な経験を反映するように検索可能な形に まとめる必要があります。それは忍耐が必要で、自然主義者のように物事 を黙って観察する態度が必要になります。こ
分散SCMを使いたい！と思う今日この頃。 仕事ではSVN（Subversion）を使っているのだが、ちょっとしたお試し編集をするためにブランチを作ることに抵抗がある。ブランチは欲しい、大きめな変更をコミット無しで行いたくない、やはり少しずつコミットして進めていきたい。しかし、変更が全て記録されてしまうのがいただけない。ログが残るのは良いことなのだが、本当に使うかどうか未知数な実験的プログラミングのログまで残したくない。使うと決まってから初めて残すようにしたいのだ。 すまん、これまで一緒に仕事をしてきた人々よ。俺はこれまで「ログが残って困ることがなんかある？いらなきゃ無視すればいいだけなんだから、気にするな。ブランチでもなんでもバンバン作ってしまえ！」とうそぶいてきているわけだが…ハッタリかましてました！本当は俺も抵抗があるのだ。 そこで、分散SCMだ。さらにいうと、SVKがいまひとつ気に入
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く