svn diff をカラフルに表示させるワンライナー - すぎゃーんメモ
Gitで、 [color] ui = autoの設定をしているとdiffしたときに追加部分が緑、削除部分が赤で表示されるようになっていて、結構気に入っていた。 けどSubversionではどうやるのかよく分からない。ので自分で書いてみた。 svn diff . | perl -pe 's/^([-+]).*$/"\e[".($1eq"+"?32:31)."m$&\e["/e' | less -R vimのlessを使うとよりカラフルなのが出るらしい。 svn diff . | /usr/share/vim/vim72/macros/less.shvimの色設定をしっかりしていれば下記のようにしてもいけるらしい。自分の環境ではダメだった。 svn diff . | vim -R 素直にcolordiffってのを使った方がラクかなぁ。 colordiff - REDIRECTING
Subversion 1.7が出たので、TortoiseSVN 1.7でWC-NGやってみた - Masa / Lino Blog
2，3日前にSubversion 1.7が出ました。新機能はHTTPv2などパフォーマンスに関する機能が多くて、やや地味な印象です。 Apache Subversion 1.7 Release Notes よく捕らえれば、Subversionは歴史も長いので、大きな変更はいらないということでしょう。 更に先のSubversion 1.8ではDVCSに影響されたような shelvingやcheckpointingのような機能も出るようですが。 Apache Subversion Roadmap 話がそれてしまいましたが、Subversion 1.7の新機能の中でも個人的に嬉しいのが、WC-NG(Working Copy Next Generation)です。WC-NGは作業コピーのメタデータ変更で、フォルダの中にたくさんあった.svnフォルダがルートフォルダだけに集約されます。 ルートフォル
札幌 Java カンファレンス 2011開催しました - やさしいデスマーチ
札幌 Java カンファレンス 2011 with TDD BootCamp 札幌サテライトを開催しました。最終的には、来場者数55名、事前キャンセル6名、ドタキャン1名となりました。スタッフや講師を除外しても50名以上が参加され、本当にありがとうございます。当日にはポストできませんでしたが、簡単にレポートをまとめておきます。 今回のイベントは、Java7のLaunchイベントの一環として札幌で何かできないか？という相談を寺田さん（@yosioterada）から頂いた事がキッカケです。そこで開催しなかったら、札幌Javaコミュニティを立ち上げた意味がありません。快諾し、日程を調整した結果、7月9日開催となりました。 ところが、TDD BootCamp東京も運悪くバッティング。実は参加を企んでいたのですが、未遂に終わります。しかし、各地でサテライト開催の企画があがっていたため、札幌も便乗する
svn＋TeXでcommitするとPDF - オーム社開発部の出版システムでの書籍執筆:Geekなぺーじ
以前、オーム社開発部の出版体制を取材しましたが、今回、私自身がそのシステムを使って本を書きました。 Subversionでバージョン管理をしつつLaTeXで本を書く形式です。 複数人で本を書く時にバージョン管理ツールを使わないと、誰がどこをどういじったのかがわからなくなったり編集箇所が競合する場合が多いのですが、Subversionを使うことでそれらが解決可能です。 さらに、筆者か編集者のうちの誰かがsvn commitを行って最新版を更新すると、それに連動して最終原稿として印刷所に入稿されるものと同じ形のPDFが自動的に生成され、DTP作業がゼロになるとともに、筆者がアウトプットを細かく確認ができるという特徴もあります。 しかも、Subversionのコミットメールを編集者側も見ていて、該当部分に対する編集やコメントがすぐに投入され、こちらが文章を書いた数分後に編集側意見が含まれるPDF
doublev - trac/SVN Rollback -
コミットしてはいけないファイルをSVNへコミットしてしまった場合、 Revertしても一度コミットした履歴は消えないので、ファイルの復元が可能です。 ファイルを復元させないために、コミットする前の状態に戻すには、 SVNサーバ側のデータベースを、コミットする前に戻す必要があります。 また、tracのリヴィジョン同期が必要です。 trac0.12/SVN1.6での作業方法を紹介します。 ※本方法により，いかなる損害が発生しても当方では責任は負いませんので、ご注意ください。
SVNからMercurialに移行するべき8つの理由
Git、Mercurial、Bazaarはオープンソースの分散バージョン管理システムで、どれも人気がある。特にGitとMercurialはもともとはLinux Kernelの開発のために作られた歴史からしても、ライバルと言える関係だ。LinuxやAndroid OSではGitが採用されたが、MercurialもOpenJDKやNetBeans、Xen、Python等で採用されている。 SVNから分散バージョン管理システムに移行を検討している所は多い。日本だと濱野氏がGitのメンテナをやっているせいかGitに人気が集中しているようだ。しかし気軽に分散バージョン管理システムを導入したいソフトウェア開発チームには、あえてMercurialを勧めたい。 1. SVNからMercurialに移行するべき8つの理由 取り扱いが楽で、今すぐ移行できる事がMercurialを導入するべき理由だが、もう少し
post-commitを利用して自動的にレビューリクエストを作成する - スコトプリゴニエフスク通信
Subversionのpost-commitフックを利用してReview Boardのレビューリクエストを自動的に作成する。 #!/bin/sh # /var/lib/svn/myrepository/hooks/post-commit export LANG="en_US.UTF-8" REPOS="$1" REV="$2" REVPREV=`expr $REV - 1` svnauthor=`svnlook author $REPOS rev $REV` svnlog=`svnlook log $REPOS rev $REV` svnlogfirst=`echo $svnlog | head -n1` /usr/bin/svn diff -r $REVPREV:$REV file:///var/lib/svn/myrepository | /usr/bin/post-review \
ReviewBoardでプレコミットレビュー - プログラマの思索
岡本さんがReviewBoardの素晴らしい記事を掲載されていたのでメモ。 【元ネタ】 Review Board | Take the pain out of code review Review Boardならコードレビューを効率良くできる！ (1/3) - ＠IT InfoQ: Review Board - コードレビューをオンラインで ReviewBoard 釣られて使ってみた | tsuyuki.makoto Rietveldでレビューしよう @ val it: α → α = fun 徒然さめざめ Redmine Hack! reviewboardとの連携 ReviewBoardのインストール方法: プログラマの思索 ReviewBoard 釣られて使ってみた | tsuyuki.makotoには下記のように説明されている。 (前略) Tracのような感じなのかと思っていたけれど
Subversionのシステム構成を考えてみた
全社的にSubversionを使えないか調べているんだけど、その構成に関する資料はとても少ない。 SVN1.5だとエンタープライズ環境におけるSubversionの複製アーキテクチャ by japan.internet.com デベロッパーとかSubversionを見直せ by プログラマの思索さんがとても詳しい。 そこで、Subversionのシステム構成をまとめてみた。いきなり「WebDAV Transparent Write-Through Proxyっすよ！」とMTGで提案するのも何なので、まずは整理。 単一サーバの場合 これは簡単。WindowsならばAll-in-one Tracとか使えばすぐ環境ができる。 昔の職場では、自分のPCに入れて使っていたのでこの構成になる。 いいところ ・シンプル ・小さいプロジェクトとかならこれで十分 悪いところ ・リポジトリが壊れるとバックアッ
Subversionリポジトリのバックアップ方法いろいろ - ぱせらんメモ
Subversionリポジトリのバックアップ方法が色々ありすぎて何がベストなのかわからなかったので調べてまとめてみた。 ただのファイルコピー 普通にファイルシステム上でディレクトリをコピー（あるいはアーカイブ）する方法。非推奨。 誰かがリポジトリにアクセスしている最中にやると壊す可能性がある。 リポジトリディレクトリをコピーしたいならsvnadmin hotcopyを使うべき。 長所 簡単。 速い。 短所 バックアップデータの可搬性に乏しい（アーキテクチャ依存）。 リポジトリをロックしないので壊す可能性がある。 データエラーが検出できない。 svnadmin dump/load svnadminのdumpとloadを使う方法。 誰かがアクセス中でも一貫性が保たれる。 あくまで管理対象のファイルのみのバックアップなので、設定やフックなどは別途バックアップが必要となる。忘れがち。 差分バックア
SI業界人は要チェック！！Subversionでのベンダブランチの運用手順。
外部から納品物に自分たちが手を入れるような場合や、他の人が作ったパッケージ製品を改造して提供するような仕事を管理する場合に使えるパターンです。つまり、SI業界には必須ともいえるパターンなはず。 レポジトリにvendorディレクトリを切っておき、その下でベンダから受領したブツを管理する。納品毎にバージョンtagをつける。そこから枝分かれさせたものを、自分のプロジェクトのサブディレクトリとして管理していく。こうやって管理することで、ベンダからの受領物を自分のプロジェクトにマージするときに、SVN力をいかんなく発揮させることができます。 参考：http://hide.xsv.info/tips/svnmanual/merge3/ 今更な人には今更だろうけど、今更じゃない人には今更じゃないよっていうのがこのセカイですので、もう気にしてません。サンタさん、僕はオトナになったよ…。 レポジトリの構成（
プログラマの思索: Subversionのブランチを有効活用してアジャイルに開発せよ
デブサミ2008講演資料の「SubversionとMaven 2 による構成管理」を読んで、改めてソフトウェア開発ではソース管理が最重要であると再認識した。 ソース管理について振り返ってみる。 【1】ソース管理の歴史 ソフトウェア開発では、ソース管理が必須だ。 ソース管理の本質は、履歴を辿って、いつでもソースをUndo、Redoできること。 昔のコンピュータ資源が希少な時、そもそもプログラムを履歴に残すことすらできなかっただろう。 今でもリリース時によくやるように、システム一式を複製して日付でリネームしていた。 僕は当初、ソース管理に、MSのVisualSourceSafeを使っていた。 CVSよりも直感的でGUIが使いやすい。 VSSを使い始めてから、下記の作業がルーチンになった。 朝、出社後、VSSから最新ソースを落として、VisualAgeForJavaのワークスペースにインポートす
リビジョン管理システムを使える技術者はイケテいる - 檜山正幸のキマイラ飼育記 (はてなBlog)
ある程度の経験を積んだ技術者／プログラマであるかどうかを判断したいとき、「リビジョン管理システムを普通に使えるかどうか？」という基準はけっこう有効な気がした。 以下の使い方は、「使ってみれば便利さが分かるから」とか言ってなんら説明をしなかった僕の責任です -- と前置きしますが： proj/2009-10-23/, proj/2009-11-10/ なんてディレクトリが、リビジョン管理下になっている。 同じことだが、foo.c, foo-v2.c, foo-v3.c なんてファイルがある。 リポジトリのワーキングコピーとは別に、“ほんと”のワーキングディレクトリがあり、ほんとのワーキングディレクトリから一端リビジョン管理下ワーキングディレクトリにファイルコピーしてからコミットしている。 複数人参加単一プロジェクトのディレクトリ構成が、proj/tanaka/, proj/suzuki/,
ベンダブランチの管理方法 - miauのブログ
サードパーティ製のコード（たとえば CakePHP）をプロジェクトのリポジトリに取り込んで使うような場合、バージョンアップが結構手間になります。バージョンアップの度に増減したファイルを svn add や svn delete するのは面倒ですし、ファイル名の変更をちゃんとトレースしたいなら svn rename もやりたくなるでしょう。また、CakePHP のソース自体に手を加えたいような場合、マージ作業も面倒になります。 こういう場合ベンダブランチや svn_load_dirs.pl というスクリプトを使うと、比較的楽に管理できます。svnbook でも ベンダブランチ - 第4章 ブランチとマージ - Subversion によるバージョン管理 という感じで軽く触れられているのですが、どうも利用している方が少ない気がするので、CakePHP を例にシナリオベースで利用方法を書いてみま
開発実績の調査に「statsvn」を使う | 小豆私論。
二十一世紀にもなり、構造化プログラミングだ！という声は、オブジェクト指向だ！に切り替わり…そういえばアスペクト指向はどうなったんだろうと思いをはせる昨今、いかがお過ごしでしょうか。 最近は、開発プロセスの見直しも叫ばれておりますが、まだまだ現場では「KLOC! KLOC! KLOC!」と言われますね。 （注：KLOCというのは、 kilo line of code。つまりは「1000行あたりのコード」のことです） 最初から計測するつもりでいれば、対策もできるのですが世の中、何事も後で言われます。 たとえば突然 BOSS がこんなこと言いませんか？ いつ頃コード量が大幅に増えたのか？ 作業者あたりの作業量は？ 週あたりの平均は？ 運良く私は言われたことがありませんが（笑）、Subversionを使用していれば大丈夫。 「StatSVN」というツールがあります。 http://www
Subversion
バージョン管理ツールSubversionの基礎練習です。 Windows XPのコマンドプロンプトでSubversionの基本的なコマンドを動かしていきます。 Subversionを学び始めるきっかけにどうぞ。 目次 はじめに ダウンロードとインストール リポジトリ用のディレクトリを作ります リポジトリを初期化します 新しいモジュールを作ってインポートします チェックアウトして作業開始 新しいファイルを追加します 新しいディレクトリを追加します 普段の作業はこんな風に進みます ファイル名を変更してみよう この文書に書かなかったこと 関連リンク 更新履歴 ぜひ、感想をお送りください はじめに Windows XPのコマンドプロンプトで、 バージョン管理ツールSubversionの基本的なコマンドを動かしてみましょう。 この文書の通りに実行すると、 基本的なSubversionのコマンドをひと
はじめての CodeRepos - いけむランド
どうも検索でひっかかる CodeRepos の記事は読み手が Subversion とか Git の基礎知識を持っていることを前提で書かれているので、まともにそれらを触ったことがない自分は登録だけでも一苦労だった。 以前から Ruby の勉強でぼちぼち書いていた yabcel *1 がとりあえずクラスファイルの逆アセンブルくらいはできるようになったので、これを機に CodeRepos に登録してみた。 http://svn.coderepos.org/share/lang/ruby/yabcel/ 以下、はじめて Subversion を触る人がソースを登録するまでの手順をまとめる。 ディレクトリ作成 ソースを置くためのルートとなるディレクトリを作成する。svn import しないといけないのかと思っていたが、どうやら svn mkdir で良いらしい。 coderepos なら、svn
MOONGIFT: » Mac OSX向けの洗練されたSubversionフロントエンド「Versions」:オープンソースを毎日紹介
開発時にバージョン管理システムを導入することによるメリットは言うに及ばないが、それはプログラマのみならずデザイナーにとっても同様だ。だが、バージョン管理をデザイナーまで普及させるのは非常に困難だ。 メイン画面 やはりインタフェースが鍵を握っている。使い勝手の良い、分かりやすいインタフェースのバージョン管理システムがあれば利用してくれる可能性はありそうだ。 今回紹介するフリーウェアはVersions、Mac OSX向けのSubversionフロントエンドだ。 Versionsは既存のワーキングコピーも簡単に登録でき、HTTP/SSH/SVNプロトコルに対応してリポジトリを登録することができる。何よりファイルの一覧やログの閲覧などが分かりやすいインタフェースでできる点が便利だ。 比較の確認画面 また、ファイルを選択してDiffを表示したり（DiffはFileMergeを利用）、履歴をするのがボ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Code Archive - Long-term storage for Google Code Project Hosting.
Subversion によるバージョン管理