[ThinkIT] 第2回：Subversionによるバージョン管理（前編） (1/3)
今回は、Subversionによるバージョン管理方法とウノウでの導入事例について前編と後編にわけて紹介していきます。 Subversionとは、無償で利用できるバージョン管理システムです。現在もオープンソースで活発に開発が進んでおり、執筆時点の最新バージョンは1.4.2となります。バージョン管理システムとは、ソースコードや仕様書などを含むドキュメントなど、時間とともに内容が変化するファイルを管理するシステムの総称です。 Subversionと同じようなバージョン管理システムとしては、CVS（Concurrent Version System）が有名ですが、SubversionではこのCVSで使いにくかった点を改良した次世代バージョン管理システムというコンセプトで開発が続けらています。筆者が実際にどちらも利用してみた結論として、導入をおすすめするバージョン管理システムは、やはり「Subver
SVNコマンドで衝突を解消したり、元に戻す - 猫にWeb
自分が更新したソースをリポジトリにコミットする直前に、 他の人に一足早くコミットされるとバージョンが古くなってコミットできません。 さらにそのまま更新すると、そのソースファイルがリポジトリと競合しちゃって 拡張子が｢.mine｣や｢.r12345｣などの余計なファイルが生成されます。 そんな時に使えるSVNコマンドです。 svn resolved (作業コピーのファイルまたはディレクトリの「衝突」状態を取り除きます) svn resolved ファイル名 このコマンドは単に衝突に関係した中間ファイルを削除するだけです。 まだロックは取得したままなのでさらに下記のコマンドを実行します。 svn revert (ローカルファイルへのすべての編集を取り消します) svn revert ファイル名 ディレクトリ単位で処理したい場合はオプションに｢--recursive｣フラグを使います。 僕の環境
git-svnの使い方を覚えた - idesaku blog
分散SCMを使いたい！と思う今日この頃。 仕事ではSVN（Subversion）を使っているのだが、ちょっとしたお試し編集をするためにブランチを作ることに抵抗がある。ブランチは欲しい、大きめな変更をコミット無しで行いたくない、やはり少しずつコミットして進めていきたい。しかし、変更が全て記録されてしまうのがいただけない。ログが残るのは良いことなのだが、本当に使うかどうか未知数な実験的プログラミングのログまで残したくない。使うと決まってから初めて残すようにしたいのだ。 すまん、これまで一緒に仕事をしてきた人々よ。俺はこれまで「ログが残って困ることがなんかある？いらなきゃ無視すればいいだけなんだから、気にするな。ブランチでもなんでもバンバン作ってしまえ！」とうそぶいてきているわけだが…ハッタリかましてました！本当は俺も抵抗があるのだ。 そこで、分散SCMだ。さらにいうと、SVKがいまひとつ気に入
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
