Mercurialで別オリジンのリポジトリ間の同期を取る運用の仕方について - monjudoh’s diary
前説 DjangoでWebアプリを開発していて自分はJavaScript部分を担当しています。 で、サーバ側を動かさないと開発できないのは辛いので、 サーバサイドで生成されたHTMLとJSONをwgetして、js/dummy/とかに配置し、 各種URLの参照を書き換えてローカルでJavaScriptだけもりもり実装できるようにしました。 サーバサイドの実装に先行してJavaScriptの実装を進めていたため、 プロジェクト全体(django-apps)と独立してバージョン管理したかったため、 static配下だけが入ったdjango-staticというリポジトリを作成し、 そちらで開発を進めていきました。 今回の話は、プロジェクト全体(django-apps)とJavaScript&CSSだけ(django-static)の 二つのリポジトリの同期をとって運用していく話です。 準備 hg
Scaling Mercurial at Facebook
With thousands of commits a week across hundreds of thousands of files, Facebook’s main source repository is enormous–many times larger than even the Linux kernel, which checked in at 17 million lines of code and 44,000 files in 2013. Given our size and complexity—and Facebook’s practice of shipping code twice a day–improving our source control is one way we help our engineers move fast. Choosing
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
Mercurial 対 Git：なぜ Mercurial を選ぶのか？ - Atlassian Japan
ここで見たように、Git は、Subversion ユーザーにその CLI に早く慣れてもらうようにするということをあまり考慮していません。 新しいコマンドを入力するために指を再度トレーニングすることによりこの問題を回避することはできますが、それでもシステムを移行する上での障害の一つになるでしょう。その上、Subversion ユーザーにとってフレンドリーで、かつ、強力で美しいインターフェースをもった Mercurial があるので、Git がなくても問題はありません。 履歴が安全な Mercurial Mercurial の哲学は、 “履歴は永久的で神聖である” ということです。Mercurial のコアには、履歴を変更できるコマンドがたった一つだけあります。hg rollback です。このコマンドは直前のプルやコミットを “取り消し” ますが、それより前のものには一切触れません。 G
「git commit するまえに考えるべき10のこと」がDVCS的じゃない件 - うさぎ組
はじめに git commit するまえに考えるべき10のこと | Act as Professionalを読んでいろいろと思うことがあったので書きました。 これはSCMBootCamp主催者としてとか、Mercurialユーザーを代表してとかではありません。 僕はこう思う。ということです。 読むの面倒な人は最下部のまとめだけ読めばok。 commit != push DVCSの利点はローカルコミットという概念を持ち込んだことです。これにより、高速な履歴追加、安全なマージを手に入れることができました。 件の記事を読んでいて気になったのは、commitという単語です。 特に、 1コミットに1つの対応 コメントアウトしたコードをコミットしない テストが正常に通過したものにしてください コミットメッセージの1行目は”短い説明” コミットメッセージのスタイル コミットメッセージのボディは有意義な内
(特に Git 併用ユーザには是非読んでおいて欲しい) Mercurial における『ブランチ』の概念 〜 その２ - 彷徨えるフジワラ
今回のお題は、Git における『ブランチ』と同じものと誤解してGit 併用ユーザが混乱する事案が多発する、Mercurial の『名前付きブランチ』に関して。 以下、各回で説明する主なトピック: その１: 名前無しブランチ その２: 名前付きブランチ(本エントリ) その３： ブックマーク その４： 構造的ブランチ その５： 名前付きブランチ運用で必要なトピック その６： 名前付きブランチに関するちょっと踏み込んだ話 名前付きブランチ Mercurial では、履歴記録の際に、各リビジョンに対して『所属するグループの名前』を1つだけ指定することができる。この情報は、履歴情報の一部として、ハッシュ値算出にも使用され、永続的に記録される。 通常、新規に作成されたリビジョンは: 親リビジョンと同じグループに属する リポジトリで一番最初に記録されるリビジョンは、特に指定の無い場合は "default
Git 対 Mercurial：なぜ Git を選ぶのか？ - Atlassian Japan
今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが Vim と Emacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは本来の仕事そっちのけ
Hgに慣れてしまった人のためのGitメモ - kuenishi's blog
基本的な開発スタイルはHgでもGitでもそう変わらないと思うので、考え方を完全に持ち込む、というかHgに慣れたんだけどみんなGitHubにいるからGitも使わざるを得ないとかそういう人（というか私）のための備忘録として。単にどのVCSがどう違うかは大体知っているんだけど、いざやってみようとするとコケまくる人たちのために。。。 ソースはgittutorial(7)。 結論からいうとこの表を書きたかった。 やりたいこと mercurial git レポジトリ作成 hg init (みんなでさわる場合)git init --bare --shared レポジトリクローン hg clone git clone 変更内容のコミット hg ci git commit -a *1 変更状態 hg diff git diff revert hg revert -all . git reset --hard
いっしょに仕事をしたいプログラマ 5つの特徴 - たごもりすメモ
ちょっとこんなことを考えるきっかけがあったので、ざっと書き出してみた。Webに公開されている情報からあるプログラマについて見てみたとき、どういう人ならいっしょに働いてもいいかについて。 ここに書く内容はソースコードの品質以前の問題についてのみにしてある。だからこの特徴を満たしていればどうということに直接なるわけではない。ただ、欠けているところがあれば、少なくとも自分はその人といっしょに仕事をしたいとは思わないだろう。 なお自分は現勤務先の採用活動にはかかわっておらず、このエントリの内容は勤務先の採用基準とは全く無関係です。 学生さんなどの場合にはまた話が違うと思います。 あと割と自分のことは棚に上げてます。「お前これできてねえじゃん」という部分については都度ご指摘をいただけますと大変ありがたく思います……。 1. その人が書いたソースコードが公開されている 日本語で何を言われてもぶっちゃけ
“Git だろうと Mercurial だろうと、ブランチ名をzshのプロンプトにスマートに表示する方法”が便利すぎる件
“Git だろうと Mercurial だろうと、ブランチ名をzshのプロンプトにスマートに表示する方法” で紹介されている zsh の vcs_info という関数を使って git や mercurial のブランチ名をプロンプトに表示しているみたいです。 git 使ってたら実際どのブランチいじってるのかわからなくなることが 多々あって困ってたのでさっそく導入してみました。 はまったのは “vcs_info: function definition file not found” というエラーが 表示され vcs_info が使用できなかった。 これはバージョンを 4.3.6-dev-0+20080929-1 以降にすればいいらしい。 mac の ports の場合は zsh-devel でいれないと 4.3.6 以下なので使用できない。 zsh-devel をインストールして /opt
ネットワークがつながらない状況での分散開発はどうやるのがいいのか - wyukawa's diary
ネットワークがつながらない状況での分散開発はどうやるのがいいかを考えてみる。 以前似たような経験したのは自分たちが複数の協力会社の１つという立場で、元請けのSVNリポジトリに直接コミットするというもの。ネットワークはつながっています。また元請けは基本的に開発はしておらず、協力会社も開発はほとんど終わっていて変更はバグ修正のみという状況です。 イメージはこんな感じ。 リリース（元請けのSVNリポジトリに直接コミット）する場合は、自分たちのSVNリポジトリにタグうってexportして、あらかじめチェックアウトしておいた元請けのSVNリポジトリのソースに上書きしてコミットします。この辺もHudsonで自動化してましたね。あとコミットするファイル一覧も出しました。元請けはそれと実際にコミットされたソースとを比較して漏れが無いか確認してたみたいです。 しかしこの方法だとファイルの削除やリネームに対応
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
bitbucketの使い方
分散リポジトリ型時代のソフトウェア構成管理