Google のウェブログ公開ツールを使って、テキスト、写真、動画を共有できます。
Subversionにおけるブランチとは、ディレクトリのことである。 Subversionにおいては、ブランチとは単なるディレクトリに過ぎません。 Subversionではよく下記のようなツリー構造にすることが推奨されます。 project - trunk - branches - foo - bar ブランチfooやブランチbarは、たいていtrunkディレクトリをコピーして作ります。 「ブランチを作成する」という行為は「ディレクトリをコピーすること」と操作的には同じであり、1コミットとして扱われます。 $ svn cp svn://path/trunk svn://path/branches/foo -m "make branch" 「ブランチの名前変更」も「ディレクトリのリネーム」と同じ操作であり、やはり1コミットして扱われます。 $ svn mv svn://path/branch
もう8月ですね。暑いですね。W杯はスペインの優勝で幕を閉じました。 僕は7月からやばそうなプロジェクトに入りました。僕の7月の残業時間は60ですが、100オーバーの人も少なくないようです。夜中の11時過ぎても人がいっぱいいるのはやっぱ変ですよね。 来年の3月まで続くのにこの状況です。自分も含めて心身壊す人が出ないことを祈ります。 さてそんな状況ではありますが、興味深いエントリがありました。 分散型バージョン管理システムは実際の開発現場でどれだけ普及するか? - 現場のためのソフトウェア開発プロセス - たかのり日記 エントリの内容には割と同意です。 僕自身も含めてですが、いままで見てきた感じでいうとSVNを使いこなしてかつ構成管理を意識できる開発者は多くないのが現実です。 ありがちなのはこんな感じ。 コミット漏れによるコンパイルエラー 他の人の変更内容を誤って上書き 自分が作業しているEc
今年に入ってから、急速にGitが注目を浴びています。Google Trendsを見ると、Subversion、Mercurialなどに比べると圧倒的にGitの人気が高いのがわかります(図1)。 図1 Google TrendsによるGit(青)、Mercurial(赤)、Subversion(橙)の検索数 しかしながら、Gitを利用する人の意見は2つに分かれています。 A.わかりにくい B.すごく便利だ なぜこのようなに印象が二分されてしまうのでしょうか? 本稿では、「Gitに潜む光と闇」と称してこれらの意見に対して考察していくことにします。 Gitはわかりにくい? Gitがわかりにくいと思う人は、どうしてそう感じるのでしょうか。そのあたりのおおよその事情は下記のようなことだと考えられます。 (1)Subversionとコマンド体系が少し違う バージョン管理ツールとして、Su
※ 本記事の内容は「僕の個人的な考え」であって、正解とは限りません。予めご了承ください。あと、長いです。 能書き ここ半年ぐらい、僕のまわりでは「Gitに移行しようぜー」的な波が押し寄せてきてる。前職の職場も、今の職場も、大学時代の友達も。一方僕は、学生時代(3年前ぐらい?)にたまたま偶然Gitに首突っ込んだので、もう既にGitがないと生きていけない体になってしまっているという立場。ということで、Gitについて思うところを僕なりに一回文章にしてみようと思う。 ここに書くのはGit入門ではなく、「Gitの基本コマンドは覚えて使えるけど、どうやったらGitっぽくつかえるか、Gitの恩恵を得られるか掴みきれてない」ぐらいの習熟度の方に参考になるような内容の予定。もちろんここに書いてあることに従えと言いたいわけではないので、違う意見の場合はぜひコメントなど頂ければ幸いですし、Git勉強中の方は1つ
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに1個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
2010 年 2 月 1 日 For home projects, can Mercurial or Git (or other DVCS) provide more advantages over Subversion? - Stack Overflow より、抄訳。 この記事は Git と Subversion の比較だけど、ここで言っていることは全て Mercurial にもあてはまる。 リポジトリの初期化: git: git init subversion: svnadmin create /path/to/repo svn import http://long.url.to/repo yourwork rm -R yourwork svn checkout http://long.url.to/repo yourwork うぁー、めんどくせー!! リポジトリとメタデータ: git
WCが壊れたのかと思ってあせったが、既知の問題らしい。 1.7系のSubversionではときどきcleanupしたほうがよいのかも。 git gcと同様にときどき圧縮してやる必要があるということか。 $ svnversion . svn: E200030: sqlite: callback requested query abort svn: E200030: sqlite: callback requested query abort $ svn cleanup $ svnversion . 11602 それらしきチケットもあった (本家でなく macportsだけど) #33751 – https://trac.macports.org/ticket/33751#comment:19 In case this helps anybody, "svn cleanup" fixed th
SVN へのコミットをフックしてビルド実行出来るようになった これまでに比べるとハマったとこはだいぶ少なかったけど フックスクリプト実行時には環境変数が空の状態で起動されるというのを 知らなかったために、しばらく何でフックされないのかなー? っていう状態になってました 以下を参考にさせてもらいました http://d.hatena.ne.jp/kaorun55/20080815/1218767907 http://www.asahi-net.or.jp/~iu9m-tcym/svndoc/svn_hook_script.html フックスクリプトの作成上の注意 フックスクリプトが実行されるときには、セキュリティ上の理由から環境変数(PATH 変数も)がすべて空の状態で起動されます。 このためスクリプト内部で外部プログラムを起動する場合は絶対パスを使用するかスクリプト内部で環境変数を設定する
Takumi IINO @troter bzrって自分のローカルに任意のブランチを作る場合って、ローカルの共有レポジトリを作ってそこに作業対象ブランチをチェックアウトして、そのチェックアウトからローカルの共有レポジトリにトピックブランチを作るって作業をするのか。こういう点はhgとかgitとかの方がいいなぁ。容量的に Takumi IINO @troter 「共有レポジトリとブランチ(Repository tree)」と「スタンドアローン(Standalone tree)」の違いって、履歴などの情報を共有するか個別に持つかの違い?。スタンドアローンはディスク食べる。共有レポジトリはgitのブランチに近い事ができる。実体があるけど。 Takumi IINO @troter 次のような操作をした場合を想定: mkdir ~/sandbox; cd sandbox; bzr init-repo -
Subversion リポジトリでシンボリックリンクは普通に使えるようです。 $ ln -s hoge hoge-link $ svn add hoge-link このときシンボリックリンクファイルには svn:special という属性がつき,内部的にはリンクが記述された通常ファイルとして扱われるようです。そのためか HTTP サーバー上でシンボリックリンクとして扱うことはできません。残念です。 Windows で扱う際は, svn:special 属性が無視されて通常のファイルとしてチェックアウトされてしまうことを注意しなければなりません。 Windows clients don't have symbolic links, and thus ignore any svn:special files coming from a repository that claim to be s
Subversion基本操作リポジトリ生成(create) + import の実際リポジトリ生成 (create)svnserve 設定/起動モジュール登録 (import)チェックアウト(svn checkout/co)コミット(svn commit)更新(svn update/up)状態確認(svn status/st)アイテムの追加(svn add)アイテムの削除(svn /delete/del/remove/rm)アイテムの移動(svn move/mv)差分確認(svn diff/di)応用個人用設定ファイル(.subversion/config)チェックアウト応用(svn checkout/co)リビジョン指定コンフリクト解消エクスポート(svn export)リポジトリ内リスト(svn list/ls)ファイルの無視(svn propset svn:ignore)キーワード展
\閉鎖予定のサイトも売れるかも?/ アクセスがないサイトもコンテンツ価値で売れる場合も… ドメインの有効期限を更新してサイト売却にトライしてみましょう
svnは基本的にファイルパーミッションを管理しない。しかし、実行属性だけは管理している。 svn proplistでファイルに実行属性が付いているかどうか確認できる。 http://subversion.bluegate.org/doc/re23.html svn:executableと表示されれば、そのファイルには実行属性が付いている。 http://subversion.bluegate.org/doc/ch07s02.html#svn.advanced.props.special ファイルに実行属性を付けたい場合は、 svn propset svn:executable 実行属性を付けたいファイルhttp://subversion.bluegate.org/doc/re24.html ファイルから実行属性を消したい場合は、 svn propdel svn:executable 実行属
正直、svnの環境整えようとすると、パーミッションが個人的に一番腹が立つ。 不要な権限与えたくないけど、複数ユーザでの更新作業はやれるほうがいいし、もろもろ悩ましい。 ということで、そのときの備忘録。 ちなみに、ApacheやWebdavの設定はしないで、svn環境できればok。 とりあえず、今回はクライアント側をWindows環境下として想定。Macは気力あれば書く。 まぁ、結論は負けましたw まずユーザと開発グループ追加。このユーザにシェルとパスワード与えず、開発者をdevグループに所属させるってのがいいのかなぁ。 ここで既に悩ましい。 # /usr/sbin/groupadd dev # /usr/sbin/adduser -g dev svnんで、subversionのインストール。 # yum install subversionんで、まずここ。 今回はGUI環境でTortois
南関東の「いろんなところから富士山が見える」状況に驚きつづけている 大阪から東京に引っ越して30年以上経つが、じわじわと蓄積されてきた驚きがついに閾値を超えたので筆を執った次第である。正確には「ポメラ DM250を起動してmenuキーを押して新規作成を選んだ」のだが、ポメラを持っていなかったら、さらに驚きが蓄積されていないと…
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く