git-svn のちょっとイイ話 Git-SVN を使ってる人が周りになんとなく増えてきたので。 SVN クライアントとして Git を使える利点は、ネットワークどうこうというよりは、 Git の便利機能が使えまくることなんじゃないかと思います。 Git が SVN よりも圧倒的に優れている点としては、ブランチのマージが楽という点が挙げられると思いますが、 Git-SVN を使うことで、 SVN ユーザーもこの Git の優れたマージ機能の恩恵を被れます。 SVN は CVS よりブランチ作りやすくなってるけど、マージが困難なので結局ロクにブランチ切らない、みたいなことも多いと思うのですが、 Git-SVN があればガンガンブランチ切ってはマージしまくって、というふうに作業出来ると思います、よかったですね。 んで、 Git-SVN を使っていると、今自分が作業しているのがどこにコ
subversionに関するnihenのブックマーク (15)
-
nihen 2009/09/08
-
blog.shu-cream.net : subversionがユーザ名とパスワードを覚えてくれないとき
普段はsvn+sshで鍵認証しているので問題ないのですが、httpなリポジトリを使うときに何故かユーザ名とパスワードを毎回きかれるので困っていると言ったら、id:ursmが原因を知っていました。 .subversion がシンボリックリンクだとダメ なんかセキュリティ上の制約でもかけてるんですかね。 ほとんど全てのドットファイルをgithubで管理しているので、「クローンしてきてシンボリックリンク」という運用をしていたらひっかかってしまったようです。 結局、シンボリックリンクを削除して、cp -r して解決しました。 ursmには「もうsvn使わないからいいんじゃないですか？」と言われた今日。 はやく分散充になりたい。
-
論理整合性のチェックも含めたsubversionのバックアップ - へぼへぼプログラマ日記
* * * * * mv /path/to/backups/dumpfile_new /path/to/backups/dumpfile_old; svnadmin dump -q /path/to/myrepos/ > /path/to/backups/dumpfile_new crontabとかにこんなかんじで書いとくってのが最低限の構成かなぁ？ crontabのエラー出力からのメール送信を利用。 間隔についてはエラーメール受信後に対処できる十分な間隔で。 バックアップ間隔を対処可能時間よりも短くしたい場合は世代を増やす感じで。 まー、このぐらいは最低やっておかないと馬鹿にされそうですね。 dump時のエラーチェックをやってなかった人はすぐにでもsvnadmin verifyやってみよう。恐ろしい結果が待っているかもよ。
-
Subversionリポジトリのバックアップ方法いろいろ - ぱせらんメモ
Subversionリポジトリのバックアップ方法が色々ありすぎて何がベストなのかわからなかったので調べてまとめてみた。 ただのファイルコピー 普通にファイルシステム上でディレクトリをコピー（あるいはアーカイブ）する方法。非推奨。 誰かがリポジトリにアクセスしている最中にやると壊す可能性がある。 リポジトリディレクトリをコピーしたいならsvnadmin hotcopyを使うべき。 長所 簡単。 速い。 短所 バックアップデータの可搬性に乏しい（アーキテクチャ依存）。 リポジトリをロックしないので壊す可能性がある。 データエラーが検出できない。 svnadmin dump/load svnadminのdumpとloadを使う方法。 誰かがアクセス中でも一貫性が保たれる。 あくまで管理対象のファイルのみのバックアップなので、設定やフックなどは別途バックアップが必要となる。忘れがち。 差分バックア
-
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
-
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
-
-
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
-
-
ひげぽん OSとか作っちゃうかMona- - Subversionを ssh 経由で使おう(ApacheもWebDAVも必要ないよ) - masatobito さんのコメント
Subversionをローカルだけでなく本格的にサーバーで使おうと思うといつも障害になるのが以下の誤解だ。（というか今日まで誤解していた) Apacheで難しい設定をしなくてはならない ⇒Apacheの使用は必須ではない。インストールにaprというApache由来のライブラリが必要なだけ。 WebDAVとかいうよく分からない仕組みを理解しなければならない ⇒同じく必須ではない svnserverとかいうサーバを常駐させる必要がある ⇒同じく必須ではない 結局すべて、誤解でだった。 個人で使うならば、もっと簡単(?)というか親しみやすい方法があり、それが「ssh経由でアクセス」である。 自分的に ssh の理解も怪しかったのであわせて手順メモを残しておきます。 subversionのインストールは yum でやっていますが環境に合わせて下さい。 1.ssh設定 以下ユーザー名は higepo
-
[O] trac+subversionを使い始めた
« 夕方から起動 | トップページ | Gateaux de Voyage(ガトー・ド・ボワイヤージュ) とろけるシブースト 白桃 » trac+subversionを使い始めた [Programming] trac+subversionな環境を整えたので、まとめメモを書くことにします。 まだ不十分ですが、あとは徐々に改善。 trac+subversionなサーバを作っておきたい。 さらに、リポジトリ全体も定期的にバックアップをとりたい。 と思ったんですよ。 今は、個人のソースはかなりアバウトなバックアップをしていて 突然自分のPCが壊れてしまったとき、昨日とかおとといのソースが 無くなってしまうような状態なのです。 何もしてないわけではなく、CVSとSubversionは使っていますよ。 でもソースの差分をみて何か発見するとか、 タスクとかバグとかをメモしておいてほに
-
Subversion メモ
基本概念と特徴 リポジトリ Subversion は共有情報の一元管理システムであり、情報はリポジトリに格納される。 リポジトリは情報をファイルシステムツリー（一般的なファイルとディレクトリの階層構造）の形で保持する。 Subversion ではリポジトリの場所は URL によって表現される。 リポジトリにアクセスするための URL には以下のようなものがある。 file:/// リポジトリへの直接アクセス (ローカルディスク上) http:// Apacheサーバ への WebDAV プロトコル経由でのアクセス https:// http:// と同じだが、SSL による暗号化 svn:// svnserve サーバに対する独自 TCP/IP プロトコル経由でのアクセス svn+ssh:// svn:// と同じだが、SSH トンネルを利用する ほとんどの場合、Subversion の
-
SVN::Webいいねコレ - はこべにっき ♨
SVN::Webいいよ、コレ。いや、超有名なのかもだけど。知らんかったので。 "Subversion repository web frontend"ということで、私のように、tracを単にWebリポジトリビュアーとしてか使ってない人には手軽でおすすめ。SVN::Web自体のリポジトリがSVN::Webでみれます。 シンプルゆえに設定もわかりやすくて、コマンドラインでsvnweb-installしたあとで、config.yamlに repos: myrepos: '/path/to/my/repos' yourrepos: '/path/to/your/repos'とか書くとすぐ使える。リポジトリを全部同じディレクトリに入れてる人は、 reposparent: '/path/to/repos/parent'とやると、/path/to/repos/parent以下のリポジトリを全部見てくれて
-
リポジトリの構成で悩んでる - はこべにっき ♨
Subversionもだいぶ慣れてきて、本格的にsvn+svkな開発体制をとりたい*1そんでもって自分で書いたコードはtracで公開したいところ。 なんだけど、管理したいコードにはpublicなものとprivateなものがあって、publicだけtracで見せたい。かといって、作業用リポジトリはあんまりわけたくない。ポケットは一つが良いというか。 今考えてるアイディア以下のような感じ。 publicとprivateは別のリポジトリにする メリット publicとprivateがきれいにわかれる それぞれで全く別の設定ができる 別々のtracで動かすのもそのまんま デメリット プロジェクトつくるたびにpublicかprivateか悩む privateのものをpublicに移したりするのが面倒そう publicとprivateは同じリポジトリ内のディレクトリでわける メリット ポケット一つなの
-
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2024 Hatena. All Rights Reserved.
設定を変更しました