動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
svnで管理している、あるディレクトリを削除しようとしたときに $ svn rm https://example.com/svn/branches/hoge/fuga/piyo -m 'delete piyo'とやるべきところを、指定するディレクトリを間違えて $ svn rm https://example.com/svn/branches/hoge -m 'delete piyo'と、branchまるごと消してしまった。 復元するのに、 $ svn co https://example.com/svn/branchesと一度チェックアウトして(git-svn使っていたのでsvnのワーキングディレクトリは手元になかった)、消してしまうまえのリビジョン番号Mを調べて $ svn merge -r HEAD:<M> .と逆マージで復元させる、ということをしたのだけど、全ファイルを一つずついち
SubversionとTracでファイル管理の“迷宮”から脱出：ユカイ、ツーカイ、カイハツ環境！（2）（1/4 ページ） プロジェクトで修正／仕様変更が“迷宮”入りする理由 ソフトウェア開発を行ううえで、設計書やソースコードのバージョンをきちんと管理することは非常に重要です。構成管理（ファイル管理）を行っていないプロジェクトでは、例えば次のような問題が発生します。 2人以上の開発者が同時に成果物を編集した場合、後に編集を始めた開発者がすでに編集を行った開発者の編集内容を上書きしてしまう。結果として、修正したはずのバグや変更したはずの仕様が、設計書やソースコードに反映漏れするという事態が発生 設計書やソースコードのレビューを行って修正したはいいが、どこをどう修正したのか分かりにくく、レビュー内容の反映の確認を行っても修正漏れや修正誤りに気が付かない ソースコードを変更すると、動かなくなってし
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
前回の設定からの続き。 おさらいとしては、 Subversionはリポジトリごとにリビジョンが更新される。 つまりプロジェクトごとにリポジトリを作成しないとリビジョン管理が大変。 Subversionにsvn+sshで接続する前提でリポジトリ作成 と言う事で、リポジトリ作成の方法を前回から以下のように変更した。 面倒くさいので、簡単なシェルスクリプトを作成。 #!/bin/bash 〜余計なものは省略〜 REPOS_NAME=./$1 # make repository mkdir $REPOS_NAME svnadmin create --fs-type fsfs $PWD/$REPOS_NAME # make management dir # mkdir -p $REPOS_NAME/branches # mkdir -p $REPOS_NAME/tags # mkdir -p $RE
[git] subversionのブランチへコミット
メモ代わり。てきとーに。 いや、ですからてきとーですって。 2年前ぐらいにPythonあたりでメールくれた方、ごめんなさい。メール紛失してしまい無視した形になってしまいました。。。 メモ。 $ git branch -r MOD_CHXJ RELEASE_0_1_0 RELEASE_0_1_1 RELEASE_0_1_2 RELEASE_0_2_0 RELEASE_0_2_1 RELEASE_0_5_0 RELEASE_0_6_2 RELEASE_0_7_0 RELEASE_0_8_0 RELEASE_0_9_0 UNSTABLE_0_4_0 tags/MOD_CHXJ_0_1_0 tags/RELEASE_0_6_0 tags/RELEASE_0_6_1 tags/RELEASE_0_8_1 tags/RELEASE_0_8_3 tags/RELEASE_0_8_5 tags/RELEA
urlは、.svn/entriesの中に。 $ head entries switchサブコマンド $ svn sw --relocate svn://192.168.1.210/home/postteen/svn/repos/e500_2 svn+ssh://192.168.1.5/home/postteen/svn-repos/e500_2 .
必要なもの % sudo apt-get install apache2-mpm-worker libapache2-dav-svn apache2-mpm-workerはapache2-mpm-*のうちの どれか。 設定 /etc/apache2/mods-available/以下にあるsvn関係の設定 ファイルへのリンクを/etc/apache2/mods-enabled/以下に作成． あれ，dav_svn.loadのなかで，LoadModuleがコメントアウトさ れているなぁ．なんでだろう． % cd /etc/apache2/mods-enabled % sudo ln -fs ../modes-available/*dav* ./ /etc/apache2/httpd.confに以下を追加．うーん， /etc/apache2/mods-available/dav_svn.conf
Solaris10になって、サービスの管理はSMFで行うようになりました。サービスの管理方法が統一されてとても便利ではあるのですが、いざ自分でサービスを登録しようとすると、XML形式のマニフェストファイルなど、覚えなければいけないことがいろいろと出てきます。ここでは特定のサービスを題材にSMFを勉強していきたいと思います。
Subversionのセットアップから、基本的な操作方法を説明します。 Subversion概要 ソースコードのバージョン管理システムは、ソフトウェアの開発の中でもっとも重要なツールです。チームで開発を行なうときにソースコード管理システムは必須のツールの一つですが、ソースコードだけでなく様々なフィアルも管理できます。単にチームとしての利用だけでなく、個人のツールとしても威力を発揮します。筆者も、個人でバージョン管理システムを導入して、原稿やサーバの設定ファイルなどのドキュメントの管理をしています。 バージョン管理システムとして、以前はCVSが多くのプロジェクトで利用されていました。しかし、CVSは履歴を保持したままでのファイルの移動ができないなどの問題もありました。SubversionはCVSが抱えていた問題を解決するために開発されました。現在では、多くのプロジェクトでSubversion
Subversionクライアントを動作させるためには apr(Apache Portable Runtime) apr-util neon swig という、これらの別ライブラリをインストールした上で、Subversionを入れる必要があります。 最初それを知ったときは、あまりの多さに冗談かと思いましたが、どうやらこれら全部必要なようです。 てか、端折ってやったら、見事に動かなくなりました :-p apr cd $HOME/local/src wget http://ftp.kddilabs.jp/infosystems/apache/apr/apr-1.2.9.tar.gz tar zvxf apr-1.2.9.tar.gz cd apr-1.2.9 ./configure --prefix=$HOME/local --disable-static make make install
＼閉鎖予定のサイトも売れるかも？／ アクセスがないサイトもコンテンツ価値で売れる場合も… ドメインの有効期限を更新してサイト売却にトライしてみましょう
ここでは、Subversionのレポジトリに外部からアクセスする手段を与えるサーバの設定について説明します。ここからは、このサーバをSubversionサーバと呼びます。Subversionサーバを構成する方法として、独自のプロセスを起動する方法とApache HTTPサーバに組み込む方法があります。独自のプロセスを起動する方法は単純な構成となります。一方、Apache HTTPサーバに組み込む方法は多少設定が複雑になりますが、独自のプロセスよりも柔軟にアクセス制御ができることやHTTP経由でサービスを提供するためWebブラウザからレポジトリを閲覧できることなど多くの利点がありますので、ここではApache HTTPサーバに組み込む形式を採用します。 Subversionサーバとして動かすApache HTTPサーバの前提バージョンは2.0系です。この最新バージョンをインストールしてくだ
メモ 使用したバージョン Apache 2.2.0 Subversion 1.3.0 インストールするディレクトリ Apache /usr/local/apache2 Subversion /usr/local/subversion Apacheインストール † # cd /usr/local/src # wget http://example.com/httpd-2.2.0.tar.bz2 ←最寄りを。 # tar jxf httpd-2.2.0.tar.bz2 # cd httpd-2.2.0 # view INSTALL ←とりあえず読んで。 # ./configure --enable-so --enable-dav ←この二つは必須。 # make # make install # /usr/local/apache2/bin/apachectl start 〜 動作確認 〜 #
はてなと時期を同じくして clouder.jp も自宅サーバからさくらインターネットに移行しまして、Subversion と Trac をインストールしたのですが結構苦労したので覚え書きとして残しておきます。 とりあえず、Subversion と Trac のインストールに必要なソフトウェアは以下です。今回インストールしたバージョンも記しておきます。 ちなみに今回インストールしたサーバはFreeBSD 6.1で、Perl、Python、Ruby はインストール済。でも Trac は Python だけあれば動きますので、Perl と Ruby はインストールされてなくてもよいです。 Subversion関連 neon-0.25.5.tar.gz swig-1.3.31.tar.gz subversion-1.4.2.tar.gz Trac関連 httpd-2.0.59.tar.gz sql
動機 よし、Subversion を使ってみるか…と思い、Fedora Core 3 の評価もかねてインストールしてみました。 そもそもの目的は、Eclipse の Subclipse でのバージョン管理なのですが（move/rename がしたかったんです）、 Fedora Core 3 では FSFS レポジトリが利用できる Subversion 1.1 でパッケージが作ってあったので、ついでに Fedora Core 3 も試してみようと思った次第です。 が、SELinux が有効の状態では、レポジトリに対する書き込みができないため、すんなりと使うことができませんでした。 せっかくの SELinux を無効にするのももったいないと思い、SELinux のポリシーを作って使えるようにしてみました。 Subversion を使わなくても、WebDAV を利用しようと思ったら同じような作業
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
