git clone --branch で一気にブランチに移行2015年08月01日 11時34分32秒

git clone はレポジトリを複写する方法。分散型の git に取っては、取得するチェックアウトにも相当する。git clone には -b または --branch のオプションもあり、任意のブランチに直接移行することも出来る。

試してみたら、存在しないブランチを指定すると、何も複製されない。

git clone; git branch で取得とブランチへの移行をすると、ブランチが無いときにそのまま master になってしまう。ブランチが存在しない場合に、異常終了したい場合には clone で一気にブランチを指定すると、失敗してもに何も残らない。

FreeBSD の CVS も 8.4 で終わりみたいだ2014年02月10日 11時56分53秒

FreeBSD も長いこと使っているが、時代の移り変わりを感じる時がある。

% cvs stat Makefile
===================================================================
File: Makefile          Status: Up-to-date

   Working revision:    1.404.2.2
   Repository revision: 1.404.2.2       /home/ncvs/src/Makefile,v
   Sticky Tag:          RELENG_8_4 (branch: 1.404.2)
   Sticky Date:         (none)
   Sticky Options:      (none)

   Existing Tags:
        RELENG_8_4                      (branch: 1.404.2)
        RELENG_9_1_0_RELEASE            (revision: 1.392.2.3.2.2)
        RELENG_9_1                      (branch: 1.392.2.3.2)
        RELENG_9_1_BP                   (revision: 1.392.2.3)

8.4 Release 以降は cvs は更新されていない。

Subversion は今でも好きではなく、cvs で更新できる間は cvs でと、移行していなかったがそろそろ年貢の納め時の様だ。

何より痛恨なのは、Subversion はタグが作れない事。そのように設計されたとは言うが、設計そのものが間違っている。リリースビルドをするとき等は、ブランチでコンパイルし、成功した暁にタグを作りたい。逆だと、手順が二倍に増える。そして、タグをリリースビルド後に作って、タグにコードを svn switch すると、全てのファイルのタイムスタンプが更新されデバッガが、好ましく思わない。

ディスク容量が cvs の二倍必要。今は気にはしないが、何年も前に少ない容量で遊んでいる時は、影響が大きかった。これ自体は、特にリモートの場合に、diff や stat でアクセスを回避できるので、利点はしっかりとある。

ただ cvs は RCS の延長なので、コミットの単位がファイル毎等の問題があったのも事実。FreeBSD では利用者の一人に過ぎないので、svn を使うこと自体には不満は無いが、少し下調べが必要だ。

Subversion で mergeinfo を壊された時は svn merge --record-only2011年08月08日 11時11分53秒

Subversion を使って履歴管理をしているのだが、時折、mergeinfo を壊す輩がいる。まだ、どの履歴が、どのコマンドが問題を起こしているのかは掴めていないが、svn merge に余計な時間を費やさなくてはいけないので、頭を抱えている。

mergeinfo の過去のマージの履歴を消えているみたいで、以前に行なったマージを再度行なおうとする。svn はもちろんのこと衝突を起こし、一つずつ手での修正を強要してくる。

最初の頃は、何故起きているのか解らず、万一に備えて全部目視点検していた。しかし、既に何回も起きて、各々の目視点検は単に時間の無駄と言う結論に達した。

そんなときに使いオプションが、svn merge --record-only。svn merge の様に実際にファイルを変更せずに、mergeinfo のみを更新する。既にマージが終わっている番号を調べて、--record-only で一気に無視。

Subversion はタグが打てないという設計上の欠陥と相まって、継続的なマージがとても難しい。

ClearCase は RCS + NFS + 秀逸な UI と merge2011年08月06日 16時18分24秒

以前から ClearCase はどんな感じなのだろうと不思議に思っていた。話を聞くと、とても ClearCase は良かったと絶賛する人が多いのだが、具体的にどんな感じなのかを聞くとうまく答えられないとの人達ばかりだった。それらの人達が履歴管理を各々でやっていて不満がないのを見るのも不思議だったのだが。

そんなわけで、ClearCase を触る前の期待は大きくもあったのだが、実際に使ってみるとそうでもなかった。むしろ期待外れの方が大きかった。率直な感想は、NFS 付きの RCS。個々のファイルを別々に管理する。また、処理速度の遅さが際だっていた。

そして、コマンドの数がやたらと多くて、何が何をやるのだか把握しづらい。コマンドラインだけで使いこなすのは時間がかかりそうだ。まあ、商用だからだろうか。秀逸な GUI が存在する。かなりの部分がこれで足りるのでそこの部分の欠点はまあ補っている。

マージや衝突の解消はフリーのソフトウェアと比べると格段に良い。GUI が見やすくて、使いやすく、また左右の変更が同じ場合には自動的に認識して、解消したりもする。一部のフリーソフトでは、同じ変更でも選ぶのを強要されるのも多い。

ClearCase は期待していた程でもない2009年12月24日 13時27分58秒

ClearCase を仕事で使うようになった。CVS などを始めに、幾つか使った事はある。管理者だった事もある。しかし、ClearCase は初めてだ。

以前の職場では ClearCase を絶賛する人達が多かった。それでどんな感じだったのかを聞いたと事は何度もあるのだが、具体的な説明をもらったことは無かった。ほかのだと、ClearCase みたいな事は出来ないよと言う割にはなんだか正体が掴めなかった。

まだ、使い初めてそんなに長い期間は経っていないが、どうも使い勝手は聞いていた程良くもない。RCS よりは明らかに上だが、CVS よりも不便な所も多い。唯一、明らかに便利だと思ったのが、マージの履歴。

