すべての Microsoft 製品 Global Microsoft 365 Teams Copilot Windows Surface Xbox セール 法人向け サポート ソフトウェア Windows アプリ AI OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox Live Gold Xbox とゲーム PC ゲーム Windows ゲーム 映画とテレビ番組 法人向け Microsoft Cloud Microsoft Security Azure Dynamics 365 一般法人向け Microsoft 365 Microsoft Industry Microsoft Power Platform W

ここ暫く、#TokyoMercurial (+ 懇親会)の席や twitter上などで、サブリポジトリ(subrepo)の利用に関する質問等が多かったのですが、口頭説明や、twitter の文字制限内では、なかなか正確に伝えるのが難しかったので、ブログエントリとしてまとめてみました。 っつーか、ある程度書きあがってから、僕の勘違いに突っ込みが入って、慌てて加筆修正しました(笑)。指摘感謝です！ > @yujauja 氏 サブリポジトリの利用開始 Mercurial のサブリポジトリ機能とは: Mercurial リポジトリを親に、外部のリポジトリやプロジェクトを入れ子にし、 コマンドの実行の際に、 それら一連のリポジトリに対して処理を行えるようにします。 〜 "hg help subrepos" より というものです。 サブリポジトリの追加手順は、hg help subrepos (日本語

