タグ

subversionに関するftnkのブックマーク (55)

  • 分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project

    Joel Spolsky / 青木靖 訳 2010年3月17日 水曜 しばらく前に、ジェフと私はStack Overflowポッドキャストにエリック・シンクを迎え、バージョン管理について騒がしく議論し、とくにトレンディな分散バージョン管理システムであるMercurialやGitのことを取り上げた。 そのポッドキャストで私はこんなことを言った。「私に言わせれば、ブランチやマージが簡単にできるようになるというのは、単に同僚たちがもっとブランチやマージをするようになるということで、余計混乱させられるだけのことだよ」 わかると思うけど、あのポッドキャストは前もって入念に準備したりはしていない。単に2、3人集まって、いい加減なおしゃべりをしているだけだ。そのため、しばしば我々の主張する内容が、少し専門的な言い方をするなら、「ちげーよ」ということになる。間違っているのはたいてい細かい部分か趣旨のどちら

  • Redmine - Overview - Redmine

    Redmine¶ Table of contentsRedmineFeaturesDocumentationSupport & getting helpContributing and helping outWho uses Redmine?Redmine books Redmine is a flexible project management web application. Written using the Ruby on Rails framework, it is cross-platform and cross-database. Redmine is open source and released under the terms of the GNU General Public License v2 (GPL). Features¶ Some of the main

  • 仕様書をSubversionとTracで管理する - rabbit2goのブログ

    議事録をTracへ載せる話は「議事録はTracへ」に書いたけれど、今度は仕様書の話。ソフトウェア開発の構成管理にはSubversionを使っており、その中にはソースコードだけではなく、WordやExcelで作った資料も入れるようにしている。以前はサーバの共有フォルダに入れていたけれど、色々な面で問題が有ったのでSubversionとTracを使うようにした。目的は下記の通り。 仕様変更の確実な履歴管理 Wordファイル自体に変更履歴を管理する機能はあるけれど、ファイルを開いてみなければ分からないし、必ず履歴が残っているという保証も無い(誰かが変更箇所を承認してしまった等)ので、あまり使える機能ではない。確かに、短期的に変更点を知ってもらうには分かりやすくて便利なのだけど、長期的な保存に耐えうる機能ではないと思う。そこで構成管理へ入れるようにすれば、遙か昔の履歴も確実に残るので安心だ。 ソー

    仕様書をSubversionとTracで管理する - rabbit2goのブログ
  • 本番サーバにチェックアウトしちゃダメですか? - miauのブログ

    初歩的な管理ミスで3300もの有名サイトがソースコードを盗まれる この記事。まず訳がちょっと違うかな?という箇所があるのでそこを補っておくと。 しかしコードが実動サーバに乗る段階ではそれはローカルな作業用コピーではなく、エキスポートされた完成品だから、この問題が起こる。 こう訳されてる箇所があるけど、 When code is rolled to a live server from a repository, it is supposed to be done as an export rather than as a local working copy, and hence this problem. 実働サーバにコードを載せる場合は、ローカルな作業用コピーとして取得するのではなくエクスポートするべきだ。(だが今回はローカルな作業用コピーを番に置いているので)問題になっている。 み

    本番サーバにチェックアウトしちゃダメですか? - miauのブログ
  • 「.svn」「CVS」ディレクトリを狙ってWebサイトの非公開ファイルをゲット | スラド セキュリティ

    TechCrunchの記事「初歩的な管理ミスで3300もの有名サイトがソースコードを盗まれる」によると、ロシアセキュリティグループが、「.svn」や「CVS」といったSubversionやCVSの管理ディレクトリを狙ってWebサイトの非公開ファイルを盗み出す手法により、3300あまりのWebサイトのソースコードを入手することに成功したそうだ。 原理は簡単で、Webサイトでうっかり公開されてしまっている.svnや.cvsといったディレクトリを探し、発見したらその中身のデータを吸い出すだけ。確かに言われてみればうっかり見逃しそうなミスではある。皆様もご注意くださいませ。 (追記@14:50)原文では.cvsとなっているが、コメント#1644247で指摘されているとおり、CVSの管理ディレクトリは「.cvs」ではなく「CVS」である。

  • 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のバイナリを素直にインストールしました。インストールすると

    tips - svnメイン、でもgithubでも公開したい場合の最小手順 : 404 Blog Not Found
  • Subversionリポジトリと連携できるgit-svn | OSDN Magazine

    「Gitを使いたいが、中央リポジトリにはSubversionを使わざるを得ない」という場合も多いだろう。そのような状況で便利なのが、SubversionリポジトリとGitリポジトリの橋渡しをする「git-svn」である。git-svnを利用することで、SubversionリポジトリとGitのローカルリポジトリを同期させることが可能だ。記事では、このgit-svnの活用方法を紹介する。 git-svnのアーキテクチャ Gitの大きな特徴として、分散型アーキテクチャがある。分散型アーキテクチャでは、コミットはローカルのリポジトリに対して行い、ソースコードの同期はそれぞれの開発者間が持つローカルリポジトリ同士で変更点をやりとりすることで行う。もちろん公開リポジトリを利用したソースコードの同期も可能であり、柔軟な開発体制を取れるのが長所である。 しかし、一方でGitは非常に多数のコマンドがあり、

    Subversionリポジトリと連携できるgit-svn | OSDN Magazine
  • Subversionリポジトリのバックアップ方法いろいろ - ぱせらんメモ

    Subversionリポジトリのバックアップ方法が色々ありすぎて何がベストなのかわからなかったので調べてまとめてみた。 ただのファイルコピー 普通にファイルシステム上でディレクトリをコピー(あるいはアーカイブ)する方法。非推奨。 誰かがリポジトリにアクセスしている最中にやると壊す可能性がある。 リポジトリディレクトリをコピーしたいならsvnadmin hotcopyを使うべき。 長所 簡単。 速い。 短所 バックアップデータの可搬性に乏しい(アーキテクチャ依存)。 リポジトリをロックしないので壊す可能性がある。 データエラーが検出できない。 svnadmin dump/load svnadminのdumpとloadを使う方法。 誰かがアクセス中でも一貫性が保たれる。 あくまで管理対象のファイルのみのバックアップなので、設定やフックなどは別途バックアップが必要となる。忘れがち。 差分バックア

    Subversionリポジトリのバックアップ方法いろいろ - ぱせらんメモ
  • dsvn.elでemacsでsubversion

    こんにちわ。arashoです。 emacs使いの皆さんはsubversionを使用するときは何を使っているのでしょうか? シェルからコマンドラインベースでったりpsvn.elだったりでしょうか。 普段emacsを使っている身ですが、物覚えが悪いせいでpsvn.elのコマンドを覚える気になれず、今まではシェルを使用していました。 最近知ったのですが、ありえるりあさんのブログエントリでdsvn.elを知り、使用してみて使い勝手が良かったので紹介します。 基的にはpsvn.elと変わりはないというのですが、何がよいかというと、初心者に優しいのです。 以下の画像をご覧ください。 これは、M-x svn-statusしたあとに?で表示されます(右端が赤いのは行末の余白を目立つようにしているためでdsvn.elとは関係ありません)。初心者にはありがたい機能ですね。 あとは下段のヘルプを見なが

  • checkoutしたファイルのmtimeを、そのファイルがcommitされた時刻に合わせたい ― svnとgitの場合 - (ひ)メモ

    唯一の中央レポジトリと複数のcheckoutするノードというトポロジの場合、checkoutしたファイルのmtimeがノード間で同じ時刻(当該ファイルがcommitされた時刻)になっているとなにかと都合がいいです。 例えば、Webアプリのデプロイを中央レポジトリからのcheckout(やupdate)で行う場合を考えます。もし、内容が同じなのに複数あるアプリサーバの間でmtimeが異なってしまっていると、 サーバごとにETagヘッダの値が異なってしまう ※Apacheの場合、FileEtagディレクティブを調整(mtimeを見ないように)することによって統一可能ではあります サーバ間でrsyncをかけると無駄なファイルコピーが発生する 内容が同じににもかかわらずmtimeが異なるせいでコピーが発生する ※--size-onlyオプションでmtimeを見ないようにして回避可能ではあります と

    checkoutしたファイルのmtimeを、そのファイルがcommitされた時刻に合わせたい ― svnとgitの場合 - (ひ)メモ
  • SubversionとTracでファイル管理の“迷宮”から脱出

    SubversionとTracでファイル管理の“迷宮”から脱出:ユカイ、ツーカイ、カイハツ環境!(2)(1/4 ページ) プロジェクトで修正/仕様変更が“迷宮”入りする理由 ソフトウェア開発を行ううえで、設計書やソースコードのバージョンをきちんと管理することは非常に重要です。構成管理(ファイル管理)を行っていないプロジェクトでは、例えば次のような問題が発生します。 2人以上の開発者が同時に成果物を編集した場合、後に編集を始めた開発者がすでに編集を行った開発者の編集内容を上書きしてしまう。結果として、修正したはずのバグや変更したはずの仕様が、設計書やソースコードに反映漏れするという事態が発生 設計書やソースコードのレビューを行って修正したはいいが、どこをどう修正したのか分かりにくく、レビュー内容の反映の確認を行っても修正漏れや修正誤りに気が付かない ソースコードを変更すると、動かなくなってし

    SubversionとTracでファイル管理の“迷宮”から脱出
  • Subversion設定の標準化

    ディノ社内のバージョン管理は主にSubversionを利用しています。また、社内の開発環境はWindowsMacLinuxが入り乱れています。そんな環境で、一番問題が少なそうなSubversionの設定を考えてみました。現在これを社内標準として運用していますが、今のところ大きな問題は起きていません。 設定内容ですが、auto-propsとglobal-ignoresの設定です。各種ファイルについて、eol-style=nativeやkeywords=Idやsvn:mime-typeなどを設定します。 ちなみに、設定はsymfonyの公式オススメ設定「Symfony Repository Tips」から大半を流用しています。 設定内容 設定内容はsubversion-config.txtの通りです。同じ内容を以下に貼付けておきます。 [helpers] #diff-cmd = dif

  • 【特集】使ってる? Issue Tracking - trac 楽々ことはじめ (1) パニックプロジェクトを生まないために | エンタープライズ | マイコミジャーナル

    プロジェクトの情報共有を支えるための重要なタスクにドキュメンテーションと文書管理がある。あなたのプロジェクトでは適切な文書管理がなされているだろうか。通常、プロジェクトからは日々多くの種類/フォーマットの文書が生み出されている。そのため、文書管理に統制の無いプロジェクトでは、どこにある何を見ればいいのかを把握することでさえ、たちまち容易ではなくなってしまう。 プロジェクトに関する情報が増えてくる前に、一人でプロジェクト開発に従事しているあなたも、チームで開発をしているあなたも、散在する情報を整理したいと考えることだろう。 「今、プロジェクトで何が問題になっていて、何を片付けないといけないか」という情報群--ToDoやタスクリストとも表現できるこれらの情報群は、プロジェクト中のさまざまなシーンで出現し、これが管理されていないプロジェクトは、ほぼ確実に混乱に陥る。問題管理で取り扱う情報の種類は

  • 10分で作る、Subversionレポジトリ - Unix的なアレ

    バージョン管理システムにはCVSやsubversionなど様々なものがありますが、サーバーのセットアップに抵抗がある人もいるのではないでしょうか? しかしながら実際のところ、パッケージ化されているので驚くほど簡単にできてしまいます。 今回は、もっとも簡単な手順でSubversionのレポジトリサーバーを構築する方法を紹介したいと思います。 動作環境 今回の手順の動作環境は下記のとおり。OSをインストールしたままの、まっさらな状態を想定しています。 OS Debian Linux etch Protocol http Web Server Apache2.2.3 それでは早速いきましょう。当に10分間で構築できます。 パッケージのインストール 下記の作業はすべてrootで作業をするものとします。(まっさらな状態を想定しているため、sudoは利用していません。) それでは必要なパッケージをイ

    10分で作る、Subversionレポジトリ - Unix的なアレ
  • WindowsでSubversionを使う:TortoiseSVNでバージョン管理 | OSDN Magazine

    Windows環境でSubversionによるバージョン管理を行いたい場合に便利なのが、GUIでリポジトリにアクセスできるTortoiseSVNだ。記事では、TortoiseSVNの導入から基的な使用方法までを解説する。 図1 TortoiseSVN TortoiseSVNをインストールする TortoiseSVN(家)は、Windows 2000/XP/Vistaで動作するSubversionクライアントである。エクスプローラーの拡張機能としてインストールされ、エクスプローラーからGUIでファイルのチェックアウトやコミット、アップデートといった作業を行えるのが特徴だ(図1)。 TortoiseSVNはSourceForge.JPのダウンロードページからダウンロードできる。32bit版と64bit版のバイナリインストーラが用意されているほか、UIを日語を含む各種言語に対応させるLa

    WindowsでSubversionを使う:TortoiseSVNでバージョン管理 | OSDN Magazine
  • moccur-grep-find で .svn 以下のファイルを無視する | フッ君の日常

    Emacs でソースコードの検索/置換をするときに欠かせないのが moccur-edit 。 すごく便利で重宝してるんだけど、moccur-grep-find を実行したときにバックアップファイル(ファイル末尾が "~")とか .svn 以下のファイルまで引っ掛けてしまうので、.emacs にこんな感じで無視するファイルの設定を追加している。 (setq dmoccur-exclusion-mask (append '("\\~$" "\\.svn\\/\*") dmoccur-exclusion-mask)) これで、上記のファイルは無視されるようになる。 # 「svk とか git 使ったら?」というツッコミはスルーするのでよろしくw ちなみに、デフォルトの dmoccur-exclusion-mask の設定は以下のような感じ。 (defcustom dmoccur-exclusio

    moccur-grep-find で .svn 以下のファイルを無視する | フッ君の日常
  • おまぬけ活動日誌(2008-07-13)

  • git-svnを使って既存のSVNリポジトリでGitを使う方法のメモ - Hello, world! - s21g

    既存のSVNリポジトリを使いつつ、ローカルではGitの利便性を享受するために、 git-svnを使う方法のメモです。以下はopenid-fuのリポジトリを使った例です。 まずは普通にSVNリポジトリにファイルをimportしておきます。既存のものがある場合はそれを使います。 git-svnでリポジトリをcloneします。

  • Open Tech Press | コード開発プロジェクトにおけるソース管理システムの正しい利用法

    ソース管理システムの適切な使いこなしはプログラマにとって重要なスキルの1つであるが、その習得となると、実務の現場での経験と試行錯誤を通じて身につけるしかない。そのため学生や趣味のプログラマにとって、こうしたシステムの習得は時間がかかる以上に苦痛を伴う作業のはずだ。よって稿では、ソース管理システムの初心者が陥りやすい落とし穴および、それらを回避するためのベストプラクティスを具体例とともに解説することにする。 ソース管理システムを使用する質的な目的は、プログラマに余分な負担を掛けることなくプログラミング作業に集中させることである。そして開発対象のソフトウェアに追加した変更が思っていた程の効果を発揮しなかったり、あるいは追加そのものが間違っていたという場合でも、ソース管理システムを使用していれば最後にチェックインしたバージョンへと即座に復帰させることができる。またコードベース開発を複数のプロ

    Open Tech Press | コード開発プロジェクトにおけるソース管理システムの正しい利用法
  • subversionリポジトリを自動で作るスクリプト(株式会社RYUS スタッフblog) - XOOPS専門-株式会社RYUS

    今日からスタッフBLOGに参加する事になりました。haltです。 Subversionなどのバージョン管理システムでリポジトリを追加する時、 マニュアルから手順を見て覚えても、リポジトリを追加する時なんてそう毎日あるものでもないのですぐに手順を忘れてしまいます。 毎回調べるのも面倒だし、手順に違いがでて他のリポジトリと構成を変えてしまうと使う時にいちいち構成をチェックする必要があるので 以下のようにシェルスクリプトにしておいて、初期設定をまとめて実行するようにしています。 #!/bin/sh if [ -z $1 ]; then echo "Usage:$0 [project_name]" exit fi sudo svnadmin create --fs-type=fsfs /var/lib/svn/$1 sudo chmod -R 777 /var/lib/svn/$1/db s