正式には、 「ソフトウェア構成管理」 (Software Configuration Management: SCM) と言います。 「ラショナル統一プロセス」 (Rational Unified Process: RUP) では、 「構成および変更管理」 (Configuration and Change Management: CCM) などとも呼ばれます。 では「構成」とはなんでしょう?
作業上、元々使っていたのがVSSであったこともあり、 ロック必要じゃない? みたいな話があがった。 VSSは、 ・チェックアウト(編集権利取得) ・チェックイン(サーバに反映、編集権利放棄) なんだけれど、 Subversionは、(svn:needs-lock ・ロックを取得(編集宣言=ローカルの読み取り専用が外れて、他の誰かはロックできなくなる ・コミット(変更されていたならば、ロックを開放して変更をサーバに反映。変更されてなければ何もおきない=ロックは開放されない ・ロックを開放(編集終わりましたよ宣言=コミットを忘れていても、ロックは開放されてしまう。変更されてなければローカルは読み取り専用に戻る。 となってる。 VSSのモデルと違い、 ・コミットしても「変更がなければロックは開放されない」 ・ロックを開放しても「変更があっても何も言われない」 ということがある。 VSSではこれら
svkを使ってファイルを管理していたら、あるファイルで、元のSubversionのリポジトリでは実行フラグがついているのにsvkでチェックアウトしたファイルからは実行フラグが外れているという現象に遭遇した。 たまたま何日か前にMercurial で手軽な共有レポジトリをつくろう - www.textfile.orgでMercurialというものを見かけていたので、少し調べてみた。 情報をある程度集めることができたのは Mercurial git の2つだ。 略称は'hg' 参考にしたページは 〈 SL 〉: Mercurial と Trac のメモ steps to phantasien t(2007-05-19) Mercurial の利用 など。 コンパイルが簡単だという話で、実際に試してみたら本当に簡単にコンパイルできた。svkとはえらい違いだ(svkのコンパ
前回は、新しく始まったプロジェクトで、チーム・リーダーが、どのようにして、IBM Rational Team Concert(以下、RTC)を利用する環境を構築していくかについて説明しました。 今回は、チーム・メンバーの視点で、開発メンバーが用意されたRTCの環境を、どのように使っていくかを紹介します。 具体的には、RTCの「ワークアイテム管理」「ソース管理」「ビルド管理」などの開発プロジェクト作業において、最も頻繁に使用する機能の、典型的な利用例について説明します。 また、今回も、EclipseのUI(ユーザー・インタフェース)操作画面を例に、説明します。 0. ~プロジェクトの背景・特徴~ 前回も説明しましたが、今回取り上げるプロジェクトの背景・特徴は、以下の通りです。 メンバーにアジャイル開発の知識があるので、顧客の理解を得て、「スクラム」プロセスが採用された。 リーダーは、別のプロ
Traditional version control helps you backup, track and synchronize files. Distributed version control makes it easy to share changes. Done right, you can get the best of both worlds: simple merging and centralized releases. Distributed? What’s wrong with regular version control? Nothing — read a visual guide to version control if you want a quick refresher. Sure, some people will deride you for u
Kalid Azad、 2007 年 10 月 15 日、 原文 (original post) 従来のバージョン管理は、ファイルをバックアップ・追跡・同期するのに役立った。 分散バージョン管理を使うと、変更内容を共有するのが楽になる。 さぁ、両方の長所を活かすんだ。簡単なマージと一括管理されたリリースを。 分散だって? これまでのバージョン管理で何がまずいの? 別に…。 さっ、気を取り戻したければ、 バージョン管理へのビジュアルガイド(英語) を読んで。 もちろん、「古くさい」システムを使っているとバカにする人もいるだろう。 けれど、私はそれで全然かまわないと思う。 どんなバージョン管理システム(VCS)を使うにしても、プロジェクトにとっては前向きな一歩なんだから。 集中型バージョン管理システムは 1970 年頃に現れた。 その頃プログラマーには、シンクライアントと “big iron”
I asked for suggestions a few days ago. I got several good ones, and investigated them. You can find my original criteria at the link above. Here’s what I came up with: Google Code Its very simple interface appeals to me. It has an issue tracker, a wiki, a download area. But zero integration with git. That’s not necessarily a big problem; I can always keep on hosting git repos at git.complete.org.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く