感覚的には、CVS の方が ClearCase よりもファイルをまとめて扱いやすい。ClearCase では ディレクトリ毎の比較や、ファイル群を一気に比較できなくて、とても不便に感じている。

Subversion でのブランチ間の比較2009年03月01日 11時09分20秒

Subversion で異なるブランチ間やタグ間を比較する時は、目的のサブディレクトリを指定する。

% svn diff svn://svn.freebsd.org/base/release/7.1.0/sys svn://svn.freebsd.org/ba
se/head/sys

Subversion の diff は二つの異なった対象と比較するか、作業コピーのファイルを現在のブランチと比較するしか出来ないようだ。

意図的に作業しているブランチとは違ったブランチと diff を取ることがある。例えば、FreeBSD の 8-current で作ったとしよう。cvs diff -r releng_7 として違うブランチと比較を行い、移植作業の見積りが出来る。しかし、Subversion では svn://svn.freebsd.org/base/head/sys で行った変更を、svn://svn.freebsd.org/release/7.1.0/sys と比較することは出来ない。不便だ。

git add/commit/diff の動作2009年02月12日 17時58分37秒

以前にも git のインターフェースは他と同じ名前なのに動作が違うのは指摘した。似て非なる物の為、更にとっつきが悪い。git heckout もその一例だ。

git の add と commit の動作も他とは全く異なる。

非 git での add は、新しいディレクトリやファイルを追加するのに使われる。非 git での commit は引数に指定されたファイルをコミットするのに使われる。そして、diff はこの手元での変更を表示する。様々なオプションを指定すればタグなどとの比較も可能だが、ここで言いたいのは何もオプションを与えないときの動作のことだ。

git では、全てのコミットを事前に add する必要がある。git の add はディレクトリやファイルを追加するのではなく、変更をコミットする為の予約をするコマンドだ。そして、commit であらかじめ登録しておいた変更のうち、引数で渡されたファイルのみの差分をコミットする。commit には add が必須だ。そして、diff コマンドは、手元の変更で add されていない物のみを表示する。そのため、git add が終わった変更は、git diff にて表示されない。

hg で例をあげる。


% hg init
% echo A > file.txt
% hg add file.txt 
% hg commit -m 'Create file.txt.'
% echo B >> file.txt 
% hg diff
diff -r d3e5d96de93f file.txt
--- a/file.txt  Fri Feb 11 23:10:27 2009 -0500
+++ b/file.txt  Fri Feb 11 23:11:42 2009 -0500
@@ -1,1 +1,2 @@
 A
+B
% hg add file.txt 
file.txt already tracked!

二度目の file.txt の add は出来ないと言われる。

今度は git で試す。


% git init
Initialized empty Git repository in /tmp/git/.git/
% echo A > file.txt
% git add file.txt 
% git commit -m 'Create file.txt'
Created initial commit 58d0fcc: Create file.txt
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file.txt
% echo >> B file.txt 
% git diff
diff --git a/file.txt b/file.txt
index f70f10e..35d242b 100644
--- a/file.txt
+++ b/file.txt
@@ -1 +1,2 @@
 A
+B

ここでは、diff が表示される。

% git commit -m 'Added B.'
# On branch master
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#
#       modified:   file.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

しかし、これはコミットできない。

% git add file.txt 
% git diff
% git commit -m 'Added B.'
Created commit 9f0a6ac: Added B.
 1 files changed, 1 insertions(+), 0 deletions(-)

add を使い登録することで、コミットが受け付けられた。そして、diff では変更を見られなくなっている。

バージョン管理 short tours2009年02月09日 12時34分12秒

一人で各種の履歴管理システム/プログラムを使い初める為の簡単な例。以下の作業を各々のプログラムにて実行する。
  1. work ディレクトリに a.txt と 1.txt を作成。
    
    % cd /tmp
    % mkdir work
    % cd work
    % echo "A B C" > a.txt
    % echo "1 2 3" > 1.txt
    
    
  2. import/checkout の作業を行なう。
  3. 1.txt を編集し、status と diff を見る。
    
    % echo "10 11 12" >> 1.txt
    
    
  4. 1.txt の変更をコミット。
  5. a.txt を A.txt に変更し、コミット。
  6. ログを見る。

プログラムのデザインと思想によって、始め方は千差万別だ。各々、特徴的な初期化のやり方をする。しかし、そう何回も繰り返す作業ではない。

一度、使い始めると大切な作業は三つ。

  1. 変更を確認する。
  2. 変更を記録する。
  3. 履歴を見る。
これらの作業が中心となる。コマンド的には、checkout(co)、diff、commit(ci)、update、log、status 等が並ぶ。これらのコマンドがある程度使えると、不自由はしない。

そして集団で使うとなると、更に二つの作業が必要になる。

  1. 他人の変更を引っ張ってくる。
  2. 衝突を解消する。
個人的に使っていても、二つ以上の作業場を用意して、疑似体験することは出来る。大きいプロジェクトや既に安定運用している成果物だと変更箇所も分散される事が多い。また、正しく管理されている仕事であれば衝突を避けるように計画するべきなので、衝突の解消を行なう事自体は少ない。こちらについては、今回は扱っていない。

集中管理型や分散型による違い。各思想の違いもコマンドに現れていて面白い。RCS は単体ファイルのみ。CVS 以降はディレクトリ構成も含めて、ファイルを集合として扱える。新しいい物も RCS/CVS に準拠したコマンド名も多い。使い手としては、コマンドと動作がある程度似ていた方が、試しやすく抵抗感も少ない。欠点としては、RCS/CVS の動作に寄せる形になるので、設計に RCS/CVS の影響が多かれ少なかれ出てくる事だ。

旅程cvsMercurial/hggitSubversion/svnrcssvk