募集頁：http://kokucheese.com/event/index/6329/ ハッシュタグ： #shibutra 2010年12月17日(金) (19:00-22:00 (開場18:45)) 開催場所 古石場文化センター ２階 第１，２研修室 (東京都江東区古石場2-13-2) 続きを読む
2010/12/17分散バージョン管理勉強会
募集頁：http://kokucheese.com/event/index/6329/ ハッシュタグ： #shibutra 2010年12月17日(金) (19:00-22:00 (開場18:45)) 開催場所 古石場文化センター ２階 第１，２研修室 (東京都江東区古石場2-13-2) 続きを読む
A successful Git branching model - プログラマの思索
Gitの使い方について良い記事があったのでメモ。 【元ネタ】 見えないチカラ: A successful Git branching model を翻訳しました 少人数開発に役立つ5つのまとめ 構成管理について良い本は、「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」と「入門Git」の2冊。 これらの本を読んで理解した立場から書いてみる。 GitやMercurialのような分散バージョン管理では、ブランチをたくさん作るのが普通。 ブランチの目的を意識して、ブランチを管理するのが重要。 上記の記事では、メインブランチ、フィーチャーブランチ、リリースブランチ、ホットフィックスブランチの4種類が紹介されている。 僕の理解では、記事に書かれているメインブランチはtrunk、フィーチャーブランチはトピックブランチ、リリースブランチはまさ
statSVNで開発の状況を可視化する
みなさんこんにちは。@ryuzeeです。 先日何人かに聞かれたので書くことにします。 うちはPHPでの開発が多いので、色々なオープンソースなツールを組み合わせて自動化に組み込んでいますが、Javaな人はSonarを使うとよいかもしれません。 statSVNって何？http://www.statsvn.org/にある通りで、Subversionのログを利用して以下のような分析をしてくれる。 ソースコードの行数推移開発者ごとのソースコード行数時間別のアクティビィティ分析開発者毎のアクティビィティ分析モジュール毎のアクティビィティ分析ディレクトリ毎の状況ファイル数や平均ファイルサイズ、巨大ファイル変更回数の多いファイルの分析コミットログの時系列での整形出力などなど インストール簡単です。 http://sourceforge.net/projects/statsvn/にアクセスし、statsvn
TortoiseHg＋hgsubversionの導入方法 - プログラマの思索
TortoiseHg＋hgsubversionの導入方法の記事があったのでメモ。 【元ネタ】 hgsubversionの導入 - 文殊堂 Gitはgit-svnという優れたツールがあるが、Mercurialはhgsubversionを使うといい。 但し、結構はまる。 上記の方法を試すと良いと思う。 git-svnやhgsubversionの利点は、中央集権SCMであるSVNをあたかも分散バージョン管理のリポジトリかのように扱えること。 マスターリポジトリはSVN、開発者のプライベートブランチはGitやMercurialと使い分けて、trunkから派生させて機能追加して実験したり、トピックブランチ上でパッチを作ったり、色々試せる。 特に、修正の順序とリリースの順序が異なる障害修正のパッチを従来よりも楽にコントロールできるのはよい。 Mercurial以前と以後のチケット駆動開発: プログラマ
サーバにあるファイルをコピーしてSubversionにコミットするスクリプト - タイトルは未定
だめ出しされるのを期待して(?)公開します。目的ファイルサーバを使って、原始的な方法*1で管理されてるファイルをこっそりSubversion（以降SVN）に取り込みたい。将来的に、SVNに移行できたらいいなという思いがあるので。 前提SVNへのインポートは事前に行っているチェックアウトも事前にローカルHDDに行っている 仕様ファイルサーバからローカルのワークディレクトリへ同期を行う ディレクトリが存在しない場合は作成ファイルが存在しない場合はコピーファイルサーバの方が日付が新しい場合は上書きコピー.svnファイルはもちろん削除対象外とする同期しないファイル、ディレクトリを指定できるようにするローカルにのみ存在するファイル・ディレクトリを削除 .svnファイルはもちろん削除対象外とするSVNへの追加、削除 新しいファイルをsvn add削除されたファイルをsvn deleteSVNへコミット
SVNリポジトリのバックアップを取得したい - 履歴
タグやブランチを作成するわけでもなく、ただ単純に現在のリポジトリを保存しておきたいといったニーズは 結構あるようで、こういった場合にどうするのかといえば、dumpを取得し、別名のリポジトリを作成した後 にdumpをロードといった手順になります。 svnadmin dump E:\TracLight\projects\svn\SampleProject > F:\temp\sample.dump svnadmin create E:\TracLight\projects\svn\SampleProject2 svnadmin load E:\TracLight\projects\svn\SampleProject2 < F:\temp\sample.dump 上のsvnadmin createはロード前にやっておけばよいので、真ん中に挟む必要性はありません。 私の環境ですと、dumpよりもl
SVNコミット時にコメントを必須にしたい - 履歴
あるプロジェクトのリーダから、「SVNへのコミット時にコメントを必須にしたいのだけど...」と相談を受けました。 「ああ、あれね。」ということで、早とちりをして、以下の設定を行いました。 以下の設定では、TracLightningをEドライブにインストールしてある前提で、 Subversionのフックスクリプトを設置 E:\TracLight\projects\svn\<プロジェクト名>\hooks\post-commit.batを別名コピー（pre-commit.bat）します 実行ファイルの作成 E:\TracLight\bin\pre-commit.shを作成 以下、pre-commit.bat SET TRAC_LIGHT_HOME=e:\TracLight if not DEFINED TL_PROJECT_HOME set TL_PROJECT_HOME=%TRAC_LIGHT
SVNで，コミット時にログの入力を強制する （Windows版subversionのサーバ側フックスクリプトの作成方法） - 主に言語とシステム開発に関して
バッチのまとめTOPへ SVNで，コミット時にコメントの入力を強制する方法。 想定するSVNの構成： サーバ側：WindowsでSubversionを使っている。 クライアント側：WindowsでTortoise SVN を使っている。 より良いライブラリ管理のために。 応用すれば，コミット時に色々な制約を設けることができる。（ルール違反のコミットを防止できる） スクリプト作成 まず，ＳＶＮコミットをサーバ側でフックするスクリプトを作成 pre-commit.bat （C:\TracLight\projects\svn\<プロジェクト名>\hooks\ 内などに保存） rem 条件を満たさないコミットをはじくためのスクリプト rem subversionから渡される引数を格納 set REPOS=%1 set TXN=%2 rem コミットしようとしているトランザクションを検証 cscri
ネットワークがつながらない状況での分散開発はどうやるのがいいのか - wyukawa's diary
ネットワークがつながらない状況での分散開発はどうやるのがいいかを考えてみる。 以前似たような経験したのは自分たちが複数の協力会社の１つという立場で、元請けのSVNリポジトリに直接コミットするというもの。ネットワークはつながっています。また元請けは基本的に開発はしておらず、協力会社も開発はほとんど終わっていて変更はバグ修正のみという状況です。 イメージはこんな感じ。 リリース（元請けのSVNリポジトリに直接コミット）する場合は、自分たちのSVNリポジトリにタグうってexportして、あらかじめチェックアウトしておいた元請けのSVNリポジトリのソースに上書きしてコミットします。この辺もHudsonで自動化してましたね。あとコミットするファイル一覧も出しました。元請けはそれと実際にコミットされたソースとを比較して漏れが無いか確認してたみたいです。 しかしこの方法だとファイルの削除やリネームに対応
HgSubversion試してみた - wyukawa's diary
夏休み突入しました。周りでは突入出来てない人もいるけど。。。--); ネットワークがつながらない状況での分散開発をマジにやりそうなので、それにそなえてHgSubversionを調べてみました。 開発者はSVNしか意識しないで、構成管理担当者がcloneして差分をbundleファイルでやりとりするのをイメージしてます。 svn diffのやり取りでもいけるかもしれませんが、まずはMercurialとSubversionの連携をやってみます。 試したOSはWindows Vistaです。 1.インストール Subversionは http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=11151&expandFolder=11151&folderID=91 からSetup-Subversion-1.6.6.msiをダ
Subversion: コミットメール(2) 〜GmailのSMTPサーバを使ってコミット時にメールを送ろう〜 - ...ing logging 4.0
Debian だとはじめは Ruby とか入ってないと思うので入れます． apt-get install ruby apt-get install rubygems gem install tlsmail apt-get install libopenssl-rubyリポジトリの ./hooks にある post-commit.tmpl を post-commit という名前で同じディレクトリにコピーし，中身を書き換えます． $ cat post-commit #!/bin/sh # POST-COMMIT HOOK # # The post-commit hook is invoked after a commit. Subversion runs # this hook by invoking a program (script, executable, binary, etc.) #
SVNのブランチは貧弱なのか - wyukawa's diary
もう8月ですね。暑いですね。W杯はスペインの優勝で幕を閉じました。 僕は7月からやばそうなプロジェクトに入りました。僕の7月の残業時間は60ですが、100オーバーの人も少なくないようです。夜中の11時過ぎても人がいっぱいいるのはやっぱ変ですよね。 来年の3月まで続くのにこの状況です。自分も含めて心身壊す人が出ないことを祈ります。 さてそんな状況ではありますが、興味深いエントリがありました。 分散型バージョン管理システムは実際の開発現場でどれだけ普及するか？ - 現場のためのソフトウェア開発プロセス - たかのり日記 エントリの内容には割と同意です。 僕自身も含めてですが、いままで見てきた感じでいうとSVNを使いこなしてかつ構成管理を意識できる開発者は多くないのが現実です。 ありがちなのはこんな感じ。 コミット漏れによるコンパイルエラー 他の人の変更内容を誤って上書き 自分が作業しているEc
TortoiseHG+hgsubversionでのsvnのbranchのmerge - monjudoh’s diary
概略 hgsubversionではhg mergeしてできたmerge済みrevisionをpushすることはできない。 hg mergeしたら merge前revisionにhg update merge済みrevisionでrevert hg commit とやって同内容の非merge revisionを作ってそれをpushすれば良い。 せつめー 黄色のbranchから黒のdefaultにmergeするとする。 まず、TortoiseHGで普通にmergeする。 確認ダイアログでlocal:default,other:branchとなっているようにすること merge直後の状態はこのようになる。 hgsubversionではhg mergeしてできたmerge revisionをpushすることはできないので、 defaultのmerge直前revisionにhg updateし、 m
プロジェクトで Git を使ってみた感想とか - miauのブログ
2009/12〜2010/06 くらいまでの案件で Git を使ってみたので、その感想その他です。毎度長くてごめんなさい。 Subversion の経験はそこそこある状態でのスタートです。 リポジトリ構成のポイント ソースコードは Git、ドキュメントは Subversion で Git はファイル名をバイト列で管理するので、Windows と Linux の両方で使いたい場合は日本語名のファイルは使えません。（今のところ対応予定もないとのこと。ファイルのコンテンツやコミットログについては UTF-8 で統一できるので問題ありません。） ソースコードについては日本語名のファイルは含まれないので Git 管理でいいと思いますが、ドキュメントに関しては難しいので Subversion 管理にしました。 リポジトリの単位は細かく Git では Subversion と違ってリポジトリの一部をチェ
コミットコメントを意地でも書かせたい - almost nearly dead
コミットコメントを意地でも書かせたいと思うことがあります。 でも意外と書いてもらえなかったりします。 酷い場合だと バグ修正 とか 対応した だけ書いてあったりします。 注意するのも疲れるし、大抵の場合は注意しても直りません。 そんなわけで、私が面倒を見ている環境だとpre-commit-hooksを使って、規定のバイト数のコメント書かないとコミット出来ないようにして対応しています。 単にエラーだと障碍だと騒ぐ人達が居るので、コメントの重要性をエラーメッセージで語りかけるようにもしてたりします(笑) 以下はTracLightning環境下で動作する(はず)のScriptです。*1 キーワードの定期的な見直しは必要ですが、コメントを書かないとコミットできなくなるので意識付けを行うのには有用だと思います。コミットコメントが書いてもらえないと悩んでいる方は試してみては如何でしょうか。 ＃結構やっ
Subversionの今後は？ 分散型バージョン管理にはならないと提案
Apache Subversionは、ソースコードなどのバージョン管理システムとして普及しているソフトウェアです。今年10周年を迎え、2月にはApache Software Foundationの正式なプロジェクトにもなりました。 Subversionは1つのリポジトリを共有する中央集中型のバージョン管理システムですが、バージョン管理システムではここ数年、gitやMercurialといった分散型への注目が高まり、広まってきました。 こうした状況の中でSubversionの主要な開発者が集まり、今後の方針とロードマップついての話し合いが行われました。そして今後のSubversionの方針（Vision）とロードマップ（Roadmap）についての提案が、メーリングリストにポストされています。 集中型バージョン管理を堅持するという提案 方針を説明する最初の一文でもっとも気になること、すなわちSu
週末プログラマにお薦め！！Subversion+DropBoxで似非分散型バージョン管理 - プログラマでありたい
※Git版も書いています。 Git+DropBoxで、プライベートリポジトリ作成。或いはGitをAmazon S3でバックアップ 週末プログラマの悩みに、バージョン管理のリポジトリをどこに置くかというのがあります。理想を言えばどこかのサーバーにおいて、HTTP経由でどこからでもアクセス出来るのが一番良いです。でもそうすると、レンタルサーバーのコストが掛かります。またGitHub等もありますが、基本的にソースをオープンにすることが前提ですので、個人ユースで使いにくい部分もあります。で、勢い自分のローカルにしかソースがないという状況があります。 私は以下３つの問題を改善したいなぁと思っていました。 １．ソースのバックアップをどこか違うところに持ちたい ２．ネットワークでオフラインの時でも、コミット出来るようにしたい ３．違う環境から作業しても、最新のソースを取れるようにしたい そこで、gitで
無為空間 |bzr rebaseはSubversionリポジトリのブランチでも使える
無為空間 むいむい(´ω｀*) Entries bzr rebaseはSubversionリポジトリのブランチでも使える タグ: Bazaar Subversion bzr 2.0.4 bzr-rebase 0.5.4 bzr-svn 1.0.0 で確認。 rebaseが使えると、Subversionで $ svn checkout http://example.com/svn/tags/version1 # 安定版を落としてくる ……いろいろ編集する…… ……いろいろ編集する……（ローカルの版管理どうしよう……(~_~;)） $ svn switch http://example.com/svn/tags/version2 # 安定版が新しくリリースされたのでチェックアウトをそちらにswitchする とかやっていたところを $ bzr branch http://example.com/
blog.endflow.net
We Trust? 信仰してますか？ ということで、今年も Definitive. Advent Calendar 2023がリリースされました。 去年は飲みたい豆からつまみ食い的に選んでしまったため、最後に残った Don Benjie Rum Barrel Aged を飲んだのは3月くらいでした。 今年は同じことを繰り返さないよう、毎日順番にブラインドで飲むことにしました。その都度簡単なメモを残すようにして、この記事で公開し、そのあとパナ氏から8日分の正解を教えてもらって答え合わせする、恥晒し企画です。 アドベントカレンダーは超信仰を選びました。対戦よろしくお願いします！！！ Cold Brew (水出し) 2.0 アイスコーヒー 2.0を書いたのが 2020 年の夏なので、そこから 2 年も経ってしまったなんて驚きだ。 今回も懲りずに「2.0」シリーズを書いていくんだけど、なんで Co
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
bzr-svn — Bazaar v2.1.0 documentation