Mercurialはmercurialでpush済みの名前付きブランチをリネームする三つの方法の記事にあるように一度作成したものはすべて記録するという設計なので、確かにGitのように表題のAPIは提供されていません。 しかし、本質的には単純にファイルを書き換えているだけなので、pushしていないローカルの環境では、ブランチ名を変更したりブランチを削除することは簡単にできます。 MQ拡張によりパッチ化することでこれらを実現していきます。 ブランチを切ったけど名前間違っちゃった
1. はじめてのMercurial/Bitbucket 日本CodeIgniterユーザ会 Kenji Suzuki 2011/02/19 CodeIgniter and its logo are property of EllisLab Inc CodeIgniter 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 Inc CodeIgniter Users Group in Japan
2009-05-070. Preface 2009-05-071. How did we get here? 2009-05-072. A tour of Mercurial: the basics 2009-05-073. A tour of Mercurial: merging work 2009-05-074. Behind the scenes 2009-05-075. Mercurial in daily use 2009-05-076. Collaborating with other people 2009-05-077. File names and pattern matching 2009-05-078. Managing releases and branchy development 2009-05-079. Finding and fixing mistakes
Rebase Extension This extension is distributed along with Mercurial releases Author: Stefano Tortarolo 1. Introduction Rebase allows moving commits around in Mercurial's history (using a series of internal merges). This has many uses: moving changesets between branches "linearizing" history reordering changesets collapsing multiple changes into one changeset 2. Configuration Enable the extension i
Gitのリベース(Rebase)機能がようやく分かったのでメモ。 MercurialのMQは、GitのRebase機能を実現する重要な機能だ。 【元ネタ】 git rebaseって超便利じゃね? - Seasons.NET Gitを使いこなすための20のコマンド - SourceForge.JP Magazine : オープンソースの話題満載 履歴の書き換えによって生じる問題 Mercurial: "Managing change with Mercurial Queues" を読む(3) | Inside ASCADE Pro Gitの日本語 Mercurialではじめる分散構成管理:第6回 勝手に「分散構成管理」 ~非Mercurial環境との共存|gihyo.jp … 技術評論社 4.6. コミット ― TortoiseHg v0.8.2 documentation Subversi
OK, after basic anti-patterns discussed in part 1 and 2 of this series, it’s time to discuss a bit more sophisticated messaging anti-patterns and how to write better messaging-oriented applications. Using appropriate message type So let’s start with the first principles of messaging. Why we want to use a message broker in our architecture? The most probable answer is to exchange data in asynchrono
みんな大好き GitHub のスタッフ blog で『Github は如何にして速いままでいられるか』という記事が出ていました。内製のツールなどが screenshot 付きで紹介されています。 How we keep GitHub fast しかしツールの見栄えの良さにちょっとくらくらしますね。Web な startup だとよくありがちな Staff モードの SQL query log や、call graph。Graphite や statsd を使ったグラフを大型モニタに映し出すのがNew York の startup では流行って(いるような気がし)ますが、ここまでビジュアル的によく出来たものは見たことがないです。 Etsy の performance dashboard 結論としてはまとまっていませんが、一言でいえば『メトリックス大事』ということでしょうか。皆さんの会社では、
尊敬するDOAの先輩である、渡辺さんがこう書いている。 「データモデルなきアジャイル」の危うさ、より その種のシステム(※引用者補記:販売管理システムや生産管理システムといった基幹系業務支援システム)をアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 それに対して、稲見さんがこんなコメントをしている。 アジャイル開発と言っても色々で、最近流行りのScrumという手法は、開発の中身に関しては何も言及していません。ですが、私の知っているある人達
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く