少し前のことですが、tracの移行作業(subversionのリポジトリ移行も含む)を行いました。 今後、同じ作業をどこかでするかもしれませんので、忘れないようにメモ。 例として、 trac-projというtracプロジェクト svnrepというsubversionリポジトリ を別マシンに移行する場合を考えます。tracのDBはsqliteとします。 まず、移行元のマシンでtrac-projとsvnrepのバックアップを取ります。他ユーザのアクセスとバックアップが競合しないようにhotcopyコマンドを使ってロック+バックアップします。 $ trac-admin ~/trac/trac-proj hotcopy trac-backup $ tar cvfz trac-backup.tar.gz trac-backup $ svnadmin hotcopy ~/svn/svnrep svn-
普段のプログラミングにgitを使用しているのだけど、実際の現場ではまだまだsvnが主流だったりする。svnを直接使ってもいいのだけど、やはりローカル上でコミットしたいとか、複数のコミットを1つにまとめたいとか、トピックブランチを切りたいとかあるのでそれはsvn単体だと厳しい。そんなわけでBetter SVNとしてのgit svnの紹介、と言うよりメモ。 リポジトリのクローン git svn clone repository_url これでsvnリポジトリをgitリポジトリとして取得できる。大きめのリポジトリだと結構時間がかかるのでのんびりと。svnリポジトリの構成がtrunk/branches/tagsという一般的な構成であればオプション-を付けるのがおすすめ。trunkをmaster、branches/tagsをremote branchとして扱うようになる。個別に指定する方法もあるので
svnとgit両方使うようになりました。するとgitの便利さに感嘆する一方、svnのブランチ操作の面倒臭さが際立ってきました。特に、ブランチ操作ではgitは素晴らしく例えば以下のような例をご覧いただくとその差は一目瞭然かと思います。 ブランチ一覧を得る git branch svn list http://example.com/svn/branches ブランチを作る git branch mybranch svn cp http://example.com/svn/trunk http://example.com/svn/branches/mybranch -m 'create mybranch from trunk' 以上のように、svnはブランチをブランチとして扱っていないためとても面倒なコマンドを打たなくてはなりません。これではとてもsvnのブランチなんて使ってられないのでとっと
ProductAnnouncing SVN SupportEver wanted to use SVN to grab code from GitHub? Well, now you can, and just like that GitHub is the world's biggest Subversion host. Here's a few things you… Ever wanted to use SVN to grab code from GitHub? Well, now you can, and just like that GitHub is the world’s biggest Subversion host. Here’s a few things you might like to do with it: Use any GitHub repository as
Posted at 2010/01/11 17:29, Modified at 2010/01/15 00:57 多人数で開発する場合、バージョン管理システムと、そのシステム上でのブランチの作成とマージは、必要不可欠だと思う。最近、Flickr はブランチもマージもしない というのを読んでだいぶ驚いたけど、こういうのはかなり稀だ。 マージは面倒な作業だ。その面倒さは、あるソフトウェア x が xa, xb と分岐したときに、それを統合した x(a+b) をつくる、という行為自体がそもそも難しいというのもあるし、いい加減行ベースの diff が野蛮すぎるというのもあると思う。 バージョン管理システムがもっとがんばれるのでは、というのもある。広く使われているバージョン管理システムである Subversion について、マージまわりの機能の貧弱さはよく指摘される。Linus Torvalds も
以前から個人的にLDAPを導入しているのですが、意外と忘れがちなので備忘をかねてメモります。 昔のメモなので今と挙動が違うかもしれませんがご了承ください。OSはCentOS 5です。 まずはOpen LDAPのインストールと設定をします。 関連パッケージのインストール $ yum -y install openldap openldap-servers openldap-clients openldap-devel ディレクトリマネージャのパスワードを生成する $ /usr/sbin/slappasswd -h {SSHA} New password: Re-enter new password: slapd.confの設定 /etc/openldap/slapd.conf ...snip... access to attrs=userPassword by self write by a
git-svn のちょっとイイ話 Git-SVN を使ってる人が周りになんとなく増えてきたので。 SVN クライアントとして Git を使える利点は、ネットワークどうこうというよりは、 Git の便利機能が使えまくることなんじゃないかと思います。 Git が SVN よりも圧倒的に優れている点としては、ブランチのマージが楽という点が挙げられると思いますが、 Git-SVN を使うことで、 SVN ユーザーもこの Git の優れたマージ機能の恩恵を被れます。 SVN は CVS よりブランチ作りやすくなってるけど、マージが困難なので結局ロクにブランチ切らない、みたいなことも多いと思うのですが、 Git-SVN があればガンガンブランチ切ってはマージしまくって、というふうに作業出来ると思います、よかったですね。 んで、 Git-SVN を使っていると、今自分が作業しているのがどこにコ
メモ。 $ git svn rebaseしたときに、自動的にマージできず、 CONFLICT (content): Merge conflict in path/to/conflicted_fileWhen you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To restore the original branch and stop rebasing run "git rebase --abort". rebase refs/remotes/trunk: command returned error: 1 こんなメッセージが出たときの解消手順。 status を確認するとこん
I've been trying to persuade git-svn to work properly with Rails plugins that are installed via svn:externals. Whilst working out how to do it I stumbled across several great articles, but I couldn't get any of the solutions presented to work perfectly. Samuel Tesla's article is especially informative, but for a long time I couldn't stop git-svn from trying to commit Git metadata back into my Subv
は基本的には出来ないそうです。 なんか昔のマニュアルにはそれらしきものがあるのだけれど、現在はgit svn show-externalsが残っているだけで、確認はできるものの自動でガガーっと取って来れて、submoduleになるなんてのは夢物語なのです。 # 実は出来たりするのかもしれないけれど、良く分からなかったし、 # Git使っている人の大半がSubversionも使えるので需要がないらしい。 # 新人類には厳しい現実だ。 ということでいろいろ調べていたのですが、結論としてexternalな部分に編集が必要ない場合は、個別にgit svn cloneしてきて、.gitignoreに加えておくのが良いみたい。 でもRailsのプロジェクトなんかでプラグインが大量にexternalになっている場合は面倒だよ! ということを考えるのは僕だけではないようで、 http://github.c
Rubyパッチ袋 まあ、おまえらもmatz基調講演を聞いて「意外にも思いつきではなくちゃんとパッチが管理されている」ことに衝撃を受けたことだろう(実は前から日記とかで言及されてはいたが)。あれを見てそろそろgit使い始めようかとか思いだしたかもしれない。しかし、じゃあといってRubyのレポジトリをgit svn cloneしようとすると果てしなく時間がかかる(ネットワーク状況などにもよるが30時間くらい?一日以上なのは確実)ので、多くの人はここでめげてしまう。 ところが案外知られていないけどgit-svn(1)は実はよくできていて、git svn cloneってのは毎回みんながやる必要はなくて、本当はだれかがどこかで一回やればいいのである。他の人はそいつをgit cloneすればいいの。その誰かさんのgitレポジトリってのはみんなが見れるところにないといけないわけだが、そこはもちろんgit
Windows側からGUIでいじってる方のクライアントをTortoiseSVN 1.5.2にアップデートしたせいで,リポジトリの形式がSubversion 1.5の形式に書き換えられ,1.4系クライアントを使っているCentOSのほうから書き換えができなくなってしまった. そんなわけで,CentOS 5.2のほうもSubversion 1.5にバージョンアップ. パッケージインストールはdagから おなじみのdag(rpmforge)ですね.dagを yum のリポジトリに追加する方法は毎度のことですがてきとーにググる. 私の場合は普段はenableにしていないので(utterramblingsのパッケージと若干バッティングするものがあり,ApacheやPHPでちょっとうまくいかなくなるので),以下のように実行. % sudo yum update --enablerepo=dag sub
ふつうに使ってるのですが、そういえばメモしてなかったなーと思い、なんとなくメモしておく。 ちょっとBKなんですがもっとスマートなやり方はないものか。。。 $ git checkout -b working_branch $ git svn info # => trunkのURLになる # 何かしら作業する $ git commit -a $ git commit -a $ git commit -a # svnにremote branch 作る $ git svn branck new_remote_branch # svn copy trunk branch とほぼ同様 $ git checkout new_remote_branch -b worknig_branch_remote $ git svn info # => branches/new_remote_branchのURLが出
git, svnCodeReposへのやりとりにgitを使おうと思い、手早くリポジトリをセットアップするため、対象をオリジナルのリポジトリの一部に限定かつ変更履歴を省略するため以下のようにしたところ、何もfetchされなくて困りました。 $ git-svn clone -r HEAD http://svn.coderepos.org/share/dotfiles/vim dotfiles-vim Initialized empty Git repository in .git/ $ 何が理由か色々と試してみたのですが、どうやら上記のようにリポジトリの一部/dotfiles/vimに限定してgit-svn cloneをする場合、-rで指定したリビジョンの範囲の変更に/dotfiles/vim下のファイルやディレクトリが含まれていなければならないようです(git-svn clone = gi
git-svn git-svn は Subversion と git の相互運用を可能にするコマンドです。git-svn コマンドにより Subversion リポジトリの一部または全体を git リポジトリに変換することができます。 git-svn コマンドは tags として指定された Subversion ディレクトリを git のブランチにマッピングします。例えば、上記の releases/releases-2.6.2 は tags/releases-2.6.2 にマッピングされます。今回は releases をタグとして扱いたいため、git-svn コマンドだけでは目的を達成できません。(実行後にいくつか作業を行う必要があります。) svn2git svn2git は git-svn のラッパーですが、git-svn とは異なり、タグとして指定した Subversion ディレク
已通过安全加密检测 如果没有自动跳转,请点击下方按钮前往 点击进入 360安全卫士提供技术支持 Copyright © 1998 -2020. All Rights Reserved.
Subversionリポジトリのバックアップ方法が色々ありすぎて何がベストなのかわからなかったので調べてまとめてみた。 ただのファイルコピー 普通にファイルシステム上でディレクトリをコピー(あるいはアーカイブ)する方法。非推奨。 誰かがリポジトリにアクセスしている最中にやると壊す可能性がある。 リポジトリディレクトリをコピーしたいならsvnadmin hotcopyを使うべき。 長所 簡単。 速い。 短所 バックアップデータの可搬性に乏しい(アーキテクチャ依存)。 リポジトリをロックしないので壊す可能性がある。 データエラーが検出できない。 svnadmin dump/load svnadminのdumpとloadを使う方法。 誰かがアクセス中でも一貫性が保たれる。 あくまで管理対象のファイルのみのバックアップなので、設定やフックなどは別途バックアップが必要となる。忘れがち。 差分バックア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く