[この発想はなかった] 専任のSubversionオペレータなる人がいるらしく、受理された申請書と変更ファイル(を入れたUSBメモリ)をSubversionオペレータさんに手渡すと、あとはオペレータの人が代わりにコミットしてくれるみたいですよ。
今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page
[この発想はなかった] 専任のSubversionオペレータなる人がいるらしく、受理された申請書と変更ファイル(を入れたUSBメモリ)をSubversionオペレータさんに手渡すと、あとはオペレータの人が代わりにコミットしてくれるみたいですよ。
livedoor Developers Blog:Subversionで攻めの開発を (いまさらだけど) - livedoor Blog（ブログ）
こんにちは。ブログ担当のnabokov7です。 さてみなさん、ここのところ、livedoor Blog の新機能リリースのペースが上がっていることにお気づきでしょうか。 12月だけでこれだけの新規リリースのお知らせを出しました。 2007年12月27日 プライベートモードで記事を投稿できるようになりました 2007年12月25日 タグクラウド とタグ別ページを表示できるようになりました 2007年12月20日 カテゴリ別モブログ機能リリースのお知らせ 2007年12月18日 「話題のブログ」が新しくなりました 2007年12月18日 プレビュー機能強化と新リスログプラグインのお知らせ 2007年12月13日 投稿・編集を便利にするブックマークレットのご紹介 2007年12月11日 バリューコマースの商品をカンタンに紹介できるようになりました。 2007年12月11日 アップロードしたファイ
猿にもわかるsvn入門
はじめに repo='http://svn.momonga-linux.org/svn/pkgs' という shell 変数が定義されているものとして話を進めます. 割と頻繁に URI を打つ事があるので短かめの変数を定義しておくことを お勧めします. Q. 今のsvn repoって結局どうなのよ？ A. 以下のようになっています。(2006-08/15現在) 詳しくはここらへん参照 http://developer.momonga-linux.org/viewvc/ http://developer.momonga-linux.org/viewvc/branches/ 使う事が少ないtags以下は省略しています。 http://svn.momonga-linux.org/svn/pkgs / ┣ trunk/ ┃ ┣ pkgs/ 最先端のパッケージ。通常はこちらを使用すればok。 ┃ ┗
Subversionを見直せ - プログラマの思索
SW構成管理の概念の中心は、バージョン管理。 バージョン管理こそが我々SW開発に従事する者にとって、背骨であり血液に当たる最重要なインフラ。 デスマーチに陥るプロジェクトは、バージョン管理に何かしらの欠点や弱点がある。 おそらく殆どのSW開発では、Subversionをバージョン管理に使っているが、Subversionは実は数多くの機能を持ち、従来のプロジェクト管理を根本的に変える可能性を秘めている。 もう一度、Subversionの機能を見直してみた。 【1】ムービー企画「Subversionによるバージョン管理入門」 WEB+DB PRESS Vol.39誌面連動ムービー｜gihyo.jp … 技術評論社 最近のバージョン管理は、trunkとbranchの2系統のバージョン管理戦略を持つ傾向がある。 メインラインモデルと呼ばれる。 メインラインモデルの手法を使って、本番運用中の保守br
tDiaryのSubversionバックエンド - 2008-11-13 - ククログ
みなさんはtDiaryの日記データをどのようにバックアップしているのでしょうか。cronでアーカイブしていたり、dbi_ioでデータベースに保存して、データベースの内容をアーカイブしていたりしているのでしょうか。 開発者の人なら日記のデータもソースコードと同じようにバックアップしたいですよね。つまり、バージョン管理をして、レポジトリの内容をアーカイブするバックアップです。そんな人はこのようなSubversionIOはいかがでしょうか。保存する毎にSubversionリポジトリに日記データをコミットします。 require 'tdiary/defaultio' module TDiary class SubversionIO < DefaultIO def transaction( date, &block ) dirty = TDiaryBase::DIRTY_NONE result =
SubversionとTracでファイル管理の“迷宮”から脱出
SubversionとTracでファイル管理の“迷宮”から脱出：ユカイ、ツーカイ、カイハツ環境！（2）（1/4 ページ） プロジェクトで修正／仕様変更が“迷宮”入りする理由 ソフトウェア開発を行ううえで、設計書やソースコードのバージョンをきちんと管理することは非常に重要です。構成管理（ファイル管理）を行っていないプロジェクトでは、例えば次のような問題が発生します。 2人以上の開発者が同時に成果物を編集した場合、後に編集を始めた開発者がすでに編集を行った開発者の編集内容を上書きしてしまう。結果として、修正したはずのバグや変更したはずの仕様が、設計書やソースコードに反映漏れするという事態が発生 設計書やソースコードのレビューを行って修正したはいいが、どこをどう修正したのか分かりにくく、レビュー内容の反映の確認を行っても修正漏れや修正誤りに気が付かない ソースコードを変更すると、動かなくなってし
TortoiseSVNとITS・BTSの連携 - idesaku blog
前から「なんだこりゃ？」とは思っていたのだよ。 TortoiseSVNのプロパティ設定画面なのだが、選択可能なプロパティの中にbugtraq:url他、bugtraq:XXXという名称のものがある。これ、どう見てもバグトラッキングシステムとの連携用だよねぇ？ 気になったのでちょっと調べてみたのだが・・・あったよ。 http://www.caldron.jp/~nabetaro/svn/TortoiseSVN_ja/tsvn-dug-bugtracker.html へぇ！そんなことができるのか！Mantisもいることだし、ちょっくら試してみよう。 チェックアウトしてくるモジュールのルートディレクトリ（大抵、repourl/trunk/だろう）に、次のプロパティを設定する。 プロパティ名 値 bugtraq:url http://server/mantis/view.cgi?id=%BUGID
TortoiseSVNの差分機能は素晴らしい - プログラマの思索
TortoiseSVNの差分機能は、テキストだけでなく、WordやExcelも可能だと知って激しく感動した。 実際、WordやExcelの変更履歴機能が働いて、文字列で差分が発生した箇所は吹き出し又は赤色塗りされるようだ。 すばらしい！ 更に、下記ツールを使うと、PowerPointやpdfの差分も見れるようだ。 xdocdiff おかげで、SubversionでWordやExcelをバージョン管理することも苦痛にならなくなった。 むしろ、ソースと同様に仕様書も、積極的にバージョン管理できる。 しかも、RedmineやTracなどのBTSと連携すれば、SVNリビジョンとチケットを紐づけできるから、ソース修正と同じ方法で、仕様書そのものも修正理由を追跡できる。 ソースだけでなく、仕様書も、ビルドスクリプトも、ライブラリも、開発環境も全て、Subversionに入れてバージョン管理すれば、BT
10分で作る、Subversionレポジトリ - Unix的なアレ
バージョン管理システムにはCVSやsubversionなど様々なものがありますが、サーバーのセットアップに抵抗がある人もいるのではないでしょうか？ しかしながら実際のところ、パッケージ化されているので驚くほど簡単にできてしまいます。 今回は、もっとも簡単な手順でSubversionのレポジトリサーバーを構築する方法を紹介したいと思います。 動作環境 今回の手順の動作環境は下記のとおり。OSをインストールしたままの、まっさらな状態を想定しています。 OS Debian Linux etch Protocol http Web Server Apache2.2.3 それでは早速いきましょう。本当に10分間で構築できます。 パッケージのインストール 下記の作業はすべてrootで作業をするものとします。(まっさらな状態を想定しているため、sudoは利用していません。) それでは必要なパッケージをイ
Subversion1.5 - KoshigoeBLOG
何となく気になったので、変更点を眺めて試してみた。 subversion: Subversion 1.5 Release Notes svn mergeinfo "WebDAV Transparent Write-Through Proxy"は、楽しそうだけど使う機会がありそうでなさそうな。海外のレンタルサーバにリポジトリたててるような場合はいいんでしょうね。社内リポジトリにスレーブ用意しても、バックアップ目的以外でなにかいい事あるでしょうか。不可分散するほどに負荷はかかってませんし。意味なく個人用Tracを用意してみますかね。 なんとなく、「ローカルにコミット」という点で、分散バージョン管理を思い浮かべてしまいましたが、あくまでレプリケーションなので、意味合いが違いますよね。 FSFSのフォーマットが新しくなったというのは、そもそもFSFSを詳しく知らないので「ふーん」といった印象。ただ
をれをれ subversion リポジトリを作って外部のリポジトリを使いやすいように料理しよう！ - woremacxの日記
coderepos や lazy-people や vaginarepos といろんな subversion リポジトリにアカウントもらって、さらにはプライベートな subversion リポジトリがあったりすると、どこになにがあったのかさっぱりです。そんなときは、をれをれ subversion リポジトリを作って自分が使うものだけを集約すると、快適な生活を送れるかと思います。やり方はカンタンです！プライベートなリポジトリ( http://example.com/repos/private/ )を用意して、svn:externals をセットするだけです！ # checkout する $ svn co http://example.com/repos/private/ $ cd private # coderepos 用ディレクトリを作る $ svn mkdir coderepos $ s
branches を trunk に merge する前には必ず trunk の内容を branches へ merge する - Yappo::タワシ
想定外な事になるよ！っていう例をやってみた。 $ ls trunk/ foo.txt hoge.txt branches/a を作る $ svn copy trunk branches/a A branches/a $ svn ci Adding branches/a ファイルを色々変更する $ vim branches/a/foo.txt $ svn diff Index: branches/a/foo.txt =================================================================== --- branches/a/foo.txt (revision 2) +++ branches/a/foo.txt (working copy) @@ -1 +1,2 @@ fue +nikoniko $ svn ci Sending bran
リポジトリへのComitもれを防ぐ方法 - Hello, world! - s21g
複数人で開発している場合に、新しく作成したファイルを svn addし忘れて、Commitもれを発生させてしまうと、 テストが走らなかったり、開発を止めてしまったりと、 様々な悪影響が発生してしまいます。 今回は、Commitもれを防ぐために僕が使ってる方法を紹介します。 やってることは単純で、以下のalias設定を.zshrcに登録しています。 1 alias svn_new='svn stat | grep "^\?" | sed "s/\? *tmp.*//" | sed "s/\? *log.*//" | grep .' svn statの結果から、log/とtmp/ディレクトリの中身を除外してるだけですね。 あとは、svn_newコマンドを実行すれば、svn add し忘れてるファイルが無いかどうか簡単に確認できます。 しかし、実際にはconfig/database.ymlやt
過去のリビジョンを全て検索したい - yuumi3のお仕事日記
ある日気がついたら、ソースコードから 関数 XXXX がなくなっていた！ というような場合、いつどうしてその関数が無くなったのかを調べたいですよね。 Subversionに全ての過去のソースは格納されてますが、それに対する全文検索のような機能はなさそうです。 そこで、ある１つのソースコードの全リビジョンを取り出すプログラムを作ってみました。 #!/usr/bin/env ruby url = ARGV[0] logs = IO.readlines("|svn log #{url}").select {|s| s =~ /^r\d+ /} logs.reverse.each {|log| log =~ /^r(\d+) / rev = $1 STDERR.puts log puts '=' * 80 + "\n" puts log + "\n" puts IO.read("|svn cat
Subversion - higepon blog
Merging in Subversion is a complete disaster. The Subversion people kind of acknowledge this, and they have a plan, and their plan sucks too. It's incredible how stupid these people are. They've been looking at wrong problems all the time. Branching is not the issue. Merging is. この部分は確かにその通り。 Subversionは、マージのサポートがなさすぎてひどい。 追記 どこからどこまでがマージされたのか？というメタ情報がSubversionにはないのですよね。 なので、「以前どのブランチをどこの revisio
satolog: リーナス・トーバルズ「Subversion ほど無意味なプロジェクトはない」
Saturday, December 01, 2007 リーナス・トーバルズ「Subversion ほど無意味なプロジェクトはない」 Tech Talk: Linus Torvalds on git My hatred of CVS has meant that I see Subversion as being the most pointless project ever started. The slogan for Subversion for a while was "CVS done right" or something like that. And if you start with that kind of slogan, there is nowhere you can go. There is no way to do CVS right. ぼくの CVS への憎悪が
Subversionを使ってプロジェクトを破綻させるためのTIPS:Geekなぺーじ
「Subversion worst practices」というプレゼン資料がありました。 Subversionを使ってできる最悪のバージョン管理方法を解説しています。 Google社員によるOSCON(2007/7)でのプレゼンのようです。 笑えました。特にレポジトリ直編集あたりが何度か。。。(ry。 利用するバージョン管理システムについてひたすら言い争う 既存のスクリプトなどの存在を全て忘れて何が何でもSubversionへ移行する バックアップなんて気にしない、もしくは毎晩「svnadmin dump」 色々な言語のファイル名を混在させる 開発者は信用できない。Lockしまくる。無断で編集させない。コンフリクトを防ぐ。Lockしたまま旅行へ行く。ついでにsysadminも連れて行く バージョン管理システムを直接使わせずに、それを使うスクリプトを作って使わせる 全開発者に自前プランチを与
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
http://twitter.com/takano32/statuses/844499135
KoshigoeBLOG: SubversionのpropertyとTracのリポジトリブラウザ