svnでファイル名に@が含まれるファイルをrevert/rmする方法 - このブログはURLが変更になりました
ハマった。 @入りのファイルを間違ってバージョン管理下におくと、svn的に消せない/戻せない状況に陥る。確認したバージョンは1.6.9。 再現方法 svn cpで@入りのファイルを生成する。 $ touch foo $ svn add foo $ svn cp foo bar@baz $ svn status A bar@baz A fooはい、じゃあrevertしてみてください。まずはfooを。これは普通にできる。 $ svn revert foo Revert 'foo'同じようにbar@bazも消してみますかね。 $ svn revert bar@baz svn: 'bar' does not exist $ svn revert bar\@baz Skipped 'bar'え？revertできない。あーリビジョン記法になってるのね。ということはこうかな？ $ svn revert
checkoutしたファイルのmtimeを、そのファイルがcommitされた時刻に合わせたい ― svnとgitの場合 - （ひ）メモ
唯一の中央レポジトリと複数のcheckoutするノードというトポロジの場合、checkoutしたファイルのmtimeがノード間で同じ時刻(当該ファイルがcommitされた時刻)になっているとなにかと都合がいいです。 例えば、Webアプリのデプロイを中央レポジトリからのcheckout(やupdate)で行う場合を考えます。もし、内容が同じなのに複数あるアプリサーバの間でmtimeが異なってしまっていると、 サーバごとにETagヘッダの値が異なってしまう ※Apacheの場合、FileEtagディレクティブを調整(mtimeを見ないように)することによって統一可能ではあります サーバ間でrsyncをかけると無駄なファイルコピーが発生する 内容が同じににもかかわらずmtimeが異なるせいでコピーが発生する ※--size-onlyオプションでmtimeを見ないようにして回避可能ではあります と
Subversion で間違えてディレクトリをごっそり消してコミットしてしまった時
今日のプロジェクト成果物とりまとめを前に昨日、メンバの1人が trunk 直下の2年半分のファイルが入っているプロジェクトディレクトリをなぜか削除してコミット。 朝きたら過去のリビジョンをエクスポートして再度追加して戻したとかで、全部履歴が切れてしまっていた。作業ディレクトリも全部入れ替わり。 こういう時は過去のリビジョンからの copy をすべし。 履歴が維持される 属性などもコピーされる 他のチェックアウト済み作業ディレクトリへの影響もなし といった点で優れている。 作業ディレクトリを使って消したディレクトリを戻す svn copy --revision R URL . svn commit -m "Resurrected dir1 from revision R" ここで R は間違えて消してコミットしたリビジョンの1つ前のリビジョン。 URL は削除したディレクトリの URL。 実
SubversionリポジトリとTrac作成コマンドのメモ - maru.cc@はてな
いま、デプロイ方法や、プロジェクト管理方法のうまい方法が無いか模索中です。 何十、何百人月で、運用が数年続く案件ならば、初期設定がある程度コストがかかっても、しっかりとした仕組みを設置することは出来ますが、うちの場合には、1人月程度で、しかも運用自体も数ヶ月という短期案件が結構あります。 その場合に、初期コストをかけずに、ある程度大規模になっても適用できる仕組みが無いものか。 今現在は、Subversionでバージョン管理をし、そこから、rsyncのシェルバッチを使用し、ステージング、本番へ反映する仕組みはあるのだが、もっといい方法は無いものか。 いい方法があったら、ぜひ教えてください。 で、Subversionも、ひとつの共有リポジトリにプロジェクトごとにフォルダを作成して作業していたのですが、ファイル数が多くなってくると、svn update がめちゃめちゃ重くなってきたので、プロジェ
【CGI・Perl】実行可能な属性をファイルに付加する（svn:executable）
CGI・Perl例文集 CGI(Perl)のサンプルプログラムをコピー＆ペーストで使える便利集！ カテゴリー：svn_propset 実行可能な属性をファイルに付加する（svn:executable） Subversionで、ファイルに実行可能な属性を付加したい。 複数のOS間で運用しているといつの間にか設定したパーミションが外れてしまう問題を解決したい。これはSubversionで属性の設定を行えばよい。 Subversion自体に、このファイルは「実行可能なファイル」であると記憶させてやれば解決する。Windows上では別段変化はないが、Linuxなどでcheckoutするとパーミションが設定された状態でファイルがセットされる。 $ ls receive.cgi settag.cgi $ svn propset svn:executable ON settag.cgi pro
[linux]なんでもsvnで管理する - もぎゃろぐ
サーバをさわるときは、常に信用できない人間が約一名(自分だ！)いるので、どんな作業でも取り返しがつくようにするのが大切です。 ssh上で行った作業のログをとる - もぎゃろぐ という具合にしてログをとることで、いざというとき何をしていたか振り返ることができるようになるのですが、設定ファイルに変なことを書いた場合、emacsの修正内容はログに残らないので、まだ若干不安が残ります。 そういえば、masuidriveさんは、「コマンドも含め全てのファイルはSubversionで管理」しているのだそうで。 masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針 こうしておけば、ファイルに変なこと書いても最悪ロールバックできますので、これは大変いいアイデアだと思います。 具体的にどうやるのか今ひとつわからなかったので躊躇していたので
svn:externals のリビジョン固定 : netswitch!
Railsで $ script/plugin install -x したプラグインのリビジョンを固定するには、
YappoLogs: 複数のsvnリポジトリを一つにまとめる方法
複数のsvnリポジトリを一つにまとめる方法 うちのsvnリポジトリは、trac等で公開をする前までは、各コンポーネント毎にリポジトリを作るという非効率な管理をしていました。 そろそろ嫌になって来たので、これを全部公開用にまとめようと思い、helpみながら頑張りました。 要件的には、リビジョン番号が変わっても良いから、とにかくlogを含めてインポートしたい！ という感じです。 最初はsvkとか使わなきゃだめなのかなぁ、とか思ってたのですがsvnadminだけで願いが叶いました。 dumpとloadを使います。 loadする時はオプション無しでloadしてしまうと、dump前のファイルパスにデータをぶっ込んでくれちゃうので、trunkとかが混ざってカオスになっちゃいました。 そこで--parent-dirオプションを使って、どのパスにloadするかを明示的に指定してloadします。 --par
Subversion : OSS へのローカルな変更を管理する - WebOS Goodies
WebOS Goodies へようこそ！ WebOS はインターネットの未来形。あらゆる Web サイトが繋がり、共有し、協力して創り上げる、ひとつの巨大な情報システムです。そこでは、あらゆる情報がネットワーク上に蓄積され、我々はいつでも、どこからでも、多彩なデバイスを使ってそれらにアクセスできます。 WebOS Goodies は、さまざまな情報提供やツール開発を通して、そんな世界の実現に少しでも貢献するべく活動していきます。 先日の記事で net2ftp の日本語エンコーディング変換対応パッチをご紹介しました。このように既存のオープンソースソフトウェアに変更を加える際に問題となるのが、独自のローカルな変更とソフトウェア本体のアップデートによる変更をいかにしてマージするかです。ソフトウェアの更新頻度にもよりますが、アップデートのたびに手作業で変更を適用するのはとても面倒ですよね。 こんな
Subversionのpost-commitフックでsvn updateできないときは : akiyan.com
Subversionのpost-commitフックでsvn updateできないときは 2006-12-26 OSCON : Subversion Best PracticesではWebサイトのsvn updateはpost-commitフックで自動的にやろうといわれています。 私もそれに倣って以下のコードをpost-commitに書いてみたのですが、何度やってもうまくいきませんでした。post-commitフックスクリプト自体は動作しているのですが...。 /usr/local/bin/svn up /path/to/working/directory >> /tmp/svnupdate.log & そこで同じ境遇の人がいないか探してみたところ、見つけました。 SubversionによるPHP開発環境バージョン管理話 2006.10.03-[Id of Radiance]より。 ところが
ネットワークボリューム上に.DS_Storeファイルを作らせない
macosxhints経由。 ネットワーク上のボリュームに.DS_Storeを作成させない方法。 元ネタはAppleのこのアーティクル。 やり方はTerminalで として改行し、設定を変更したらシステムを再起動（実際にやってみましたが、システム再起動が一番良いです）。 これだけ。 これでシステム再起動後にネットワークボリュームにアクセスして何かファイルをコピーしてみても.DS_Storeファイルは作られません。 ものすごく素敵なTip！ ちなみに私の環境では、ネットワークボリュームつったってWindowsXPが走っているWebサーバーなんでありますので、バッチファイルで処理しております。 これは「出来ちゃったファイルを一括削除」って方法なのですが．．．。 やり方は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
