Yoheis.net: リバースプロキシ背後のWebDAVサーバでリネームできない
20070817 リバースプロキシ背後のWebDAVサーバでリネームできない Mac OSXにapacheをインストールし，WebDAVサーバをたてたのだが，ファイルやディレクトリのリネームができない．いろいろ検索して調べたところ， Subversion behind an Apache Reverse Proxy subversion: Mail reader あたりがヒット．リバースプロキシの背後にあるWebDAVサーバに対してSubversonからリネームできない問題への対処が書いてある．今回の件もこれと同じであった． リバースプロキシがhttpsで，WebDAVサーバがhttpの場合にこの問題が起きる．WebDAVのMOVEメソッドでは，ファイルの移動先はリクエストヘッダDestinationに書かれる．これが，例えばhttps://dav.example.com/destinat
Pro Git進行中 - m-takagiの日記
『オープンソースソフトウェアの育て方』がひとまず落ち着いたので、次のネタとしてScott Chaconの「Pro Git」の翻訳に参加しています。『入門Git』発売記念ということで、便乗して晒しておこう :-) Pro Git 作者: Scott Chacon出版社/メーカー: Apress発売日: 2009/08/27メディア: ペーパーバック クリック: 20回この商品を含むブログ (2件) を見る GitHubの中の人でもある著者は、今年のRubyKaigiにも登場していたので、実際に話を聴いた人も多いかもしれません。私を含む数名の共同作業で翻訳を進めており、とりあえず前半部分をひととおり訳し終えたところです。 原文 (そのソース) 日本語版 (私の作業用リポジトリ) 書籍の内容がウェブで公開*1されているという、「オープンソースソフトウェアの育て方」のときとよく似たパターンですな。
GitHubの登場はコミッタを特権階級から追い落とす革命だった - Hello, world! - s21g
弊社は、deployツールとしてcapistranoを使っています。 しかし、Capistranoのメンテナンスが終了するという話("Jamis Buck氏, CapistranoやSQLite/rubyの開発を終了"参照)を聞いても、 特に困らないという事に気がついて、あらためて驚きを感じました。 なぜだろうと考えてみると、それはGitとGitHubの存在による所が大きい。 GitHubにソースがある限り、メンテナが不在でも勝手にforkして 野良patchを書いたり、それを集めてきてちょっとした stable release的なものを作ったりする事ができてしまう。 もちろんそれは、今までだって頑張れば出来た事だけれど、 Git/GitHubは、それを全く違う次元で簡単にしてしまった。 かつてはメンテナやコミッタが専権的にソフトウェア開発の決定権を握っていた構造が、Git/GitHubの
tips - svnメイン、でもgithubでも公開したい場合の最小手順 : 404 Blog Not Found
2009年04月02日03:30 カテゴリTips tips - svnメイン、でもgithubでも公開したい場合の最小手順 というわけで、遅ればせながらgithubはじめました。 dankogai's Profile - GitHub のですが、正直どうもgitにはとっつけない。RCS → CVS → subversion というのは、コマンド体系も互換性が高い正常進化でとっつきやすかったのですが、gitはそもそも考え方からして違うということも大きいかと思います。 というわけで、とりあえずひきつづき subversion をメインに使いつつ、githubでも公開したい場合どうしたらいいのかという備忘録を。 gitクライアントの入手 入手は以下から。 Git - Fast Version Control System 私はOS Xのバイナリを素直にインストールしました。インストールすると
デブサミ2009 はてなの開発戦略 - 2nd life (移転しました)
先日のデブサミ2009で発表した、はてなの開発戦略 (すごい名前だ…) のプレゼン資料を公開します。前半は主に git の話で、後半ははてなブックマークリニューアルの、Perl 層の開発をどんな感じで行っていったか、という話です。 デブサミ2009 はてなの開発戦略View more presentations from hotchpotch. はてなの git では、中央のマスタレポジトリサーバがあって、そこから各自 clone / fetch して開発を行ってるので、完全に github のような分散のメリットを生かしているわけではありません。 しかし完全に分散を生かさずとも、git に移行したメリットは十分にあって、資料の中でもふれていますが、やはり一番便利なのが git のブランチ機能です。もうこれ無しでの開発は考えられないなぁ、ぐらいで、さくっとブランチ切って開発、ブランチの切り
Linus「C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが 簡単に生産されるようになってる」
/15 [4] (21:54) 原文: http://lwn.net/Articles/249460/ From: xxx To: xxx Subject: Re: [RFC] builin-mailinfo.c をマシな文字列ライブラリを使うようにすること Date: Thu, 6 Sep 2007 18:50:28 +0100 (BST) Message-ID: <alpine.LFD.0.999.0709061839510.5626@evo.linux-foundation.org> On Wed, 5 Sep 2007, Dmitry Kakurin wrote: > > Git のソースコードを最初に見たとき、ヘンだと思ったこと: > 1. C++ じゃなくてただの C を使ってる。理由は謎。移植性がどうとか言わないで、 > そんなのウソに決まってるから。 *あんた* のほうこそ
checkoutしたファイルのmtimeを、そのファイルがcommitされた時刻に合わせたい ― svnとgitの場合 - （ひ）メモ
唯一の中央レポジトリと複数のcheckoutするノードというトポロジの場合、checkoutしたファイルのmtimeがノード間で同じ時刻(当該ファイルがcommitされた時刻)になっているとなにかと都合がいいです。 例えば、Webアプリのデプロイを中央レポジトリからのcheckout(やupdate)で行う場合を考えます。もし、内容が同じなのに複数あるアプリサーバの間でmtimeが異なってしまっていると、 サーバごとにETagヘッダの値が異なってしまう ※Apacheの場合、FileEtagディレクティブを調整(mtimeを見ないように)することによって統一可能ではあります サーバ間でrsyncをかけると無駄なファイルコピーが発生する 内容が同じににもかかわらずmtimeが異なるせいでコピーが発生する ※--size-onlyオプションでmtimeを見ないようにして回避可能ではあります と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
jugyo.org