Subversionリポジトリ再構成 - 日々の報告書
ゴールデンウィークの休みを利用して、さくらのサーバにソースコード管理用のSubversionリポジトリを移行した。基本は元のリポジトリのデータをdumpして、さくらサーバ上にloadするだけなんだけど、今まで単一リポジトリにソースコードやデータファイル（はてなダイアリーのバックアップ、ホームページのデータなど）も突っ込んでいたので、コード用、データ用にリポジトリの分割もすることにした。これがトラブル続きで、めんどくさく、大変時間がかかった。まとめるのもおっくうなので、要点だけをメモ。 svnリポジトリから一部のモジュール（ディレクトリ）を切り出して、別のリポジトリに移す場合、1)svnadmin dumpでダンプしたファイルを、2)svndumpfilterを使って必要な部分のみ切り出す $ svnadmin dump svnrep > svnrep.dump $ svndumpfilte
hgsubversionのhg clone --startrev - monjudoh’s diary
前置き hgsubversion自体の導入については↓をどうぞ hgsubversionの導入 - 文殊堂 ちょっと前までのhgsubversion ちょっと前までhgsubversionではsvnのリポジトリの完全なコピーを作ることしかできませんでした。 例えば10年物のsvnリポジトリをhg cloneすると10年分の履歴全てを取ってきてしまいます。 目的がsvnリポジトリのコンバートであるなら問題ありませんが、 svnリポジトリを正としつつMercurialの分散SCMの機能を活用して開発をいい感じにやりたい という場合には困ります。 git-svnのように特定リビジョン以降だけ持ってくるとかやりたいです。 startrev option で、changeset:827547493112から出来るようになりました。 残念ながら基底のURL(/trunk,/tags/,/branche
仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
