斎藤です。こんにちは。 今日は、etckeeperを用いて、設定ファイルをバージョン管理する方法を説明します。設定ファイルの書き換えで辛い目に遭う前に、どうぞお試しください。 ※CentOS 6.4, Ubuntu 12.04 LTS, etckeepr 1.7を基準に説明します etckeeperとは etckeeperは主に/etc配下をVCS(Version Control Systems)を用いてバージョン管理します。実態は、gitやmercurialのwrapperとなっています。 設定ファイルの書き換えの際に、ファイル名に日付をつけてバックアップしたりする手間を省いたり、誤って書き換えてしまったときのための 保険 として利用する事ができます。 インストール方法 はじめに 先程も述べました通り、etckeeperはVCSのwrapperとして動きます。そのため、インストール時には
知らないと現場で困るバージョン管理システムの基礎知識:DevOps時代の開発者のための構成管理入門(3)(1/3 ページ) 「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする。今回は構成管理に不可欠ともいえるバージョン管理について、ブランチ機能を中心に紹介。SubversionからGitへの移行事例も。 いまさら聞けない「バージョン管理」とは 第3回目となる今回では、構成管理において「過去のある時点の状態をどのように復元するか」を実現するために不可欠ともいえるバージョン管理とバージョン管理システムについて紹介します。 「集中管理方式」と「分散管理方式」 バージョン管理システムとは、ファイルに対して「誰が」「いつ」「何を
巷では git の大ブームだけど,ひさしぶりに Mercurial について書きます。 Mercurial について言及されたブログとか読んでいるとき,たまに MQ という言葉を目にして気になっていた。ながらく気にはとめつつ全然調べていなかったんだけど,ちょっと利用しようかなというケースがあり,ちょこっと触ってみた。 自分の理解では,MQ (Mercurial Queues) とは,誤解を恐れずにいえば Mercurial の changeset と独立して構成される修正履歴(パッチ)のスタックのようなものだ。 (なので今後 MQ の patch queues を Queues という名称と裏腹に「パッチスタック」「パッチ群」などと勝手に呼び称します) 「誤解を恐れずにいえば」と書いたけれど,この直感的な印象は MQ を使っていくうちに――大筋では変わらないものの――ちょっと変わった。それ
See related links to what you are looking for.
.gitignore や .hgignore で管理対象から無視することができるのはご存知ですよね。 Visual Studio にて無視するファイル一覧をMSDNで探したけど無かったので stackoverflow で調べたらあったのでメモ。あと、教えてもらった方法も追記。 stackoverflow の回答例 github / .gitignore を用いる方法 無視ファイルの設定 .gitignore の場合 gitの場合は、 .gitignore をおいておきます。 .hgignore .hgignore *1 に下記内容を記載してください。Mercurialの場合の無視ファイルは、デフォルトは正規表現で記述するので、glob文法(SHELL形式のパターンマッチングとかのやつ)にするため一行目 *2に syntax:glob と 記載します。 syntax:glob *.obj *
このエクステンションの非推奨化を検討していますが、まだ合意がとれていません。 Mercurial Queues エクステンション 現在、このエクステンションは Mercurial とともに配布されています。 作者: Chris Mason 1. MQ を始める方へ一言 Mercurial を始める方が、 MQ を必要とすることはほとんどありません。 あなたが MQ をお使いで、気に入っているのなら、ぜひ使い続けてください。 しかし、 Mercurial を習得しようとしているなら、代わりに最新のツールを使って下さい。 例えば hg rebase, hg histedit, hg graft, hg strip, hg strip --keep, hg commit --amend です。 詳しくは各コマンドの説明をご確認ください。 The problems with MQ is that
ここ暫く、Twitter や ML 等で、Mercurial の『ブランチ』に関する質問 (特に Git の『ブランチ』との対比) に答える機会が度々あったので、Mercurial における『ブランチ』の概念に関してまとめてみた。 実のところ、SCMBootCamp in Nagoya #1 での、稲田氏 (id:methane) の基調講演資料における Mercurial のブランチに関する説明 (30ページ目) を見て: 別途口頭での説明が無いと、初学者や他のツールからの移行者にとっては、誤解を招きやすいのではなかろうか? と思ったのが、このエントリを書く元々の動機だったのだけれど、書き上げるのにかれこれ3ヶ月以上を要してしまったというのは、反省することしきり。 っつーか、ここ暫くは本家に (議論の叩き台としてリジェクト覚悟で) パッチ提案したりと、色々アレだったんで、その辺は勘弁して
このチュートリアルは Joel Spolsky さんの書いた http://hginit.com の和訳です。 わかりやすくて楽しいチュートリアルを書いてくださった Joel Spolsky さんに感謝します。 Mercurial はモダンなオープンソースの分散バージョン管理システムで、Subversion のような古いシステムから素晴らしい発展をしたものだ。このユーザーフレンドリーな、6章からなるチュートリアルで、Joel Spolsky がキーコンセプトを教えるよ。 目次 Subversion Re-education (Subversion 再教育) Ground up Mercurial (Mercurial の基礎) Setting up for a Team (チームのために設定する) Fixing Goofs (失態に備える) Merging (マージする) Reposito
Mercurialを使ったチケット駆動開発の記事が非常に素晴らしいのでメモ。 このやり方を使いこなせれば、ソフトウェア開発の生産性は劇的に上がると思う。 【元ネタ】 mercurialでチケット駆動開発 - ろじぼ 上記の記事を理解できた範囲でまとめてみた。 【仮定】 ・SCMはMercurial。(Gitでも良い) ・BTSチケットでSW開発のタスクを管理する。 ・trunk、confirmブランチは中央リポジトリ(サーバー)にある。 ・チケットブランチ(トピックブランチ)は、ローカルとサーバーの2箇所にある。 常時同期されている。 ・作業の優先順位によって、チケットがリリース順≠開発順の状況はある。 【チケットAブランチ上の作業手順】 1・チケット担当時に、ブランチ作成。【チケットのステータス=担当】 ↓ 2・チケットAブランチ上でガンガン開発する。【チケットのステータス=担当】 →t
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く