こんにちは、やまなかです。 今回はサーバー上の関数を実行するためのプロトコル（通信規格）であるRPC (Remote Procedure Call) を実現するため、Googleが開発したgRPCについてまとめていきます […]
8/11にGitの脆弱性 ( CVE-2017-1000117 )が出ていました。 CVE-2017-1000117 - Red Hat Customer Portal これは、gitクライアント上での任意のshellコマンド実行の可能性があります。 重要度 - Important Gitでの"ssh"URLハンドリングにshellコマンドインジェクションの欠陥が見つかりました。これを利用して、悪意のあるレポジトリや悪意のあるコミットを行われたをレポジトリに対して"clone"アクションをGitクライアントで実行した際に、Gitクライアントを実行したユーザの権限でshellコマンドを実行される可能性が有ります。 Gitの脆弱性 ( CVE-2017-1000117 ) — | サイオスOSS | サイオステクノロジー 実際にどんなことが起きるか 百聞は一見にしかず。 このリポジトリを cl
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
自分はバージョン管理システムとしてgitを利用してます。 プロジェクトで採用しているバージョン管理システムがSubversionの場合でもgit-svnで連携して生活してます。 今関わっているプロジェクトのsubversion上の構成がgit-svnにとって扱いづらいものが採用されていて、それの対処方法についてまとめておきます。 前提のプロジェクト構成 現在関わっているプロジェクトのバージョン管理システムでは以下のようなブランチ構成になっています。 branches/A/subA1 branches/A/subA2 branches/A/subA3 branches/B/subB1 branches/B/subB2 branches/B/subB3 branches/C/subC1/subsubC1-2 branches/C/subC1/subsubC1-2 branches/C/subC
※本稿は諸事情により過去の投稿を再投稿したものです。 はじめに git-svn を使うと、素直な SVN リポジトリーなら簡単に移行できますが、実運用してきた SVN リポジトリーを移行する際はつまづくことも多々あります。 また Git リポジトリー化ができてもブランチやタグは手作業で作ることになります。 今回、たまたま移行を検討する機会があったので、その予行作業のなかで得た知識をメモしておきます。 作業を行ったクライアント環境は Ubuntu 14.04 / Git 1.9.3 です。 SVN リポジトリーは HTTPS でアクセスできる状態です。 移行の第一歩 まずは SVN リポジトリーからローカル環境に Git リポジトリーを作成します。 git svn clone または git svn init + git svn fetch を使います。 ヘルプや Book にも記載されてい
集中型バージョン管理システム（以下CVCSとする）と分散型バージョン管理システム（以下DVCS）って何がどうよかったり嬉しかったりするのだろうか。というようなことをつらつら考えてみた。きっかけは、gitの話とか、そのあたりから。（gitって難しいのかなー http://d.hatena.ne.jp/hyoshiok/20140201/p1 ） バージョン管理システム（VCS）のキモは複数人での共同開発を支援するということにつきるかと思う。http://d.hatena.ne.jp/hyoshiok/20140204/p1 一人で開発していればコミュニケーションロスはないので、ひたすらズンズン開発するだけである。一方で複数で開発していれば、どのようにしてコードを共有し統合しテストするかという問題があって、その作業を支援するのがVCSやソフトウェア構成管理と呼ばれるものである。ソフトウェア構成
前回の記事がものすごい勢いでかきかけですが、こんばんは。 もともとはひとりで開発していてGitを利用していて途中でSubversionのリポジトリを用意する必要ができたのでその際に行ったことを書いておきます。 まず、Subversionのリポジトリを用意します。 環境しだいだと思いますが、例を書いておきます。 svnadmin create [svnリポジトリ] --fs-type fsfs svn mkdir [svnリポジトリ]/trunk [svnリポジトリ]/branches [svnリポジトリ]/tags -m "make directory for branches"プロジェクトのリポジトリに移動して以下の用な作業をします。 git svn init [svnリポジトリ] -T trunk -b branches -t tags git svn fetch # リポジトリから取
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
Subversion リポジトリの場所が変わった場合、 svn switch --relocate 旧リポジトリ 新リポジトリ というコマンドで、リポジトリの再配置ができるのだけど、 Subversion リポジトリを git svn を使って管理している場合はどうすればいいのか分からなかったので調べてみた。 コマンドは存在しない google 先生にお伺いを立ててみたところ、 [git][svn]git-svn使用時におけるsvnリポジトリの移行 ( http://d.hatena.ne.jp/walf443/20090811/1250005053 ) git svn での switch のやりかた ( http://d.hatena.ne.jp/naga_sawa/20110306/1299422744 ) というのは見つけた。どうやら、 svn switch --relocate に
subversionのリポジトリをgitに変換はよくあると思うが、gitのリポジトリをSubversionに変換というのを今回やりたい。 というのも、何度もいっているが、中央には、Subversionで、各ワークをgitで私は使いたいからだ。 （これは、Tracとはviewvcとか、すでに構築してしまった環境を変えるのも面倒というのもある。） しかし、今回はとりあえず、ネットにつながっていない環境で初めてしまったgitのリポジトリをSubversionに変換して、 再度、git-svnで再開したいのだ。 こんな用途を持っている人はあまりいないのか、WEBで方法を探したがすぐには見つからなかったので、 自分なりに、次のような手順でログ情報だけでも取り込むことにした。 Subversionのリポジトリを作成 ここでは、Subversionでのリポジトリを作成する方法は述べない。 で、s
思いは言葉に。 はてなブログは、あなたの思いや考えを残したり、 さまざまな人が綴った多様な価値観に触れたりできる場所です。
Trac 0.12 Install Memo Trac 0.12 を CentOS 5.5 i386 サーバに Apache + mod_python で新規インストールする。 処理速度を求めるなら、lighttpd + FastCGI だが、個人目的での利用なので手軽さを優先した。 必要なパッケージは、できるだけ rpm で管理する。 subversion Trac と subversion を連携させるために、まず subversion をインストールする。 subversion を使わない場合は省略可能。 install # yum install subversion mod_dav_svn Installing : apr Installing : neon Installing : postgresql-libs Installing : perl-URI Install
gitで始めたプロジェクトをSubversionのリポジトリにしたかったのだが、どうやったらいいのか調べてもよくわからない。 Subversionからgitはよくあるのにねー。 試行錯誤の結果とりあえずうまくいったっぽいので記録を残しておく。 これで大丈夫なのかどうかはよくわからない。 きっとid:bleis-tift先生がなんとかしてくれるハズ！ gitからSubversionへ 移行先となる新しいSubversionリポジトリを用意する。 svnadmin create foo んで、コミットがないとうまくいかない感じだったのでtrunk,branches,tagsを作っておく。 svn checkout http://localhost/svn/foo foo cd foo mkdir {trunk,branches,tags} svn commit -m "init" なんかfil
複数のsvnリポジトリを一つにまとめる方法 うちのsvnリポジトリは、trac等で公開をする前までは、各コンポーネント毎にリポジトリを作るという非効率な管理をしていました。 そろそろ嫌になって来たので、これを全部公開用にまとめようと思い、helpみながら頑張りました。 要件的には、リビジョン番号が変わっても良いから、とにかくlogを含めてインポートしたい！ という感じです。 最初はsvkとか使わなきゃだめなのかなぁ、とか思ってたのですがsvnadminだけで願いが叶いました。 dumpとloadを使います。 loadする時はオプション無しでloadしてしまうと、dump前のファイルパスにデータをぶっ込んでくれちゃうので、trunkとかが混ざってカオスになっちゃいました。 そこで--parent-dirオプションを使って、どのパスにloadするかを明示的に指定してloadします。 --par
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
