業務の都合で本社にしばらく出張になりました。
今住んでいるところから本社に行くには、大阪モノレールに乗らなければならないのですが、これがどうもよろしくない。
車両数が少なくて、車内が狭くて(=毎朝満員電車)、スピードも遅いのはモノレールだし仕方ない部分もあるでしょう。それは良いんです。
しかし親会社の阪急電車と連絡が悪いのはいただけない。モノレール降りて普通の速度で阪急に歩いて行くと、高い確率で電車が行った直後のホームに着いてしまうのです。
一体何の嫌がらせなの?それとも暗に走れって言ってるの?むかつくわ…。
 この記事にコメントする
 この記事にコメントする
27歳。もう30歳はすぐそこナリ。
 この記事にコメントする
 この記事にコメントする
日記のエントリにパーマネントリンクを付けました。日付が各日記へのリンクになっていますので、適当にコピってご利用下さい。
日付の右下にある「permalink」は、過去ログへのリンクになっています。リンクするなら軽いページの方が良い!と言う方は、過去ログへのリンクをお使い下さい。
ただし過去ログは手動で更新しているので、新しめのエントリのpermalinkへ飛ぶと、過去ログが生成されておらずNot Foundとなります。イマイチですよね…そうですよね。
髪の毛に当てるパーマもパーマネントの略です。一度やれば毎日面倒なセットしなくても、ずっと同じ髪型を保てますよ、ってことで永久髪型、パーマネントウェーブ(ヘアースタイル)、略してパーマです。
ですからして、よく「パーマをあてる(※)」という言い回しをしますが、これは「永久(髪型)をあてる」となって、さっぱり意味がわかりません。髪型をどうやって、何に当ててるんでしょう?
「パーマにする」ならまだ意味が分かりますが、なぜかあまり使われません。
「あてる」って誰が最初に言い始めて、なぜこんなに普及したんだろう?不思議だねぇ。
(※)地域によって「パーマをあてる」と「パーマをかける」があるみたいですが、どちらも意味が通じません。
 この記事にコメントする
 この記事にコメントする
休日出勤でした。日曜朝の電車は、乗客全員が座ってもなお席が空いていました。いつもこれくらい空いていて欲しいものだ…。
会社も空いていて静かでした。電話が一切かかってこないので捗りますね。
 この記事にコメントする
 この記事にコメントする
目次: Linux
会社でSubversionとGitを同時に使っているのですが、すごく混乱します。家ではさらにMercurialも使っているためさらに混乱します。
個々のシステムはどれもわかりやすいですし、良いと思いますが、3つ同時に使うと混乱してしまって、全く操作できません。いつかこの辺の違いをしっかりまとめたいけど、どうもやる気が出ないのですよ…。
かなりざっくりした説明ですが、各バージョン管理システムの動作概要です。ざっくりすぎとか、間違いに気づいたらぜひ教えてください。
Subversionの動作イメージ
管理外 <--(add/rm)--> ワーク <--(commit/update)--> リポジトリ
SubversionはCVSに似た体系、動作になっているようです(CVS使ったことないので知りませんけど)。CVS -> Subversion移行ユーザーの混乱を減らすためでしょうか。
Mercurialの動作イメージ
管理外 <--(add/rm)--> ワーク <--(commit/update)--> リポジトリ <--(push/pull)--> 他のリポジトリ
MercurialはSubversionの後釜を狙ったんだったか、コマンド名も動作もSubversionと似ています。しかし油断してると似て非なる部分でハマります。
Gitの動作イメージ
ワーク/管理外 <--(add/rm)--> ステージ <--(commit/reset)--> リポジトリ <--(push/fetch)--> 他のリポジトリ
Gitはステージという概念が他の2システムと異なります。ステージの存在を認識するまではcommitされる対象が理解できず混乱しますが、要らん変更をコミットしてしまうミスが減る利点もあります。
最も基本的と思われるコマンド群と、各システムでの挙動を以下に挙げます。
リポジトリと作業領域の差分を見ます。
リポジトリ <--(status/diff)--> 作業領域
対象を省略した場合、Subversionはカレントディレクトリとその子ディレクトリを対象にしますが、Git, Mercurialは全リポジトリを対象にします。
作業領域の更新をリポジトリに反映させます。
作業領域 --(commit)--> リポジトリ
オプションを特に付けなかった場合、Subversion/Mercurialは変更されたファイル、追加(add)、削除(rm)したファイルをコミットします。Gitは変更(add)、追加(add)、削除(rm)によりステージに置いたファイルしかコミットしません。
またSubversionはカレントディレクトリとその子ディレクトリがコミット対象ですが、Mercurial/Gitは作業領域全体がコミット対象となります。
リポジトリの更新を作業領域に反映させます。
作業領域 <--(update)-- リポジトリ
対象を省略した場合、Subversionはカレントディレクトリとその子ディレクトリ、Mercurialはリポジトリ内の全ファイルが更新されます。Gitはresetコマンドが似ていますが、ステージにも影響を及ぼしてしまいます。
ローカルリポジトリの更新を別リポジトリへ送ります。
リポジトリ --(push)--> 他人のリポジトリ
MercurialもGitも同じような動きをします。Subversionにはありません。
別リポジトリから更新を受け取って、ローカルリポジトリへ反映します。
リポジトリ <--(pull)-- 他人のリポジトリ
Mercurialはローカルリポジトリを更新するだけですが、Gitは作業領域も更新しようとします。Gitだとfetchが大体同じような動きをします。Subversionにはありません。
 この記事にコメントする
 この記事にコメントする
| < | 2010 | > | ||||
| << | < | 03 | > | >> | ||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 | 
| - | 1 | 2 | 3 | 4 | 5 | 6 | 
| 7 | 8 | 9 | 10 | 11 | 12 | 13 | 
| 14 | 15 | 16 | 17 | 18 | 19 | 20 | 
| 21 | 22 | 23 | 24 | 25 | 26 | 27 | 
| 28 | 29 | 30 | 31 | - | - | - | 
 wiki
 wiki Linux JM
 Linux JM Java API
 Java API 2002年
 2002年 2003年
 2003年 2004年
 2004年 2005年
 2005年 2006年
 2006年 2007年
 2007年 2008年
 2008年 2009年
 2009年 2010年
 2010年 2011年
 2011年 2012年
 2012年 2013年
 2013年 2014年
 2014年 2015年
 2015年 2016年
 2016年 2017年
 2017年 2018年
 2018年 2019年
 2019年 2020年
 2020年 2021年
 2021年 2022年
 2022年 2023年
 2023年 2024年
 2024年 2025年
 2025年 過去日記について
 過去日記について アクセス統計
 アクセス統計 サーバ一覧
 サーバ一覧 サイトの情報
 サイトの情報合計: 
本日: