これによって、次のような問題が発生します。 全員がtrunkに対してコミットするため一人のビルドエラーが全員を巻き込む 1つの機能開発が複数回コミットで完成するため、開発を続ける限り安定版を作ることが難しい 開発中コミットが頻繁に入るため、どこまでレビュー・テストしたか分からなくなる SVNはGitと違ってサーバー上のリポジトリのみなので、コミットによって他のメンバーにも影響が発生します。コミット漏れや、ビルドエラーとなるコミットが行われると、チーム全員がその影響を受けることになります。 コミットミスでエラーとなる図 また、複数機能や障害対応のコミットが入り乱れるため、「いつになれば安定版となるのか」「いったいどこまでレビューしたのか」などの管理が大変です。 実際問題、レビュー依頼されたけど忙しくてレビューできずに、バージョンブランチに移ってしまったみたいな事も発生していました。 ノーレビ
AboutAbout TortoiseSVNScreenshotsScreenshots of various dialogsTestimonialsWhat users say about TortoiseSVNNews ArchiveNews archiveSupportFAQFrequently asked questionsHelp filesThe complete documentationUseful tipsTips about not well known featuresMailing listsWhere to find the mailing listsReport bugsHow and where to report a bugTranslationsHelp translateProject statusOverview of releasesMiscIssu
Apache配下のsubversion(mod_dav_svn)で、クライアントからログを見ようとするととても遅く感じられます。これをスピードアップするネタです。 そのものズバリは以下のサイトの「VI.4.4.3. パス名にもとづいたチェックの禁止」にあります。 http://www.exacteye.com/svn/svn.serverconfig.httpd.html キーワードは SVNPathAuthz off です。Apacheのアクセス権限設定を参照しないようにする、という意味です。デフォルトでは on なのですが、このとき、ログに含まれるパス１つごとにApacheにお伺いを立てているのです。ありえねえ。 試しに自宅のリポジトリサーバでoffにしてみたら、爆速になりました。 しかし、細かく権限を設定しているようなサイトでは、この方法はオススメできません。とはいえ、subvers
☰ Apache® Subversion® "Enterprise-class centralized version control for the masses" Welcome to subversion.apache.org, the online home of the Apache® Subversion® software project. Subversion is an open source version control system. Founded in 2000 by CollabNet, Inc., the Subversion project and software have seen incredible success over the past decade. Subversion has enjoyed and continues to enjoy
本番反映が大変なので手順書をφ(..) gitでbranch使った開発が出来ればこんな苦労はしなくてもいいのに…言ってもしょうがないですけどねー 差分を出力する 対象リビジョンから最新リビジョンまでの差分をpatchファイルとして出力 ~~~ svn diff -r 対象リビジョン:HEAD -x -w > patch.diff ~~~ オプション -x -w というのはタブとインデントの違いを無視するというオプション 他にもオプションが色々 ~~~ -b スペースの数を無視する -B 空の改行を無視 ~~~ 複数指定したい場合はこのように書く ~~~ -x “-w -b -B” ~~~ patchをあてる ~~~ $ patch -p0 -E < patch.diff ~~~ patchは作成した時にpathを持っているので、同じ階層で実行する必要がある 成功した場合のメッセージ ~~~
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
※本稿は諸事情により過去の投稿を再投稿したものです。 はじめに 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 にも記載されてい
すでに Subversion は導入済みだったんだけど、SSL でログインして使うやり方だったので、これを Apache の WEBDAV として使う(http://でアクセスできる)ようにします。 インストール ググると dav_svn.conf という設定ファイルに svn系の設定を書くらしいのですが、そんなファイルはどこを探してもないため、当初のインストールが Subversion 単独だった模様。入れ直してみます。 $ s apt-get install subversion subversion-tools libapache2-svn subversion はすでに最新バージョンです。 以下のパッケージが新たにインストールされます: libapache2-svn subversion-tools Enabling dav as a dependency Module dav i
少人数チームでのソフトウェア開発でソースコードを管理するリポジトリにGitを適用して1,2ヶ月ほど経過しました。Gitを開発に使用するのは今回が始めてで、みなSubversionを使っていたメンバーです。 開発環境 OS Linux、たまにWindows 開発言語 Java プログラミングツール NetBeans 7.4 Gitクライアント NetBeans標準搭載のGit機能、たまにコマンドライン、WindowsではたまにTortoiseGit Gitサーバー apacheでgit-http-backend、Redmineと認証統合 現在の使用状況 Gitの共有リポジトリを、開発サーバー上にapache（HTTP）でホストしています。 共有リポジトリはmasterブランチ一本で、各メンバーはローカルにcloneしたあとローカルのmasterで変更作業を実施し、適宜共有リポジトリのmast
自作プラグインのSubversionリポジトリをプラグイン毎に設けていたのを止めて、一つのリポジトリにまとめることにした。その作業記録。 目次： 現状と希望 実現方法 実行時のエラー「期待されるファイルシステム形式は～」とその対処 エラー内容 原因 対処方法 リポジトリの統合を実行 環境 手順 実行するコマンド コマンド実行結果 検証 付録： コマンドヘルプ （Subversion 1.6.12） svnadmin help svnadmin –version svnadmin dump svnadmin dump （ver. 1.5.6） svnadmin load svnadmin create svn mkdir svnadmin upgrade svnadmin verify 現状と希望 現状： 昔の構成図だけど、ぼののPCのリポジトリ構成はこんな感じ。プラグイン毎にリポジトリを作
社内のバージョン管理をVisual Source Safe（VSS)から、Subversion(svn）にした経緯・苦労した点を書く。技術的な内容については、あまり書いてないので、ぐぐってくださいな。 1.VSSの課題 ユーザー毎にライセンス料がかかる Visual Studio,EclipseなどのIDEから使えない（つかいづらい） VSSのリポジトリがあちこちのサーバに点在してどこに何のリポジトリがあるかは担当者のみぞ知る サポートが切れてる（vss6。vss2005のメインストリームサポートは今年切れる） うちの会社は、昔vb6でアプリを作りまくっていたようです。その経緯からVSSが使われていました。（vb6にVSS6が付属してた）今でもvb6の資産も残ってますが、最近は.netもJavaも、さらにCOBOLのシステムもあったりします。 でも、そもそもユーザーごとに金かかるって、あり
プログラムをすべて自分たちで(開発チーム内で)管理しているあいだはよいのですが、 プログラムがだんだん大規模化してきて、ライブラリの一部を別のチームや 別の会社に作ってもらって、そのソースコードを納入してもらう、 ということもあるでしょう。 よそへ頼んだものは、すぐに完成してもらうことができれば話は早いですが、 なかなかそうはいきません。リリースまでの間、複数回に分けて 作りかけのものを受け取って、 できるところからテストを進めなければならない場合もあります。 さらに、納品してもらうものが専用に注文したものならよいのですが、 汎用的な製品のソースコードで、 納入物の一部分を自分たちでアレンジしなければならないかもしれません。 こんなときに、ライブラリの次のバージョンが届いたときに、そこへ これまでに組み込んだ自分たちのアレンジを何とか効率よく反映させたいものです。 (ご注意) このページを
コミットコメントを意地でも書かせたいと思うことがあります。 でも意外と書いてもらえなかったりします。 酷い場合だと バグ修正 とか 対応した だけ書いてあったりします。 注意するのも疲れるし、大抵の場合は注意しても直りません。 そんなわけで、私が面倒を見ている環境だとpre-commit-hooksを使って、規定のバイト数のコメント書かないとコミット出来ないようにして対応しています。 単にエラーだと障碍だと騒ぐ人達が居るので、コメントの重要性をエラーメッセージで語りかけるようにもしてたりします(笑) 以下はTracLightning環境下で動作する(はず)のScriptです。*1 キーワードの定期的な見直しは必要ですが、コメントを書かないとコミットできなくなるので意識付けを行うのには有用だと思います。コミットコメントが書いてもらえないと悩んでいる方は試してみては如何でしょうか。 ＃結構やっ
Trac のインストール
Trac を使ってみようかな、と思いました。 Trac のインストールとセットアップのメモです。一緒に Subversion もセットアップしました。 パッケージのインストール Debian なので apt-get 等で必要なパッケージをインストールします。 sudo apt-get install trac trac-ja-resource libapache2-mod-python subversion libapache2-svn Subversion のリポジトリ作成 Apache がアクセスできるようにオーナを www-data に変更します。 cd /var/lib sudo mkdir svn sudo chown -R www-data:www-data svn cd svn sudo -u www-data svnadmin create test-repo1 dav_s
Django と戯れていたのですが、どうもチュートリアルと 実際の動きが違うのではまっていたら・・・ apt-get じゃなくて、リポジトリから取得したものの 解説だったのね。 とうわけで、subversion をインストールしてモジュールを ダウンロードしようと思ったのですが、 proxy経由になるんですよね。。。 Subversionのproxy設定 http://www.proton.jp/apps/subversion.html apt-get install subversion vi ~/.subversion/servers [global] http-proxy-exception = プロキシを通さないホスト名 http-proxy-host = プロキシサーバのホスト名 http-proxy-port = プロキシサーバのポート番号 意外とお手軽でした。 早速、Djan
『入門Subversion Windows/Linux対応』サポート資料 本書 177 ページに記載されているリポジトリURLへの接続でエラーが表示されるというお問合せが数件ございます。 本件は、Subversion クライアントが proxy を通過できないために発生すると考えられます。対策の詳細につきましては、Subversionの開発元が作成するFAQに記載がございます。しかし、これは英語であるため、下記に参考日本語訳を用意させていただきました。問題解決の一助としていただければ幸いです。 なお、内容の運用につきましては、自己責任でお願い致します。 もしプロキシの背後にいたらどうなるの？ Subversion クライアントは設定によりプロキシを通り抜けることができます。最初に，どのプロキシを使用するかを指定する"servers"設定ファイルを編集します。"servers" ファイルの所
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Setup Subversion (SVN) on Ubuntu