Something went wrong.We're moving mountains to get it sorted.View our status page and subscribe for service updates.
スライド1: はじめてのMercurial/BitbucketCodeIgniter and its logo are property of EllisLab Inc日本CodeIgniterユーザ会Kenji Suzuki2011/02/19CodeIgniter Users Group in Japan スライド2: 目次・ Part 1 バージョン管理システムとは?・ Part 2 Mercurialとは?・ Part 3 Mercurialの使い方(1) ~ 基本的な使い方 ~・ Part 4 Mercurialの使い方(2) ~ 複数リポジトリの使い方 ~・ Part 5 Bitbucketとは?CodeIgniter and its logo are property of EllisLab IncCodeIgniter Users Group in Japan スラ
Mercurialは、Merucurial拡張という拡張モジュールを使って、Merucrialの挙動をいろいろ拡張できるようになっています。 デフォルトのままだと使いにくいので、Mercurialを使う上で便利にしてくれる拡張を設定しておきましょう。 デフォルトでバンドルされているMercurial拡張は、Using Mercurial Extensionsにまとめられています。 今回はGit使いがMercurial使いに転職するときに、Gitで実現できたことをMercurialで実現するための、組み込み拡張、および、サードパーティ製の拡張について紹介します。 色づけしよう ブランチの確認、diff、パッチ等々、色づけされていないとつらいです。 というわけでGit同様に色づけしましょう。 Color Extensionはすでにバンドルされているので、.hgrcに次の記述を加えましょう。 こ
GitにはA successful Git branching modelと言われるブランチ運用フローが知られています。 内容の詳細はこちら 原文 A successful Git branching model » nvie.com 翻訳 見えないチカラ: A successful Git branching model を翻訳しました でこのフローを補助するツールとしてgit-flowというのがあります。 GitHub - nvie/gitflow: Git extensions to provide high-level repository operations for Vincent Driessen's branching model. git-flowの使い方はこちらが詳しいです。 A successful Git branching model を補助する git-flow
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)(「ICANNがレジストラとして認定した企業」一覧(InterNIC提供)内に「Japan」の記載があるもの)を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
はじめに Mercurial リポジトリのホスティングサービス『Bitbucket』が、容量無制限&プライベートリポジトリ作り放題になっていました。 Free source code hosting — Bitbucket 似たようなサービスでは、Git リポジトリのホスティングサービス『GitHub』が有名ですが、こちらは無料アカウントだとプライベートリポジトリが作れません。容量も現時点で 300MB までと制限されています。 無料アカウントで出来ることは、Bitbucket が圧勝ですね。 前からプライベートリポジトリが欲しかったので、Bitbucket に飛びついてみました。 Mercurial を導入します Mercurial をインストール 公式サイトからダウンロードしてインストールします。 Mercurial SCM Windows で Cygwin を使っている場合は、Cyg
※ 2015-01-19 更新 重要なお知らせ: 1.9 ⇒ 2.0、2.9 ⇒ 3.0、3.9 ⇒ 4.0 といったバージョン番号の増加でも、Mercurial のコンセプト/操作性/互換性等における大きな改変はありません。通常の定例アップデートに過ぎませんので、従来の版を元に書かれている情報の多くは、そのまま適用可能です。 現状でそこそこ妥当な Mercurial の版は以下の通りです。 由来不詳のリビジョンを含むリポジトリから履歴情報を取り込む可能性がある場合は、3.2.3 以降の使用を強く推奨 それ以外の場合は 1.8.1 〜 最新版 (使用状況によっては 2.2 〜 2.2.1 および 2.3 〜 2.3.2 の使用回避を推奨) また、個別のケースにおいて回避を推奨する版の情報を以下に示します。 revsets 記述によるリビジョン指定を多様する場合は、2.5 版以上を推奨(詳細
分散型バージョン管理システムは Git と Github の組み合わせが人気ですが、個人的に BitBucket が気に入ったので基本的な設定や注意点などをメモしておきます。 対象 個人開発でソースコードのバージョン管理をしたい人 プライベート開発したい人。 Windows環境で開発したい人など。 なぜ BitBucket か プライベートレポジトリを無制限に作成できる 5ユーザーまでは無料プランを利用できる プロジェクト Wiki や問題追跡システム (Issue tracking system) が利用できる などが主な理由です。Mercurial レポジトリしか選択できませんが、Git や Bazzar と比べても機能的ほとんど差が無いのであまりこだわっていません (大規模開発なら話が違ってくるかもしれませんが)。単純に BitBucket 使いやすいと感じたので利用しようと思い、必
『Mercurial の使い方のチュートリアル』を一読しておけば、日常作業に困る事は無いと思います。しかし、たまにはリポジトリに間違ったコミットをしてしまうものですし、最初は誰でも間違いがちです。そこで間違えたときに打つべきコマンドの覚え書きとして、以下のコマンド入力例を公開します。 ワーキングツリーにカレント・ディレクトリを移動している状態を前提にした操作例なので注意してください。また、各コマンドの詳細なオプションは hg help [コマンド] を見て確認してください。なお、Mercurialはバージョン1.7.3で動作確認しています。 編集を取り消し、あるチェンジセットの状態に戻す コミットをやり直す、コミット・メッセージを変更する チェンジセットを消す チェンジセットを打ち消す チェンジセットを変更する 複数のチェンジセットを一つにまとめる 履歴をさかのぼって特定のファイルを削除す
2011 年 2 月 5 日 この状態で stable とマージすると: o 1 tip stable d22578dc6cbe 2011-02-05 17:26 +0900 yuya@tcha.org | add bar | @ 0 8e8497c544c1 2011-02-05 17:25 +0900 yuya@tcha.org add foo Mercurial 1.7.5 まで: yuya /tmp/repo hg:0:8e8497c544c1/default % hg merge stable ファイル状態: 更新数 1、 マージ数 0、 削除数 0、 衝突未解決数 0 (マージ結果の commit を忘れずに) yuya /tmp/repo hg:0:8e8497c544c1,1:d22578dc6cbe[tip]/default % hg ci -m 'merge with
Bitbucket で公開されている CodeIgniter 2.0 のソースを元に、開発を進める手順について解説します。 準備 https://bitbucket.org/plans にアクセスして、「5 Users Free」より「sign up」してアカウントを作成します。アカウント作成の詳細は、Bitbucket に登録しよう を参照してください。 自分の PC に Mercurial をインストールします。 Ubuntu の場合は、 $ sudo apt-get install mercurialWindows の場合は、TortoiseHg のインストール を参照してください。 Bitbucket で EllisLab の CodeIgniter リポジトリを fork する まず、EllisLab の CodeIgniter リポジトリを fork して、自分用のリポジトリを
バージョン管理システム使ってますか? 最近、会社のリポジトリをSubversionからGitにがつがつ移行してます。Gitのブランチを使った Git Flowの考え方を浸透させるべく、反映ツールのGit対応などしております。 それと同時に、MyBikeJPプロジェクトは、Mercurialで管理を行っています。 微妙に似ているけど違う gitコマンドと hgコマンドに混乱しまくりで、先日、マージにミスって @key3 さんに迷惑かけちゃいました。 ということで、環境差異を吸収し、さらにミスが減って楽になるような aliasやシェル関数を設定しました。 ちなみに zshです。 Subversion svnでは、元々、.zshrc を id:sotarok さんのをベースにしていた関係でショートカットを知りました。 http://trac.nequal.jp/browser/public/do
開発組織、プロジェクトの特性で大きく左右されるのが構成管理なので、バージョン管理ツールはその都度選択しなければならないのが現状です。 選択の前提 開発組織またはプロジェクトで標準化された構成管理(バージョン管理)環境が存在していない 開発支援環境(構成管理)に開発組織またはプロジェクトが十分な資金投入をする意思がない これは構成管理環境を専任スタッフが構築し、個々のプロジェクトへの適用・運用をサポートするというあるべき姿が取れていない組織でのバージョン管理ツール選択を考えるということを意図しています。 Subversionで対応可能か否か(分散の必要が本当にあるのか) 分散バージョン管理が話題になっていますが、実績/情報/対応ツール/日本語対応を考えるとSubversionが最有力候補です。そこで、Subversionでは構成管理上困ることがプロジェクトの特性上あるかを見極めます。 リポジ
つい先日、SVNからMercurialに移行するべき8つの理由をまとめたが、Twitterやはてなブックマークのコメントを見ていると、同じ分散バージョン管理システムとしてGitとMercurialとの比較に関心が高く、Windowsでの動作でMercurialを評価する人が多いように感じられた。 それも一つの側面で間違いでは無いのだが、日々の開発作業で使っていくと、むしろ操作体系の方が気になるものだ。GitとMercurialの両方を使う機会があったので、操作体系の面で気づいた違いを列挙した上で、Gitに対するMercurialの優位点を考察してみる。 1. 管理対象ファイルの指定方法 .gitignoreや.hgignoreで管理外のファイル名を指定でき、正規表現も使える点は良く似ている。 しかしGitはcommit前にコミット対象を毎回git-addで指定するが、Mercurialは一
Git、Mercurial、Bazaarはオープンソースの分散バージョン管理システムで、どれも人気がある。特にGitとMercurialはもともとはLinux Kernelの開発のために作られた歴史からしても、ライバルと言える関係だ。LinuxやAndroid OSではGitが採用されたが、MercurialもOpenJDKやNetBeans、Xen、Python等で採用されている。 SVNから分散バージョン管理システムに移行を検討している所は多い。日本だと濱野氏がGitのメンテナをやっているせいかGitに人気が集中しているようだ。しかし気軽に分散バージョン管理システムを導入したいソフトウェア開発チームには、あえてMercurialを勧めたい。 1. SVNからMercurialに移行するべき8つの理由 取り扱いが楽で、今すぐ移行できる事がMercurialを導入するべき理由だが、もう少し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く