VCS package guidelines - ArchWiki
Version control systems can be used for retrieval of source code for both usual statically versioned packages and latest (trunk) version of a development branch. This article covers both cases. Prototypes Use only the PKGBUILD prototypes provided in the pacman package (PKGBUILD-split.proto, PKGBUILD-vcs.proto and PKGBUILD.proto in /usr/share/pacman). Guidelines Package naming Suffix pkgname with -
DVCSのリンク集 - うさぎ組
共有したい個人メモということで。会社の人とかね。 雑感。DVCSの情報は、不正確なコピペ情報が反乱していて、Git, Hgあたりは結構ひどい。有用なやつはTipsとしてまとめたけど、なかには誤読すると大変なものもある。 「急がば回れ」的に基本から勉強するのが間違える可能性がかなり低くなる。 基本から体系的に学べるものは各DVCSのガイドにした。 ガイドにあがるようなものでも、15hくらいあればハンズオンしながらでもこなせるので、仕事中に困りながら1weekうまくいかないくらいなら、基本からやって、出来る範囲だけを仕事でやるほうがいい。 正直、DVCSなくても仕事できるし、出来る前提の職場なら、職場のワークフローを先輩に聞きながら1weekくらい作業すればいい。 SCM 概念とか DVCSについてだし、書きかけ。【5分でわかるDVCS！ + 20分でわかるGit入門 by Kyon Mm o
（特に Git 併用ユーザには是非読んでおいて欲しい） Mercurial における『ブランチ』の概念 〜 その６ - 彷徨えるフジワラ
長々続いたこのシリーズも、今回で一応終了。 最終回の今回は、『名前付きブランチ』に関する、ちょっと踏み込んだ話題を扱う。 普通に運用する場合には、それほど必要となる局面は無いかも知れないけれど、知っていればちょっとは便利になるかもしれない事柄などを。 以下、各回で説明する主なトピック: その１： 名前無しブランチ その２： 名前付きブランチ その３： ブックマーク その４： 構造的ブランチ その５： 名前付きブランチ運用で必要なトピック その６： 名前付きブランチに関するちょっと踏み込んだ話（本エントリ） 構造制約を持たない名前付きブランチ その２でも述べたように、『名前付き』ブランチは、各リビジョン毎に持っている『ブランチ名』属性を元にした、一種のリビジョングループと言える。 情報管理上、『ブックマーク』や Git の『ブランチ』のように、単一の名称に対して『ヘッド』が一つ、といった制約
（特に Git 併用ユーザには是非読んでおいて欲しい） Mercurial における『ブランチ』の概念 〜 その５ - 彷徨えるフジワラ
今回は『名前付きブランチ』運用時に必要となる幾つかのトピックを扱う。 ちなみに、当初は『５回』の予定だったけど、あと１回加えて、全６回になる模様。 以下、各回で説明する主なトピック: その１： 名前無しブランチ その２： 名前付きブランチ その３： ブックマーク その４： 構造的ブランチ その５： 名前付きブランチ運用で必要なトピック（本エントリ） その６： 名前付きブランチに関するちょっと踏み込んだ話 名前付きブランチ併用時のリポジトリ連携 連携先リポジトリに対して "hg push" による履歴の反映を行う場合、原則としては： 連携先に新たに『ヘッド』を作るようなリビジョンの反映は禁止 という仕様になっているが、増加した『ブランチヘッド』のマージ責務の先送りを回避する上では、妥当な仕様と言えるだろう。 但し、2010-07-01 リリースの1.6 版より前の Mercurial では:
Mercurial管理下のファイルを検索する grepfile extension - 放牧日記
'hg grep'は履歴を検索してしまうし、'hg locate "set:grep('hogehoge')"'はマッチした行を表示してくれないので、この二つのコマンドの間の子を作って見ました。 https://bitbucket.org/troter/hg-grepfile 設定 [extensions] grepfile = [path to]/grepfile.py 使い方 こんな感じで管理下のファイルを検索できます。 % hg grepfile -n ctx.walk mercurial/cmdutil.py:1777: for abs in ctx.walk(m): mercurial/commands.py:283: for abs in ctx.walk(m): mercurial/commands.py:1085: for abs in ctx.walk(m): mercu
（特に Git 併用ユーザには是非読んでおいて欲しい） Mercurial における『ブランチ』の概念 〜 その４ - 彷徨えるフジワラ
今回は "topological branch" の話。 以前は原語の "topological branch" を正確に直訳した『位相(幾何学)的ブランチ』という呼称を用いていたが、現在はオンラインヘルプも含めて『構造的ブランチ』という呼称を用いるようにしているので、旧来の呼称に馴染んでいる人は要注意。 以下、各回で説明する主なトピック: その１： 名前無しブランチ その２： 名前付きブランチ その３： ブックマーク その４： 構造的ブランチ（本エントリ） その５： 名前付きブランチ運用で必要なトピック その６： 名前付きブランチに関するちょっと踏み込んだ話 構造的ブランチ 再度の確認となるが、リビジョン X が『名前無しブランチ』となる条件は以下の通り。 X の親リビジョン P が、P と同一の『名前付きブランチ』内に、X 以外の子リビジョンを最低１つ持つ リビジョン X と P が、
(特に Git 併用ユーザには是非読んでおいて欲しい) Mercurial における『ブランチ』の概念 〜 その３ - 彷徨えるフジワラ
※ 2013-10-10: 暗黙の更新反映等、ブックマークの伝搬に関して、記述を補足 当初は『構造的ブランチ』の説明をしようと思っていたのだけれど、『特に Git 併用ユーザには是非読んでおいて欲しい』と冠していることもあり、Git ユーザにとっての『ブランチ』のイメージに近い『ブックマーク』の説明を先に持ってくることに。 以下、各回で説明する主なトピック： その１： 名前無しブランチ その２： 名前付きブランチ その３： ブックマーク（本エントリ） その４： 構造的ブランチ その５： 名前付きブランチ運用で必要なトピック その６： 名前付きブランチに関するちょっと踏み込んだ話 ブックマークの基本的な機能 Mercurial では『ブックマーク』(bookmark)という機能が使用出来る (1.8 版以降は基本機能として、それ以前は拡張機能としてサポート)。 『ブックマーク』では、特定のリ
(特に Git 併用ユーザには是非読んでおいて欲しい) Mercurial における『ブランチ』の概念 〜 その２ - 彷徨えるフジワラ
今回のお題は、Git における『ブランチ』と同じものと誤解してGit 併用ユーザが混乱する事案が多発する、Mercurial の『名前付きブランチ』に関して。 以下、各回で説明する主なトピック: その１: 名前無しブランチ その２: 名前付きブランチ(本エントリ) その３： ブックマーク その４： 構造的ブランチ その５： 名前付きブランチ運用で必要なトピック その６： 名前付きブランチに関するちょっと踏み込んだ話 名前付きブランチ Mercurial では、履歴記録の際に、各リビジョンに対して『所属するグループの名前』を1つだけ指定することができる。この情報は、履歴情報の一部として、ハッシュ値算出にも使用され、永続的に記録される。 通常、新規に作成されたリビジョンは: 親リビジョンと同じグループに属する リポジトリで一番最初に記録されるリビジョンは、特に指定の無い場合は "default
(特に Git 併用ユーザには是非読んでおいて欲しい) Mercurial における『ブランチ』の概念 〜 その１ - 彷徨えるフジワラ
ここ暫く、Twitter や ML 等で、Mercurial の『ブランチ』に関する質問 (特に Git の『ブランチ』との対比) に答える機会が度々あったので、Mercurial における『ブランチ』の概念に関してまとめてみた。 実のところ、SCMBootCamp in Nagoya #1 での、稲田氏 (id:methane) の基調講演資料における Mercurial のブランチに関する説明 (30ページ目) を見て: 別途口頭での説明が無いと、初学者や他のツールからの移行者にとっては、誤解を招きやすいのではなかろうか？ と思ったのが、このエントリを書く元々の動機だったのだけれど、書き上げるのにかれこれ３ヶ月以上を要してしまったというのは、反省することしきり。 っつーか、ここ暫くは本家に (議論の叩き台としてリジェクト覚悟で) パッチ提案したりと、色々アレだったんで、その辺は勘弁して
TokyoMercurial#4.5 Mercurial Queues ハンズオン を開催しました。 - 放牧日記
2012/06/09(土)にTokyoMercurial#4.5 Mercurial Queues ハンズオン を開催しました。サポートスタッフのid:flying-foozyさん、id:cointoss1973さん、参加者の皆さんお疲れさまでした。 TokyoMercurial 公式ページ http://connpass.com/event/486/:title= 勉強会の流れ Mercurial Queuesの導入のプレゼンとハンズオンを行いました。 Mercurial Queues ハンズオン (TokyoMercurial#4.5) https://docs.google.com/drawings/d/1pg2O_Q2Dqgl08raTw544yCb2lXujieANXDFuRQFqrsg/edit:title= https://bitbucket.org/mercurialjp/
bitbucketで一人pullrequestとかしてた
bitbucketで遊んでみた ちなみにGW中bitbucketとずっと戯れていたわけじゃないよ。猫と戯れていただけだよ(´；ω；｀) bitbucket は自分のリポジトリをforkできます。 →確か前々回ぐらいの #TokyoMercurial で @troter さんがそんなことを呟いていましたが、確かにできましたｗ githubはしらん。 まあ、普通しないよね。練習以外に何に使うのだろう… あとpull request そのものについて詳しい訳じゃないので間違っている場合はご指摘ください。 名前からして「ねー、ねー。僕のリポジトリ（ブランチ）pullしてよ〜」なんですよね。 準備 とりあえず適当にリポジトリを作ります 作ったらテキトーにコミットしてpushしておきます bitbucketに戻ってforkしてみます 普通他の人からforkするときはリポジトリ名
Mercurial でのサブリポジトリの利用 - 彷徨えるフジワラ
ここ暫く、#TokyoMercurial (+ 懇親会)の席や twitter上などで、サブリポジトリ(subrepo)の利用に関する質問等が多かったのですが、口頭説明や、twitter の文字制限内では、なかなか正確に伝えるのが難しかったので、ブログエントリとしてまとめてみました。 っつーか、ある程度書きあがってから、僕の勘違いに突っ込みが入って、慌てて加筆修正しました(笑)。指摘感謝です！ > @yujauja 氏 サブリポジトリの利用開始 Mercurial のサブリポジトリ機能とは: Mercurial リポジトリを親に、外部のリポジトリやプロジェクトを入れ子にし、 コマンドの実行の際に、 それら一連のリポジトリに対して処理を行えるようにします。 〜 "hg help subrepos" より というものです。 サブリポジトリの追加手順は、hg help subrepos (日本語
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
いろいろ - hg and git
hg と git のコマンド相違点 似てるようで違う hg と git の違いのメモ。 基本 working directory : バージョン管理対象のファイルを置くディレクトリ。バージョン管理対象にしないオブジェクトファイル等を一緒に置いても良い。 repository : working directory の一番上にある、.hg (hg の場合) または .git (git の場合) ディレクトリの中身。バージョン管理に関する情報、履歴等が置かれる。 あるところにあるリポジトリを追いかけるだけの使い方 たとえば www.kernel.org の Linus のリポジトリを追いかけるとか、そんな使い方の場合。一番シンプルな例。 最初の取得 (リポジトリを取得し作業ディレクトリに最新の内容を展開する) hg clone url [dir] git clone url [dir] 最新リ
ファイル内容をマージしないマージ - 彷徨えるフジワラ
Mercurial 2.1 リリース絡みのドタバタで間があいてしまったけれど、TokyoMercurial #1 で話題になった件の詳細シリーズ - その５。 "hg merge" でリビジョンの枝分かれをマージする際に、一般的な設定であれば、いわゆる『3-way マージ』と呼ばれる方法で、共通の祖先時点の内容に対して、それぞれの枝分かれにおける変更内容が統合される。 しかし、場合によっては、『マージ先の枝』（第1親側）ないし『マージ対象の枝』(第2親側)での変更内容を破棄してしまいたい (＝ 反対側の内容のみを残したい) 事もある。 以下は、そういった場合におけるコマンド実行の方法についての説明。 マージ実施時点で内容を残したい枝が確定している場合 まずは『マージを実施するが、マージ結果は完全に、どちらか一方の枝の内容のみを残したい』というケース。 単に『内容を破棄する方の枝を、マージし
"hg rollback" のガード機能 - 彷徨えるフジワラ
TokyoMercurial #1 で話題になった件の詳細シリーズ - その１。 ちなみに、TokyoMercurial #1 開催日の 01/14 から随分時間が経っているのは、決して忘れていたとかではなく、なんとか 2.1 版リリースに間に合わせようと case insensitive filesystem 対応の修正を頑張っていたため。 もっとも 01/19 時点でリリースに向けたコード凍結宣言が出てしまったので、結局修正は間に合わなかったのだけれど .... まぁ、影響範囲が思った以上に広いので、ボチボチ行くとするか。 で、"hg rollback" のガード機能の話。 今更ではあるかもしれないが、"hg rollback" の機能を再確認しておくと、『直前に追加記録された履歴情報を、管理領域から破棄する』というもの。 ちなみに一見同じような『やりなおし』的ニュアンスを持つ "hg
Mercurial の文字コード設定説明ページを更新した - 彷徨えるフジワラ
TokyoMercurial #1 参加の際に気になったトピックについて、詳細を書こうとおもったのだが、そういえば『日本語の取り扱いってどうなってるんでしょう？』という質問があったなぁ、と思い出した。 職場とかでの導入／普及の際に、やっぱり日本語の取り扱いの可否が、大きなネックになっているらしい。 一応、Mercurial Advent Calendar の一環で文字コードのエントリも書いたのだが、そもそも自分のホームページの文字コード設定の説明が現状を反映していないのが長いこと気がかりだったので、これを機に更新することに。 まとめると『Mercurial は日本語ファイル名を使う場合は少々考慮が必要だけど、それ以外は特に面倒無く日本語対応できてますよ』という話。
2011-12-02
この記事は、Mercurial Advent Calendar 2011の2日目の記事です。 revsetsとは? 築いてきた歴史から特定のチェンジセットを効率よく検索するための、Mercurialのサブセット言語だ。 Mercurialでは、 $ hg log -r 1000のlogコマンドように'-r'(--revision)オプションを付与できるコマンド(logコマンドは特に-rを多用する)がいくつかあるが、単にチェンジセットIDやリビジョン番号だけでなく、 revsetsと呼ばれる関数言語(helpでは問い合わせ言語と訳されている)を使うことで複雑なリビジョンを指定できる。 しかし、残念ながらこのrevsetsについて周知している人は少ないのではないだろうか? このrevsetsを使う時はhg logコマンドの場合が最も多いと考えているが、'hg log'のhelpにはrevset
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DVCS workflows for Bitbucket | Bitbucket Cloud | Atlassian Support