checkoutしたファイルのmtimeを、そのファイルがcommitされた時刻に合わせたい ― svnとgitの場合 - （ひ）メモ
唯一の中央レポジトリと複数のcheckoutするノードというトポロジの場合、checkoutしたファイルのmtimeがノード間で同じ時刻(当該ファイルがcommitされた時刻)になっているとなにかと都合がいいです。 例えば、Webアプリのデプロイを中央レポジトリからのcheckout(やupdate)で行う場合を考えます。もし、内容が同じなのに複数あるアプリサーバの間でmtimeが異なってしまっていると、 サーバごとにETagヘッダの値が異なってしまう ※Apacheの場合、FileEtagディレクティブを調整(mtimeを見ないように)することによって統一可能ではあります サーバ間でrsyncをかけると無駄なファイルコピーが発生する 内容が同じににもかかわらずmtimeが異なるせいでコピーが発生する ※--size-onlyオプションでmtimeを見ないようにして回避可能ではあります と
Subversionを見直せ - プログラマの思索
SW構成管理の概念の中心は、バージョン管理。 バージョン管理こそが我々SW開発に従事する者にとって、背骨であり血液に当たる最重要なインフラ。 デスマーチに陥るプロジェクトは、バージョン管理に何かしらの欠点や弱点がある。 おそらく殆どのSW開発では、Subversionをバージョン管理に使っているが、Subversionは実は数多くの機能を持ち、従来のプロジェクト管理を根本的に変える可能性を秘めている。 もう一度、Subversionの機能を見直してみた。 【1】ムービー企画「Subversionによるバージョン管理入門」 WEB+DB PRESS Vol.39誌面連動ムービー｜gihyo.jp … 技術評論社 最近のバージョン管理は、trunkとbranchの2系統のバージョン管理戦略を持つ傾向がある。 メインラインモデルと呼ばれる。 メインラインモデルの手法を使って、本番運用中の保守br
coLinux subversion問題 - walf443's blog
今まで普通に使えてたのに週末に研究室のサーバーが落ちてそれを再起動したらsvn commitで固まるようになってしまった。 最初は認証のキャッシュが原因なのかなと思って.subversion/auth/svn.simple/以下のファイルを削除してみたりしたのだけどうまく行かず。 これは困ったということで調べてみると、coLinux特有の現象らしい。 http://www.bookshelf.jp/2ch/linux/1078609142.html http://www2d.biglobe.ne.jp/~meross-k/diary/0406.HTM#200406112360 903 sage 04/11/04 18:27:08 id:NvIZ6WGh つづき： /dev/random coLinux で検索したら、ここに書いてありました。 http://www2d.biglobe.ne.
UNIX USER 2003 8: Subversionで管理せよ (draft)
オープンソースの開発においてCVSというバージョン管理システムは非常に重 要な要素の一つと考えられています。CVSを使えば、ネットワーク上に分散し た多数の開発者がうまく協調しながらソースを修正していくことが可能です。 オープンソースを開発をサポートしているSourceForgeではプロジェクトごと にCVSリポジトリが用意されていますし、SourceForgeなどを使っていないオー プンソースプロジェクトでも自分でCVSリポジトリを用意しているところが数 多く存在しています。 しかし、CVSを使いこんでいくとCVSによってあたえられる制約がいろいろと苦 痛になってきます。特にファイルの移動やディレクトリの扱いなどがうまく管 理できないことが開発のすすめ方に影響を与えていると言えるでしょう。特に 開発の初期段階では、ソースファイルのレイアウト構造などが固まっていない ために、その段階でCV
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
