TortoiseHg Advent Calendar 2012 (2012/12/01 00:00〜)
注意 現在X(旧Twitter)でのソーシャルログインができない事象を確認しています。事前にX(旧Twitter)側で再ログインした上でconnpassのソーシャルログインを行うか、 「ユーザー名(またはメールアドレス)」と「パスワード」の組み合わせでのログインをお試しください。合わせてFAQもご確認ください。 お知らせ 2024年9月1日よりconnpassサービスサイトへのスクレイピングを禁止とし、利用規約に禁止事項として明記します。 9月1日以降のconnpassの情報取得につきましては イベントサーチAPI の利用をご検討ください。 お知らせ connpassではさらなる価値のあるデータを提供するため、イベントサーチAPIの提供方法の見直しを決定しました。2024年5月23日(木)より 「企業・法人」「コミュニティ及び個人」向けの2プランを提供開始いたします。ご利用にあたっては利用
Mercurial Advent Calendar 2012 (2012/12/01 00:00〜)
注意 現在X(旧Twitter)でのソーシャルログインができない事象を確認しています。事前にX(旧Twitter)側で再ログインした上でconnpassのソーシャルログインを行うか、 「ユーザー名(またはメールアドレス)」と「パスワード」の組み合わせでのログインをお試しください。合わせてFAQもご確認ください。 お知らせ 2024年9月1日よりconnpassサービスサイトへのスクレイピングを禁止とし、利用規約に禁止事項として明記します。 9月1日以降のconnpassの情報取得につきましては イベントサーチAPI の利用をご検討ください。 お知らせ connpassではさらなる価値のあるデータを提供するため、イベントサーチAPIの提供方法の見直しを決定しました。2024年5月23日(木)より 「企業・法人」「コミュニティ及び個人」向けの2プランを提供開始いたします。ご利用にあたっては利用
Git & GitHub & kintone でウルトラハッピー！ - Cybozu Inside Out | サイボウズエンジニアのブログ
６歳と３歳の娘がいる山本泰宇（@ymmt2005）です。こんにちは。 いきなりですが、悔しいです。なにがって、@DQNEO さんが最近書かれた記事「必殺！Github導入に向けて上司を説得する時に使える資料まとめ」に載り損ねてしまったからです。 サイボウズでも Git と GitHub Enterprise を導入しています。導入や運用の助けになる資料やツールを作ったりして、とても便利なのでいずれ公開したいなと思っていたんです。忙しさにかまけて後回しにしていたら、出遅れ企業にグルーピングされてしまうなんて（涙） 出遅れてしまった以上、なにかプラスアルファをお見せするしか名誉挽回の方法はありません。何も失っていないんじゃないかというツッコミはよしてください。こうなったら恥も外聞もなく Subversion 時代の恥ずかしい過去をさらけ出し、もちろん資料も出して、さらにノウハウを詰め込んだツー
「git commit するまえに考えるべき10のこと」がDVCS的じゃない件 - うさぎ組
はじめに git commit するまえに考えるべき10のこと | Act as Professionalを読んでいろいろと思うことがあったので書きました。 これはSCMBootCamp主催者としてとか、Mercurialユーザーを代表してとかではありません。 僕はこう思う。ということです。 読むの面倒な人は最下部のまとめだけ読めばok。 commit != push DVCSの利点はローカルコミットという概念を持ち込んだことです。これにより、高速な履歴追加、安全なマージを手に入れることができました。 件の記事を読んでいて気になったのは、commitという単語です。 特に、 1コミットに1つの対応 コメントアウトしたコードをコミットしない テストが正常に通過したものにしてください コミットメッセージの1行目は”短い説明” コミットメッセージのスタイル コミットメッセージのボディは有意義な内
Visual Studio にて設定すべき .gitignore / .hgignore - secretbase.log
.gitignore や .hgignore で管理対象から無視することができるのはご存知ですよね。 Visual Studio にて無視するファイル一覧をMSDNで探したけど無かったので stackoverflow で調べたらあったのでメモ。あと、教えてもらった方法も追記。 stackoverflow の回答例 github / .gitignore を用いる方法 無視ファイルの設定 .gitignore の場合 gitの場合は、 .gitignore をおいておきます。 .hgignore .hgignore *1 に下記内容を記載してください。Mercurialの場合の無視ファイルは、デフォルトは正規表現で記述するので、glob文法（SHELL形式のパターンマッチングとかのやつ）にするため一行目 *2に syntax:glob と 記載します。 syntax:glob *.obj *
1.8 版以降の Mercurial を推奨 - 彷徨えるフジワラ
SSH 経由でリモートリポジトリと連携する際に、(1) 連携先ホストのシステムワイドに使用可能 (例: /usr/bin/hg 等) な hg コマンドのバージョンが低い一方で、(2) 連携先リポジトリの hg init で使用した hg コマンド (例 ${HOME} や /usr/local/bin 配下に独自インストールしたもの) のバージョンが、ある程度新しいものである場合、連携先リポジトリの指定が正しくても、以下のようなエラーメッセージが表示される可能性があります。 there is no Mercurial repository here (.hg not found)! ※ 日本語出力の場合: Mercurial リポジトリが見つかりません(.hg が不在です) 以下の2つのバージョンで、前者のみが 1.7 以前の場合は、まず間違いなくこの問題に該当するものと思われます。 s
Mercurial 2.3 版での内部 API 変更による 3rd party エクステンションのトラブル - 彷徨えるフジワラ
Mercurial 2.3 では、幾つかの内部 API の仕様が変更されたことで、3rd party エクステンションの中には、正常に動作しないものがあります。 現状、私が情報を把握しているものは以下のものです。 hggit (※ 修正済み) hgsubversion (※ 修正済み) projrc (※ 修正済み) collapse (rdiff も ?) 『※ 修正済み』表記のあるものは、既に 2.3 API に対応した版が公開されているものです。これらを併用されている方は、速やかに最新版に更新してください。 また、上記で列挙したエクステンション以外で、同様の、あるいは現象は違うけれども、2.3 での API 仕様変更の影響が疑われる現象を見かけた際には、以下のような手段で連絡頂けると助かります。 本ブログエントリへのトラックバック／コメント 私宛のツイート #mercurialjp
RhodeCode
RhodeCode 1.3.6 Released Posted on May 19th, 2012 | Read more RhodeCode 1.3.5 Released Posted on May 13th, 2012 | Read more RhodeCode 1.3.4 Released Posted on March 29th, 2012 | Read more RhodeCode 1.3.3 Released Posted on March 3rd, 2012 | Read more Casino Security: Real Vs. Fake Chips Unveiled Posted on June 7th, 2024 | Read more RhodeCode is a fast and powerful management tool for and GIT with
Veracity - The Next Step in DVCS
An open source, distributed version control and bug tracking system for Windows, Mac OS X, and Linux. DVCS Comparison Veracity features and philosophies vs. other major DVCS tools Getting Started Veracity Q&A: I've installed Veracity. How do I get started using it? Version Control The first thing you’ll notice: Distributed Version Control is just flat-out fast. Everything happens locally until you
obsolete 機能 - 彷徨えるフジワラ
来月(８月)冒頭にリリースされる Mercurial 2.3 版から、 obsolete (marker) と呼ばれる機能が追加される。 >>>> 2012-08-04 追記： ここから 2.3 リリース直前に、デフォルトでは obsolete 設定の追加を抑止する修正が入った模様。 そのため、2.3.x 版で試験的に obsolete 機能を試してみようと思う場合、以下のようなエクステンションを使って obsolete 機能を有効にしてやる必要がある (後述する evolve エクステンションを有効にする方法も)。 from mercurial import obsolete def uisetup(ui): obsolete._enabled = True なお、リリース間際のバタバタの影響なのか、59c14bf5a48c と a1f8869f2eee の２つのリビジョンで "_ena
(特に Git 併用ユーザには是非読んでおいて欲しい) Mercurial における『ブランチ』の概念 〜 その１ - 彷徨えるフジワラ
ここ暫く、Twitter や ML 等で、Mercurial の『ブランチ』に関する質問 (特に Git の『ブランチ』との対比) に答える機会が度々あったので、Mercurial における『ブランチ』の概念に関してまとめてみた。 実のところ、SCMBootCamp in Nagoya #1 での、稲田氏 (id:methane) の基調講演資料における Mercurial のブランチに関する説明 (30ページ目) を見て: 別途口頭での説明が無いと、初学者や他のツールからの移行者にとっては、誤解を招きやすいのではなかろうか？ と思ったのが、このエントリを書く元々の動機だったのだけれど、書き上げるのにかれこれ３ヶ月以上を要してしまったというのは、反省することしきり。 っつーか、ここ暫くは本家に (議論の叩き台としてリジェクト覚悟で) パッチ提案したりと、色々アレだったんで、その辺は勘弁して
Mercurial でのサブリポジトリの利用 - 彷徨えるフジワラ
ここ暫く、#TokyoMercurial (+ 懇親会)の席や twitter上などで、サブリポジトリ(subrepo)の利用に関する質問等が多かったのですが、口頭説明や、twitter の文字制限内では、なかなか正確に伝えるのが難しかったので、ブログエントリとしてまとめてみました。 っつーか、ある程度書きあがってから、僕の勘違いに突っ込みが入って、慌てて加筆修正しました(笑)。指摘感謝です！ > @yujauja 氏 サブリポジトリの利用開始 Mercurial のサブリポジトリ機能とは: Mercurial リポジトリを親に、外部のリポジトリやプロジェクトを入れ子にし、 コマンドの実行の際に、 それら一連のリポジトリに対して処理を行えるようにします。 〜 "hg help subrepos" より というものです。 サブリポジトリの追加手順は、hg help subrepos (日本語
hgwebと2つのリポジトリでpull requestを開発フローに組み込む - 放牧日記
http://connpass.com/event/445/:title=の成果です。 TODO: 動機付け 構成 hgwebでは次の二つのリポジトリを用意します。 http://hg.example.com/app (pull専用リポジトリ、レビュー済みの履歴を持つ) http://hg.example.com/app-work (push専用リポジトリ、未レビューを含む全ての履歴を持つ) 通常の作業者は一のリポジトリを用意ます 作業用リポジトリ pull requestを処理する人は二つのリポジトリを用意します。 作業用リポジトリ pull request取り込み用リポジトリ 0) hg clone (◆作業者/★pull request処理者) pull専用リポジトリをクローンして作業用リポジトリ(とpull request取り込み用リポジトリ)を作成します。 $ hg clone
Git 対 Mercurial：なぜ Git を選ぶのか？ - Atlassian Japan
今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが Vim と Emacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは本来の仕事そっちのけ
Mercurial 対 Git：なぜ Mercurial を選ぶのか？ - Atlassian Japan
ここで見たように、Git は、Subversion ユーザーにその CLI に早く慣れてもらうようにするということをあまり考慮していません。 新しいコマンドを入力するために指を再度トレーニングすることによりこの問題を回避することはできますが、それでもシステムを移行する上での障害の一つになるでしょう。その上、Subversion ユーザーにとってフレンドリーで、かつ、強力で美しいインターフェースをもった Mercurial があるので、Git がなくても問題はありません。 履歴が安全な Mercurial Mercurial の哲学は、 “履歴は永久的で神聖である” ということです。Mercurial のコアには、履歴を変更できるコマンドがたった一つだけあります。hg rollback です。このコマンドは直前のプルやコミットを “取り消し” ますが、それより前のものには一切触れません。 G
rebaseのイメージ - プログラマの思索
@yusuke_kokuboさんのつぶやきでrebaseのイメージがようやく分かったのでメモ。 【元ネタ】 Twitter / @akipii: とても分かりやすい RT @yusuke_kokubo: ブランチのmergeは2つのブランチが合流するのに対して、 rebaseは一方のブランチがもう一方のブランチに(分岐元から派生した分を)吸収するようなイメージをしてる Rebaseとトピックブランチ: プログラマの思索 mergeは衝突がなければ、派生ブランチをtrunkへ取り込んでくれるが、衝突があれば、マージしてくれない。 rebaseは、trunkへ派生ブランチで育てたパッチを合流するように取り込んでくれる。 つまり、rebaseはtrunkの履歴を壊さず、その履歴の上に派生ブランチの履歴を取り込んでくれる。 「入門Git」にもrebaseについて詳しく解説されている。 trunkに
Pythonプロフェッショナルプログラミングを執筆する上で、継続的インテグレーション的なことをやったことについて - cactusman日誌
Pythonプロフェッショナルプログラミング 作者: ビープラウド出版社/メーカー: 秀和システム発売日: 2012/03/26メディア: 単行本購入: 6人 クリック: 765回この商品を含むブログ (27件) を見るPythonプロフェッショナルプログラミングはSphinx+Mercurial+Jenkins+Redmine+SkypeBotの組み合わせで執筆をしていました。 編集のほうで原稿にデザインをあててPDFにするため、最終成果物はその前段階の原稿になります。 それぞれの役割は以下になります Sphinx: ドキュメント作成 Mercurial: ソースコード管理 Jenkins: Sphinxでの定期的なビルド Redmine: タスク管理, Wiki SkypeBot: 各種通知 Mercurial, Redmine, SkypeBotについてはすでに会社に環境があるので、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
BitbucketでMercurialを使い始めた - おもいつきでおもちつき
bitbucketの使い方
Charming Python: Functional programming in Python, Part 3