簡単にまとめると: リビジョン指定に revsets 表記を多様する人は、想定外の挙動が発生する可能性があるので、Mercurial 2.3 版の利用は回避することを推奨 最新の情報に関しては、こちらのエントリを参照のこと。 以下、詳細というか、障害要因調査の顛末。 事の発端は、"hg convert" と filemap 指定の併用により、追加したファイルを履歴を遡って改名する実験をしていた際の、以下のような挙動の発見。 $ ADDEDREV=`hg -R src log -r "min(filelog('re:b'))" --template '{node}'` $ echo ${ADDEDREV} 9c7bcdc44ce39d06d3fb9e4e0ee6a53c72122673 $ PARENTREV=`hg -R src log -r "${ADDEDREV}^1" --templ

2013/12/16: 適用済みパッチに対する hg rebase に関する追記あり 事の発端は以下のツイート: これに id:hokorobi 氏が以下のように返信: というタイムラインを目にしたのだけれど、最初は qimport と sed と hg add が頭の中で全然結びつかなくて、頭の中が『？？？？？』な状況だった(笑)。 考える事暫し……… あぁ！そーゆーことか！？ 例えば、MQ で複数のパッチを作成した際に: 最初のパッチで新規ファイルを追加 2つ目以降のパッチで、追加したファイルに改変を実施 という状況だとして、ここで『新規ファイル』を改名しようとすると: 最初のパッチを qpush 新規追加ファイルを rename qrefresh でパッチに rename 実施結果を反映 次のパッチを qpush 改変対象ファイルが既に rename 済みなので、パッチ適用対象無しエ

Mercurialリポジトリの統合と分割のコマンドconvertの使い方がわかったのでメモ。 【元ネタ】 Mercurial の convert 拡張を用いてリポジトリの内容を一括で変換する (フェンリル | デベロッパーズブログ) 紹介マニアどらふと版: convert と filemap を利用した hg リポジトリの分割と統合 Mercurial リポジトリを分割する - ursmの日記 Convert でリポジトリを分解する / hg tip schrome.net - Mercurialリポジトリへの分割と変換を行うシェルスクリプト Mercurialリポジトリを統合したり分割したい理由は、新規開発や2次開発で一旦作ったものの、それらのライブラリを後からまとめたり、多すぎるので分割したりしたい時があげられる。 その場合、修正履歴もそのまま引き継ぐようにしたいが、Mercurial

ここ暫く、Twitter や ML 等で、Mercurial の『ブランチ』に関する質問 (特に Git の『ブランチ』との対比) に答える機会が度々あったので、Mercurial における『ブランチ』の概念に関してまとめてみた。 実のところ、SCMBootCamp in Nagoya #1 での、稲田氏 (id:methane) の基調講演資料における Mercurial のブランチに関する説明 (30ページ目) を見て: 別途口頭での説明が無いと、初学者や他のツールからの移行者にとっては、誤解を招きやすいのではなかろうか？ と思ったのが、このエントリを書く元々の動機だったのだけれど、書き上げるのにかれこれ３ヶ月以上を要してしまったというのは、反省することしきり。 っつーか、ここ暫くは本家に (議論の叩き台としてリジェクト覚悟で) パッチ提案したりと、色々アレだったんで、その辺は勘弁して

今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが Vim と Emacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは本来の仕事そっちのけ

原文(投稿日：2012/04/23)へのリンク Microsoft は新たな Branching and Merging Guide のドラフト版をリリースした。表向きの対象は TFS ユーザだが，アドバイスの大部分はソース管理プロバイダに関係なく適用可能だ。まずその基本概念を紹介しよう。 ブランチとマージを扱うほとんどのガイドラインと同様に，すべてのブランチの親の役割を持つメインブランチが存在する。 "trunk" として知られることが多いが，Microsoft ではこれを MAIN と呼ぶ。MAIN には DEVELOPMENT と RELEASE という２つの主要ブランチがある。 最初のガイダンスでは開発ブランチ(DEVELOPMENT) について取り上げている。内容は比較的簡素で，基本的には企業のチームや機能の構成方法に帰着する，というものだ。ただし前のバージョンから継続している独

TokyoMercurial #3 の懇親会において、@cointoss1973 氏から以下の様な相談が: MQ パッチを "qpop -a" して、再度 "qpush -a" する際に、適用先リビジョンが変わってしまうのは、なんとかならないだろうか？ 最初に相談された時には、何の事やらワケワカで「？？？？ 」な状態だったのだが、お互いの前提条件に関して、色々刷り合わせを行った結果、以下の様なユースケースであることが判明: ローカルリポジトリの最新版を A-base とする MQ を使って、A-base を元に機能 A に関して作業を実施 優先度の高い機能 B の作業が、割り込んで来る 機能 A の MQ パッチを一旦 "qpop -a" 共有リポジトリから最新成果を pull ＋ 作業領域の update この時点の最新版を B-base とする B-base を元に機能 B の作業を実

http://partake.in/events/95ab571f-c477-43dd-8d96-396d3b670b6f:title=の成果発表です。 先日あるmercurialリポジトリのミラーリポジトリをgithubに作成したところ、開発がgithubに移ってしまうという(mercurial使い的には)ショッキングな出来事がありました。mercurial使いはいろいろ肩身が狭いですね。 それもこれも、「mercuiralを使いながらgithubのpull requestを取り込む方法」についてのノウハウが共有されていないことに問題があります。今後、二度と悲劇を繰り返さないために考察してみました。 想定する構成 考察した結果です。 bitbucket-and-github urlは次の通り central repository https://bitbucket.org/troter/

Mercurial 2.1 版から導入されたフェーズ機構は、『必要が無ければ、特に意識する必要が無い』類のもの。 でも、折角なので、一番手っ取り早くフェーズ機構の恩恵を受けるであろう MQ との併用モデルについて説明する。 以下の説明は、フェーズ機構の概要に関しては把握していることが前提。 まだ概要を知らない人は、"hg help phases" を参照のこと(ウェブ経由でも参照可能)。"s" が付く方 (phases) が概念としてのフェーズの説明で、付かない方がコマンドとしての phase の説明なので注意。 ＃ "export LANG=ja" 設定等が有効になっていれば、日本語化された説明を参照可能 さて、MQ を使っていて何が一番怖いかと言うと、個人的には以下の状況: push/pull/clone 契機で、MQ 配下のリビジョンが外部に漏れてしまう 一応、随分前から push

最新の情報に関しては、オンラインヘルプ "hg help largefiles"（ウェブからも参照可能）を参照してください。large 扱いのファイルの取得方法／契機周りが色々改善されています。 このエントリは、Mercurial Advent Calendar 2011 の 19 日目です。 Mercurial の 2.0 版から、largefiles エクステンション (※ 以下 "largefiles") が標準同梱されるようになりました。 このエントリでは、largefiles の概要と併せて、このエクステンションがどのような仕組みで対象ファイルの構成管理を行っているのか、ちょっとだけ内側の話をしてみたいと思います。 ちなみに、largefiles は名前こそ『large』を冠していますが、ファイルサイズの大小での使い分け以外にも、『バイナリファイルか否か』で使い分ける運用の検討を

※ NATIVE 設定周りと、.hgeol 設定反映契機に関する記述を改善しました＠2013-12-22 このエントリは、Mercurial Advent Calendar 2011 の5日目です。 Windows/Unix/Linux/Mac OS などなど、複数の環境における作業成果を、共有リポジトリ等を用いて共有する場合、環境毎にデフォルト値が異なる改行コードと文字コードは、かなりの確率でトラブルの原因となります。 このエントリでは、Mercurial における改行コードに関して説明しようと思います。 ＃ 改行コードの話が思いのほか長くなったので、文字コードは別エントリで .... (^ ^;;) Mercurial では 1.5.4 から、リポジトリ単位で改行コードを管理できる eol エクステンションが同梱されるようになりました。 改行コードの管理には、この eol エクステンシ

今年から始まったMercurial Advent Calendar 2011 - [PARTAKE]の1日目です。(あんまりフライングといわれるので記事コピーしました。)最初は小ネタという事で、MercurialのRebase拡張の使い方についてケーススタディで説明したいと思います。いろいろパターンを上げていったらかなり長い記事になってしまいました。読むのに10分くらいかかります。 説明に出てくるリポジトリはhttps://bitbucket.org/troter/mercurial-advent-calendar-2011-1/に置いてあるシェルスクリプトで作成出来ます。unixやcygwinの環境が有る方は次のコマンドで作業環境が整います。（コマンドを列挙しているだけなのでwindows環境でも簡単に再現できると思います。） $ hg clone https://bitbucket.o

mercurialでは一度おこなったコミットは基本的には取り消せません。ブランチを作成するためにもコミットが必要なため、gitのようにカジュアルにブランチのリネームを行う事ができません。ここではそんな中でも何とかブランチをリネームするための3つの方法を紹介したいと思います。 紹介する方法 リネームしたいブランチの途中でブランチを切る。リネーム後のブランチを作成し、リネームしたいブランチをマージする。リネーム後のブランチを作成し、リネームしたいブランチをtransplantする。 リポジトリの例 次の様なリポジトリで考えていきます。bad-name-branchをadd-hginoreに変更したいです。 @ changeset: 4:a1b706bc0a8e | branch: bad-name-branch | tag: tip | summary: ignore log director

Git、大人気ですね。bitbucketもとうとうGitをサポートするみたいです。 Bitbucket now rocks Git – Bitbucket blog bitbucketは、デザインこそ残念な感じですが容量制限なしでクローズドリポジトリも使い放題ということで、内容としてはGithubよりもかなり素敵。 これを機にbitbucketユーザが広がるといいなーと思っています。 bitbucketといえば、Mercurial。僕も初めはGitを使っていたのですが、あのややこしい雰囲気と自分のネットワーク環境だと使うのがかなりしんどそうだったので、それ以降メインはMercurialになってます。そこらへんの経緯は以前書いた日記に詳しく書いてます。 gitやめてmercurialとtortoiseHGをインストール Mercurial自体はわかりやすくてとても気にいってるのですが、残念な