Mercurial エコシステム
395 views
Skip to first unread message
Kaz Nishimura
Jan 6, 2015, 7:02:26 PM1/6/15
to mercur...@googlegroups.com
最近、某プロジェクトで Git の利用を余儀なくされていますが、GitHub を初めとして Gerrit 等 Git 周辺のエコシステムは既に回り始めているなあと感じざるを得ません。
Mercurial は、私的には「もっとがんばりましょう」ですかね。named branch とか個人的には Git より好きなのですが、世の中 Git に対応したサービスやソフトが増える一方なので、ちょっとくやしいです。
Mercurial は、私的には「もっとがんばりましょう」ですかね。named branch とか個人的には Git より好きなのですが、世の中 Git に対応したサービスやソフトが増える一方なので、ちょっとくやしいです。
Kaz Nishimura
Jan 11, 2015, 3:44:59 AM1/11/15
to mercur...@googlegroups.com
スレッドが続かないようなので、適当につなげます。
Microsoft Azure の Web サーバーだと Mercurial からの自動配置に対応しているようなんですけど、利用してる人はいるんでしょうかね (いないのが前提のなかとセルフつっこみ)。AWS には単なる Web サーバーのサービスがないようですし、Google App Engine は今のところ Git のみ対応と言った感じですので Mercurial に対応していると言う点では便利なサービスかと思うのですがね。
Microsoft Azure の Web サーバーだと Mercurial からの自動配置に対応しているようなんですけど、利用してる人はいるんでしょうかね (いないのが前提のなかとセルフつっこみ)。AWS には単なる Web サーバーのサービスがないようですし、Google App Engine は今のところ Git のみ対応と言った感じですので Mercurial に対応していると言う点では便利なサービスかと思うのですがね。
Katsunori Fujiwara
Jan 15, 2015, 10:55:56 AM1/15/15
to mercurial-ja
藤原です。
2015年1月11日 17:44 Kaz Nishimura <kaz...@vx68k.org>:
PaaS 系のサービス事情には詳しくないので、こちらに関しては言及でき
ませんが：
2015年1月7日 9:02 Kaz Nishimura <kaz...@vx68k.org>:
こちらに関しては、”「もっとがんばりましょう」ですかね”→「そうで
すね」で終わらすのもアレなので、普段思っていることなどを書いてみよ
うと思います。
長い割りに、特に結論もなにもありませんが（笑）
ネット上での声の大きさこそ少ないものの、守秘義務契約を締結しての受
託開発や、自社の競争力の源泉となるようなクローズドなソフトの開発は
少なくありません。
このような開発では、GitHub や Bitbucket のような海外サービス (国内
司法の手が及ばない) は勿論、国内のサービス提供者であっても、軽々に
は外部組織にソースコードを預けるわけには行かないケースが多い筈です。
私自身の経験でも、発注元によるセキュリティ監査で、外部サービスにデー
タを預けてないことを確認されたりしたことがあります。
まぁ、「"プライベート" リポジトリにおけるアクセス制限」の安全性と、
開発対象の漏洩リスク、漏洩防止のコストのバランスを考えた上で、「安
全」とみなすか否かは、個々の事情によりますが……
しかし、そういったクローズドな開発であっても、リポジトリ管理やバグ
管理のために、何らかのシステムを導入する必要が出てきます。例えば、
Mercurial のリポジトリ管理なら HgLab, Rhodecode, Kallithea,
SCM-Manager、バグ管理なら Bugzilla, Trac, Redmine 等々。少なくとも
「Excel でバグ管理」はやりたくない筈（笑）。
http://mercurial.selenic.com/wiki/MercurialHosting#Intranet_hosting
Rhodecode がライセンス変更によって有償化の敷居を下げたのは、この手
のクローズドな開発のニーズが、マネタイズ可能な程度には存在すること
を意味しているのかなぁ、などと推測してます。
個人的には、こういった、いわゆるオンプレミス用途向けの、リポジトリ
管理ツールやバグ管理ツール(の連携機能)に期待するところが大きいです。
「便利なのは Git じゃなくて GitHub」と言う人もいるぐらいですし（笑）
Rhodecode に関しては、有償化がちゃんとビジネスとして成立して欲しい
一方で、利用する側としては、規模制限によって導入の心理的敷居が上がっ
てしまうのが悩ましいところです。また、fork した Kallithea と、上手
いこと棲み分けできるとよいのですが……。
それから、この手の開発インフラの導入・保守は「面倒臭い」と相場が決
まっていますから（笑）、「面倒臭さを補って余りある利便性の高さ」
and/or「物凄く簡単な導入・保守手順」が求められるでしょう。
以前、Nishimura さんが QNAP 上で Mercurial を使えるようにする話を
されていましたが、もうちょっと欲張って:
NAS BOX の購入
→ LAN に接続
→ 電源 ON
(→ USB メモリ等経由で追加インストール or ブートイメージ上書き)
→ Kallithea + Redmine が即利用可能
みたいなことができると良いですよねぇ。更に「USB HDD 接続 →自動バッ
クアップ」とかできたら最高です(笑)。
Fossil が履歴管理機能の他に、バグ管理／Wiki 機能を統合してるのは、
いいところを付いてくるなぁ、と思います。
http://en.wikipedia.org/wiki/Fossil_%28software%29
ちなみに、つい先日、FLOSS Weekly のゲストとして、Fossil の開発者が
出演してました (私自身はまだ視聴してませんが…)。
http://twit.tv/show/floss-weekly/320
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
2015年1月11日 17:44 Kaz Nishimura <kaz...@vx68k.org>:
ませんが：
2015年1月7日 9:02 Kaz Nishimura <kaz...@vx68k.org>:
すね」で終わらすのもアレなので、普段思っていることなどを書いてみよ
うと思います。
長い割りに、特に結論もなにもありませんが（笑）
ネット上での声の大きさこそ少ないものの、守秘義務契約を締結しての受
託開発や、自社の競争力の源泉となるようなクローズドなソフトの開発は
少なくありません。
このような開発では、GitHub や Bitbucket のような海外サービス (国内
司法の手が及ばない) は勿論、国内のサービス提供者であっても、軽々に
は外部組織にソースコードを預けるわけには行かないケースが多い筈です。
私自身の経験でも、発注元によるセキュリティ監査で、外部サービスにデー
タを預けてないことを確認されたりしたことがあります。
まぁ、「"プライベート" リポジトリにおけるアクセス制限」の安全性と、
開発対象の漏洩リスク、漏洩防止のコストのバランスを考えた上で、「安
全」とみなすか否かは、個々の事情によりますが……
しかし、そういったクローズドな開発であっても、リポジトリ管理やバグ
管理のために、何らかのシステムを導入する必要が出てきます。例えば、
Mercurial のリポジトリ管理なら HgLab, Rhodecode, Kallithea,
SCM-Manager、バグ管理なら Bugzilla, Trac, Redmine 等々。少なくとも
「Excel でバグ管理」はやりたくない筈（笑）。
http://mercurial.selenic.com/wiki/MercurialHosting#Intranet_hosting
Rhodecode がライセンス変更によって有償化の敷居を下げたのは、この手
のクローズドな開発のニーズが、マネタイズ可能な程度には存在すること
を意味しているのかなぁ、などと推測してます。
個人的には、こういった、いわゆるオンプレミス用途向けの、リポジトリ
管理ツールやバグ管理ツール(の連携機能)に期待するところが大きいです。
「便利なのは Git じゃなくて GitHub」と言う人もいるぐらいですし（笑）
Rhodecode に関しては、有償化がちゃんとビジネスとして成立して欲しい
一方で、利用する側としては、規模制限によって導入の心理的敷居が上がっ
てしまうのが悩ましいところです。また、fork した Kallithea と、上手
いこと棲み分けできるとよいのですが……。
それから、この手の開発インフラの導入・保守は「面倒臭い」と相場が決
まっていますから（笑）、「面倒臭さを補って余りある利便性の高さ」
and/or「物凄く簡単な導入・保守手順」が求められるでしょう。
以前、Nishimura さんが QNAP 上で Mercurial を使えるようにする話を
されていましたが、もうちょっと欲張って:
NAS BOX の購入
→ LAN に接続
→ 電源 ON
(→ USB メモリ等経由で追加インストール or ブートイメージ上書き)
→ Kallithea + Redmine が即利用可能
みたいなことができると良いですよねぇ。更に「USB HDD 接続 →自動バッ
クアップ」とかできたら最高です(笑)。
Fossil が履歴管理機能の他に、バグ管理／Wiki 機能を統合してるのは、
いいところを付いてくるなぁ、と思います。
http://en.wikipedia.org/wiki/Fossil_%28software%29
ちなみに、つい先日、FLOSS Weekly のゲストとして、Fossil の開発者が
出演してました (私自身はまだ視聴してませんが…)。
http://twit.tv/show/floss-weekly/320
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
Kaz Nishimura
Jan 15, 2015, 5:37:34 PM1/15/15
to mercur...@googlegroups.com
オンプレミスの話で言うと、Bitbucket を運営している Atlassian が出している Stash は Git 専用ですし、ちょっとだけ書いた Gerrit はオンプレミスで利用することも可能なようなので、ソースコードを内部に留める場合でも Git の方が既に便利になっているのではないかとは感じています。Mercurial を選ぶことがプロジェクトにとって既にリスクになりつつあるのではないかと言うのが最近危惧している点ですね。
そんな中で Mercurial をもっと利用しやすくする動きがないのかと思ったのが事の発端ですね。
そんな中で Mercurial をもっと利用しやすくする動きがないのかと思ったのが事の発端ですね。
Kaz Nishimura
Jan 15, 2015, 6:47:12 PM1/15/15
to mercur...@googlegroups.com
おまけとして、Embarcadero RAD Studio という製品の Mercurial 対応はここ何年か取り組んでいるのですが、最初は Subversion だけ対応していたものが最新バージョンでは Git 標準対応になってしまいました。Git と Mercurial では単体のバージョン管理機能で比較すれば遜色はないと信じていますが、周辺ツールの充実度では完全に負けているのではないかと感じているところです。
もはや利用者の好みで選べる段階はとうに終わっていて、好き嫌いに関わらず Git を選ばざるを得ない環境ができつつあるのではないかと。そんな中で Mercurial にとって明るい材料はないものだろうかと言うのがこのトピックを始めたきっかけですかね。
もはや利用者の好みで選べる段階はとうに終わっていて、好き嫌いに関わらず Git を選ばざるを得ない環境ができつつあるのではないかと。そんな中で Mercurial にとって明るい材料はないものだろうかと言うのがこのトピックを始めたきっかけですかね。
Toshi MARUYAMA
Jan 17, 2015, 5:34:19 AM1/17/15
to mercur...@googlegroups.com
まるやまです。
On 2015-01-16 08:47 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
> おまけとして、Embarcadero RAD Studio という製品の Mercurial 対応はここ何年か取り組んでいる
> のですが、最初は Subversion だけ対応していたものが最新バージョンでは Git 標準対応になって
> しまいました。Git と Mercurial では単体のバージョン管理機能で比較すれば遜色はないと信じて
> いますが、周辺ツールの充実度では完全に負けているのではないかと感じているところです。
>
> もはや利用者の好みで選べる段階はとうに終わっていて、好き嫌いに関わらず Git を選ばざるを得
> ない環境ができつつあるのではないかと。
hg-gitを使えば良いのです。
> そんな中で Mercurial にとって明るい材料はないものだ
> ろうかと言うのがこのトピックを始めたきっかけですかね。
３カ月に一度メジャーリリースがあり、残りの毎月マイナーリリースがあるだけで、
十分明るいと思います。
FacebookがMercurial本体の開発に積極的に参加してますし、
hg-gitもFacebookの手がかなり加えられています。
Facebookがhg-gitを積極的に使っていることが、
このポストからもうかがえます。
https://bitbucket.org/durin42/hg-git/issue/133/repositories-can-diverge#comment-14628156
以上です。
> http://twit.tv/show/floss-weekly/320 <http://twit.tv/show/floss-weekly/320>
>
>
On 2015-01-16 08:47 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
> おまけとして、Embarcadero RAD Studio という製品の Mercurial 対応はここ何年か取り組んでいる
> のですが、最初は Subversion だけ対応していたものが最新バージョンでは Git 標準対応になって
> しまいました。Git と Mercurial では単体のバージョン管理機能で比較すれば遜色はないと信じて
> いますが、周辺ツールの充実度では完全に負けているのではないかと感じているところです。
>
> もはや利用者の好みで選べる段階はとうに終わっていて、好き嫌いに関わらず Git を選ばざるを得
> ない環境ができつつあるのではないかと。
> そんな中で Mercurial にとって明るい材料はないものだ
> ろうかと言うのがこのトピックを始めたきっかけですかね。
３カ月に一度メジャーリリースがあり、残りの毎月マイナーリリースがあるだけで、
十分明るいと思います。
FacebookがMercurial本体の開発に積極的に参加してますし、
hg-gitもFacebookの手がかなり加えられています。
Facebookがhg-gitを積極的に使っていることが、
このポストからもうかがえます。
https://bitbucket.org/durin42/hg-git/issue/133/repositories-can-diverge#comment-14628156
以上です。
>
>
INADA Naoki
Jan 17, 2015, 9:46:07 AM1/17/15
to mercur...@googlegroups.com
横から失礼します
git を覚えた人が敢えて hg-git を使うメリットは何でしょうか？
Python の開発も、コミュニティの力を借りるには github で開発した方がいいということで、
本体ではなく周辺リポジトリが github に移行していたりします。
Go のリポジトリも Mercurial から Git に移行しました。これも Git というより Github のちからだと思います。
弊社も Github enterprise を利用しています。
私も git の (コミットにブランチ名が残らない) ブランチの運用に慣れて refactoring みたいな生存期間の
短いブランチをプルリクエスト用に頻繁に作っては消してを繰り返しているので、 Mercurial に戻ると
どうブランチを運用したらいいのか再学習しないといけない感じになり、面倒であまり Mercurial を
使う気になりません。
--
from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
---
このメールは Google グループのグループ「mercurial-ja」の登録者に送られています。
このグループから退会し、グループからのメールの配信を停止するには mercurial-ja+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。
Kaz Nishimura
Jan 17, 2015, 10:36:19 AM1/17/15
to mercur...@googlegroups.com
まあ自分一人が使う分には hg-git でも構わないのですが、これからバージョン管理を学ぶ人に対してそこまでして Mercurial を薦められるかと言うと疑問符が付くのですよね。そこまでするぐらいなら、Git を直接覚える方が早いだろうと。
むしろ今必要なのは逆のツール、Mercurial のリポジトリを Git のリポジトリに見せるようなゲートウェイのようなものではないのでしょうかね。Mercurial でリポジトリを作ってもデメリットは何もないよと言えるようなもの、そして Mercurial で直接使えばより便利だよとアピールできる何かがないと、一部の物好きが使うツールと言うポジションに収まってしまうような気がします。
むしろ今必要なのは逆のツール、Mercurial のリポジトリを Git のリポジトリに見せるようなゲートウェイのようなものではないのでしょうかね。Mercurial でリポジトリを作ってもデメリットは何もないよと言えるようなもの、そして Mercurial で直接使えばより便利だよとアピールできる何かがないと、一部の物好きが使うツールと言うポジションに収まってしまうような気がします。
Toshi MARUYAMA
Jan 17, 2015, 10:53:28 AM1/17/15
to mercur...@googlegroups.com
まるやまです。
こちらの方が返答がしやすいので先に。
On 2015-01-18 00:36 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
> まあ自分一人が使う分には hg-git でも構わないのですが、これからバージョン管理を学ぶ人に対し
> てそこまでして Mercurial を薦められるかと言うと疑問符が付くのですよね。そこまでするぐらい
cronでhg-gitを用いて「同期」することだと。
先ほどのこのリンク
https://bitbucket.org/durin42/hg-git/issue/133/repositories-can-diverge#comment-14628156
以外にもhg-gitのどこかで見た記憶があります。
hg-gitのリソースが、ML/githubのチケット/bitbucketのチケットと分散しているので
どこにあったか覚えてないですが。
> Mercurial でリポジトリを作ってもデメリットは何もないよと言えるようなもの、
> そして Mercurial で直接使えばより便利だよとアピールできる何か
個人的にはMQとgraftですね。
あと、ファイルの改名の扱いですね。
Facebookによって、最近、hg-gitのファイルの改名対応がなされました。
ブランチについては別途。
以上です。
> がないと、一部の物好きが使うツールと言うポジションに収まってしまうような気がします。
>
> On Saturday, January 17, 2015 at 7:34:19 PM UTC+9, Toshi MARUYAMA wrote:
>
> まるやまです。
>
> <http://twit.tv/show/floss-weekly/320 <http://twit.tv/show/floss-weekly/320>>
> >
> >
>
こちらの方が返答がしやすいので先に。
On 2015-01-18 00:36 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
> まあ自分一人が使う分には hg-git でも構わないのですが、これからバージョン管理を学ぶ人に対し
> てそこまでして Mercurial を薦められるかと言うと疑問符が付くのですよね。そこまでするぐらい
> なら、Git を直接覚える方が早いだろうと。
>
> むしろ今必要なのは逆のツール、Mercurial のリポジトリを Git のリポジトリに見せるようなゲー
> トウェイのようなものではないのでしょうかね。
Facebookが社内で行っていることがまさしくこれだと思ってます。
>
> むしろ今必要なのは逆のツール、Mercurial のリポジトリを Git のリポジトリに見せるようなゲー
> トウェイのようなものではないのでしょうかね。
cronでhg-gitを用いて「同期」することだと。
先ほどのこのリンク
https://bitbucket.org/durin42/hg-git/issue/133/repositories-can-diverge#comment-14628156
以外にもhg-gitのどこかで見た記憶があります。
hg-gitのリソースが、ML/githubのチケット/bitbucketのチケットと分散しているので
どこにあったか覚えてないですが。
> Mercurial でリポジトリを作ってもデメリットは何もないよと言えるようなもの、
> そして Mercurial で直接使えばより便利だよとアピールできる何か
個人的にはMQとgraftですね。
あと、ファイルの改名の扱いですね。
Facebookによって、最近、hg-gitのファイルの改名対応がなされました。
ブランチについては別途。
以上です。
> がないと、一部の物好きが使うツールと言うポジションに収まってしまうような気がします。
>
> On Saturday, January 17, 2015 at 7:34:19 PM UTC+9, Toshi MARUYAMA wrote:
>
> まるやまです。
>
> >
> >
>
Toshi MARUYAMA
Jan 17, 2015, 11:35:10 AM1/17/15
to mercur...@googlegroups.com
まるやまです。
On 2015-01-17 23:46 +0900, INADA Naoki <songof...@gmail.com> wrote:
> 横から失礼します
>
> git を覚えた人が敢えて hg-git を使うメリットは何でしょうか？
gitが「マスターリポジトリ」という状況において、
Mercurail使いが対応する１つの方法論としてhg-gitを上げました。
それ以外については先ほどのメールに書きました。
> Python の開発も、コミュニティの力を借りるには github で開発した方がいいということで、
> 本体ではなく周辺リポジトリが github に移行していたりします。
>
> Go のリポジトリも Mercurial から Git に移行しました。これも Git というより Github のちから
> だと思います。
>
> 弊社も Github enterprise を利用しています。
オープンソース界でのGitHubの影響力については認めます。
Github enterpriseがオンプレミスであることも聞いています。
しかし、オープンソースにおいても、GitHubに流れている現状を危惧しています。
ベンダロックインの危険性は無いでしょうか？
突然の仕様変更なども考えられます。
これについてはBitbucketがwikiの書式を変えたという前例もあります。
> 私も git の (コミットにブランチ名が残らない) ブランチの運用に慣れて
これはMecurialではbookmarkになります。
> refactoring みたいな生存期間の
> 短いブランチをプルリクエスト用に頻繁に作っては消してを繰り返しているので、
これは、現在鋭意開発されているEvolveだと思ってます。
http://mercurial.selenic.com/wiki/EvolveExtension
Evolveを使わない方法として、Mozillaが行っているような
トポロジカルヘッドだらけという方法もあると思います。
http://selenic.com/pipermail/mercurial-devel/2015-January/065551.html
> Mercurial に戻ると
> どうブランチを運用したらいいのか再学習しないといけない感じになり、
> 面倒であまり Mercurial を使う気になりません。
Mercurialの名前付きブランチを使わないブックマーク運用であれば、
Gitと大差ありません。
以上です。
> です。
> >
> > もはや利用者の好みで選べる段階はとうに終わっていて、__好き嫌いに関わらず Git を選ば
> ざるを得
> 十分明るいと思います。
>
> FacebookがMercurial本体の開発に積極的に参加__してますし、
> hg-gitもFacebookの手がかなり加えられています。
> Facebookがhg-gitを積極的に使っていることが、
> このポストからもうかがえます。
>
> https://bitbucket.org/durin42/__hg-git/issue/133/repositories-__can-diverge#comment-14628156
> > かと言うのが最近危惧している点ですね。
> >
> > そんな中で Mercurial をもっと利用しやすくする動きがないのかと思ったのが事の発端
> で__すね。
> >
> > こちらに関しては、”「もっとがんばりましょう」ですかね”→「__そうで
> > すね」で終わらすのもアレなので、__普段思っていることなどを書いてみよ
> > うと思います。
> >
> > 長い割りに、特に結論もなにもありませんが（笑）
> >
> >
> > ネット上での声の大きさこそ少ないものの、__守秘義務契約を締結しての受
> > 託開発や、__自社の競争力の源泉となるようなクローズドなソフトの開発は
> >
> > 私自身の経験でも、発注元によるセキュリティ監査で、__外部サービスにデー
> > 全」とみなすか否かは、個々の事情によりますが……
> >
> >
> > しかし、そういったクローズドな開発であっても、__リポジトリ管理やバグ
> > 管理のために、何らかのシステムを導入する必要が出てきます。__例えば、
> <http://mercurial.selenic.com/wiki/MercurialHosting#Intranet_hosting>
> > <http://mercurial.selenic.com/__wiki/MercurialHosting#__Intranet_hosting
> > を意味しているのかなぁ、などと推測してます。
> >
> > 個人的には、こういった、いわゆるオンプレミス用途向けの、__リポジトリ
> > 管理ツールやバグ管理ツール(の連携機能)__に期待するところが大きいです。
> > まっていますから（笑）、「__面倒臭さを補って余りある利便性の高さ」
> > and/or「物凄く簡単な導入・保守手順」__が求められるでしょう。
> <http://en.wikipedia.org/wiki/Fossil_%28software%29>
> > <http://en.wikipedia.org/wiki/__Fossil_%28software%29
> <http://twit.tv/show/floss-__weekly/320 <http://twit.tv/show/floss-weekly/320>>
> >
> >
>
On 2015-01-17 23:46 +0900, INADA Naoki <songof...@gmail.com> wrote:
> 横から失礼します
>
> git を覚えた人が敢えて hg-git を使うメリットは何でしょうか？
Mercurail使いが対応する１つの方法論としてhg-gitを上げました。
それ以外については先ほどのメールに書きました。
> Python の開発も、コミュニティの力を借りるには github で開発した方がいいということで、
> 本体ではなく周辺リポジトリが github に移行していたりします。
>
> Go のリポジトリも Mercurial から Git に移行しました。これも Git というより Github のちから
> だと思います。
>
> 弊社も Github enterprise を利用しています。
Github enterpriseがオンプレミスであることも聞いています。
しかし、オープンソースにおいても、GitHubに流れている現状を危惧しています。
ベンダロックインの危険性は無いでしょうか？
突然の仕様変更なども考えられます。
これについてはBitbucketがwikiの書式を変えたという前例もあります。
> 私も git の (コミットにブランチ名が残らない) ブランチの運用に慣れて
> refactoring みたいな生存期間の
> 短いブランチをプルリクエスト用に頻繁に作っては消してを繰り返しているので、
これは、現在鋭意開発されているEvolveだと思ってます。
http://mercurial.selenic.com/wiki/EvolveExtension
Evolveを使わない方法として、Mozillaが行っているような
トポロジカルヘッドだらけという方法もあると思います。
http://selenic.com/pipermail/mercurial-devel/2015-January/065551.html
> Mercurial に戻ると
> どうブランチを運用したらいいのか再学習しないといけない感じになり、
> 面倒であまり Mercurial を使う気になりません。
Gitと大差ありません。
以上です。
> <mailto:marut...@yahoo.co.jp>> wrote:
>
> まるやまです。
>
> On 2015-01-16 08:47 +0900, Kaz Nishimura <kaz...@vx68k.org
>
> まるやまです。
>
> On 2015-01-16 08:47 +0900, Kaz Nishimura <kaz...@vx68k.org
> <mailto:kaz...@vx68k.org>> wrote:
> > おまけとして、Embarcadero RAD Studio という製品の Mercurial 対応はここ何年か取り組
> んでいる
> > おまけとして、Embarcadero RAD Studio という製品の Mercurial 対応はここ何年か取り組
> んでいる
> > のですが、最初は Subversion だけ対応していたものが最新バージョンでは Git 標準対応に
> なって
> > しまいました。Git と Mercurial では単体のバージョン管理機能で比較すれば遜色はないと
> 信じて
> > いますが、__周辺ツールの充実度では完全に負けているのではないかと感じてい__るところ
> なって
> > しまいました。Git と Mercurial では単体のバージョン管理機能で比較すれば遜色はないと
> 信じて
> です。
> >
> > もはや利用者の好みで選べる段階はとうに終わっていて、__好き嫌いに関わらず Git を選ば
> ざるを得
> > ない環境ができつつあるのではないかと。
>
> hg-gitを使えば良いのです。
>
> > そんな中で Mercurial にとって明るい材料はないものだ
> > ろうかと言うのがこのトピックを始めたきっかけですかね。
>
> ３カ月に一度メジャーリリースがあり、__残りの毎月マイナーリリースがあるだけで、
>
> hg-gitを使えば良いのです。
>
> > そんな中で Mercurial にとって明るい材料はないものだ
> > ろうかと言うのがこのトピックを始めたきっかけですかね。
>
> 十分明るいと思います。
>
> FacebookがMercurial本体の開発に積極的に参加__してますし、
> hg-gitもFacebookの手がかなり加えられています。
> Facebookがhg-gitを積極的に使っていることが、
> このポストからもうかがえます。
>
> https://bitbucket.org/durin42/__hg-git/issue/133/repositories-__can-diverge#comment-14628156
> <https://bitbucket.org/durin42/hg-git/issue/133/repositories-can-diverge#comment-14628156>
>
> 以上です。
>
> > On Friday, January 16, 2015 at 7:37:34 AM UTC+9, Kaz Nishimura wrote:
> >
> > オンプレミスの話で言うと、Bitbucket を運営している Atlassian が出している Stash
> は Git
>
> 以上です。
>
> > On Friday, January 16, 2015 at 7:37:34 AM UTC+9, Kaz Nishimura wrote:
> >
> > オンプレミスの話で言うと、Bitbucket を運営している Atlassian が出している Stash
> は Git
> > 専用ですし、ちょっとだけ書いた Gerrit はオンプレミスで利用することも可能なよう
> なので、
> > ソースコードを内部に留める場合でも Git の方が既に便利になっているのではないかと
> は感じ
> > ています。Mercurial を選ぶことがプロジェクトにとって既にリスクになりつつあるの
> で__はない
> なので、
> > ソースコードを内部に留める場合でも Git の方が既に便利になっているのではないかと
> は感じ
> > ています。Mercurial を選ぶことがプロジェクトにとって既にリスクになりつつあるの
> > かと言うのが最近危惧している点ですね。
> >
> > そんな中で Mercurial をもっと利用しやすくする動きがないのかと思ったのが事の発端
> で__すね。
> >
> > On Friday, January 16, 2015 at 12:55:56 AM UTC+9, FUJIWARA Katsunori wrote:
> >
> > 藤原です。
> >
> > 2015年1月11日 17:44 Kaz Nishimura <kaz...@vx68k.org <mailto:kaz...@vx68k.org>>:
> > On Friday, January 16, 2015 at 12:55:56 AM UTC+9, FUJIWARA Katsunori wrote:
> >
> > 藤原です。
> >
> >
> > > Microsoft Azure の Web サーバーだと Mercurial からの自動配置に対
> > > 応しているようなんですけど、利用してる人はいるんでしょうかね (い
> > > ないのが前提のなかとセルフつっこみ)。AWS には単なる Web サーバー
> > > のサービスがないようですし、Google App Engine は今のところ Git
> > > のみ対応と言った感じですので Mercurial に対応していると言う点で
> > > は便利なサービスかと思うのですがね。
> >
> > PaaS 系のサービス事情には詳しくないので、こちらに関しては言及でき
> > ませんが：
> >
> >
> > 2015年1月7日 9:02 Kaz Nishimura <kaz...@vx68k.org <mailto:kaz...@vx68k.org>>:
> > > Microsoft Azure の Web サーバーだと Mercurial からの自動配置に対
> > > 応しているようなんですけど、利用してる人はいるんでしょうかね (い
> > > ないのが前提のなかとセルフつっこみ)。AWS には単なる Web サーバー
> > > のサービスがないようですし、Google App Engine は今のところ Git
> > > のみ対応と言った感じですので Mercurial に対応していると言う点で
> > > は便利なサービスかと思うのですがね。
> >
> > PaaS 系のサービス事情には詳しくないので、こちらに関しては言及でき
> > ませんが：
> >
> >
> >
> > > 最近、某プロジェクトで Git の利用を余儀なくされていますが、
> > > GitHub を初めとして Gerrit 等 Git 周辺のエコシステムは既に回り始
> > > めているなあと感じざるを得ません。
> > >
> > > Mercurial は、私的には「もっとがんばりましょう」ですかね。named
> > > branch とか個人的には Git より好きなのですが、世の中 Git に対応
> > > したサービスやソフトが増える一方なので、__ちょっとくやしいです。
> > > 最近、某プロジェクトで Git の利用を余儀なくされていますが、
> > > GitHub を初めとして Gerrit 等 Git 周辺のエコシステムは既に回り始
> > > めているなあと感じざるを得ません。
> > >
> > > Mercurial は、私的には「もっとがんばりましょう」ですかね。named
> > > branch とか個人的には Git より好きなのですが、世の中 Git に対応
> >
> > こちらに関しては、”「もっとがんばりましょう」ですかね”→「__そうで
> > すね」で終わらすのもアレなので、__普段思っていることなどを書いてみよ
> > うと思います。
> >
> > 長い割りに、特に結論もなにもありませんが（笑）
> >
> >
> > ネット上での声の大きさこそ少ないものの、__守秘義務契約を締結しての受
> > 託開発や、__自社の競争力の源泉となるようなクローズドなソフトの開発は
> > 少なくありません。
> >
> > このような開発では、GitHub や Bitbucket のような海外サービス (国内
> > 司法の手が及ばない) は勿論、国内のサービス提供者であっても、軽々に
> > は外部組織にソースコードを預けるわけには行かないケースが多い__筈です。
> >
> > このような開発では、GitHub や Bitbucket のような海外サービス (国内
> > 司法の手が及ばない) は勿論、国内のサービス提供者であっても、軽々に
> >
> > 私自身の経験でも、発注元によるセキュリティ監査で、__外部サービスにデー
> > タを預けてないことを確認されたりしたことがあります。
> >
> > まぁ、「"プライベート" リポジトリにおけるアクセス制限」の安全性と、
> > 開発対象の漏洩リスク、__漏洩防止のコストのバランスを考えた上で、「安
> >
> > まぁ、「"プライベート" リポジトリにおけるアクセス制限」の安全性と、
> > 全」とみなすか否かは、個々の事情によりますが……
> >
> >
> > しかし、そういったクローズドな開発であっても、__リポジトリ管理やバグ
> > 管理のために、何らかのシステムを導入する必要が出てきます。__例えば、
> > Mercurial のリポジトリ管理なら HgLab, Rhodecode, Kallithea,
> > SCM-Manager、バグ管理なら Bugzilla, Trac, Redmine 等々。少なくとも
> > 「Excel でバグ管理」はやりたくない筈（笑）。
> >
> > http://mercurial.selenic.com/__wiki/MercurialHosting#__Intranet_hosting
> > SCM-Manager、バグ管理なら Bugzilla, Trac, Redmine 等々。少なくとも
> > 「Excel でバグ管理」はやりたくない筈（笑）。
> >
> <http://mercurial.selenic.com/wiki/MercurialHosting#Intranet_hosting>
> > <http://mercurial.selenic.com/__wiki/MercurialHosting#__Intranet_hosting
> <http://mercurial.selenic.com/wiki/MercurialHosting#Intranet_hosting>>
> >
> > Rhodecode がライセンス変更によって有償化の敷居を下げたのは、この手
> > のクローズドな開発のニーズが、__マネタイズ可能な程度には存在すること
> >
> > Rhodecode がライセンス変更によって有償化の敷居を下げたのは、この手
> > を意味しているのかなぁ、などと推測してます。
> >
> > 個人的には、こういった、いわゆるオンプレミス用途向けの、__リポジトリ
> > 管理ツールやバグ管理ツール(の連携機能)__に期待するところが大きいです。
> > 「便利なのは Git じゃなくて GitHub」と言う人もいるぐらいですし（笑）
> >
> > Rhodecode に関しては、有償化がちゃんとビジネスとして成立して欲しい
> > 一方で、利用する側としては、__規模制限によって導入の心理的敷居が上がっ
> >
> > Rhodecode に関しては、有償化がちゃんとビジネスとして成立して欲しい
> > てしまうのが悩ましいところです。また、fork した Kallithea と、上手
> > いこと棲み分けできるとよいのですが……。
> >
> >
> > それから、この手の開発インフラの導入・保守は「面倒臭い」__と相場が決
> > いこと棲み分けできるとよいのですが……。
> >
> >
> > まっていますから（笑）、「__面倒臭さを補って余りある利便性の高さ」
> > and/or「物凄く簡単な導入・保守手順」__が求められるでしょう。
> >
> > 以前、Nishimura さんが QNAP 上で Mercurial を使えるようにする話を
> > されていましたが、もうちょっと欲張って:
> >
> > NAS BOX の購入
> > → LAN に接続
> > → 電源 ON
> > (→ USB メモリ等経由で追加インストール or ブートイメージ上書き)
> > → Kallithea + Redmine が即利用可能
> >
> > みたいなことができると良いですよねぇ。更に「USB HDD 接続 →自動バッ
> > クアップ」とかできたら最高です(笑)。
> >
> >
> > Fossil が履歴管理機能の他に、バグ管理／Wiki 機能を統合してるのは、
> > いいところを付いてくるなぁ、と思います。
> >
> > http://en.wikipedia.org/wiki/__Fossil_%28software%29
> > 以前、Nishimura さんが QNAP 上で Mercurial を使えるようにする話を
> > されていましたが、もうちょっと欲張って:
> >
> > NAS BOX の購入
> > → LAN に接続
> > → 電源 ON
> > (→ USB メモリ等経由で追加インストール or ブートイメージ上書き)
> > → Kallithea + Redmine が即利用可能
> >
> > みたいなことができると良いですよねぇ。更に「USB HDD 接続 →自動バッ
> > クアップ」とかできたら最高です(笑)。
> >
> >
> > Fossil が履歴管理機能の他に、バグ管理／Wiki 機能を統合してるのは、
> > いいところを付いてくるなぁ、と思います。
> >
> <http://en.wikipedia.org/wiki/Fossil_%28software%29>
> > <http://en.wikipedia.org/wiki/__Fossil_%28software%29
> <http://en.wikipedia.org/wiki/Fossil_%28software%29>>
> >
> > ちなみに、つい先日、FLOSS Weekly のゲストとして、Fossil の開発者が
> > 出演してました (私自身はまだ視聴してませんが…)。
> >
> > http://twit.tv/show/floss-__weekly/320 <http://twit.tv/show/floss-weekly/320>
> >
> > ちなみに、つい先日、FLOSS Weekly のゲストとして、Fossil の開発者が
> > 出演してました (私自身はまだ視聴してませんが…)。
> >
> <http://twit.tv/show/floss-__weekly/320 <http://twit.tv/show/floss-weekly/320>>
> >
> >
>
Kaz Nishimura
Jan 17, 2015, 6:09:35 PM1/17/15
to mercur...@googlegroups.com
Kiln と言うのが両方の利用者に対応していたと記憶していますが、オープンソースではないですし、実態としては二つのリポジトリを内部で同期させているだけだったように思います。普通のユーザーはそこまで手間をかけることはしないのではないでしょうか。
最初にエコシステムと書いたように、DVCS としての機能の差については大して気にはしていません。ただ、DVCS に連携する外部ツールを作ろうと言う人がまず Git もしくは GitHub を前提にしてしまうようになってきている風潮は気になっています。ここで Mercurial が選択肢から外されてしまうのは、現状のユーザー数の差からすれば当然なのかもしれませんが、こうしたところで今後ますます差が付いてしまうと言うのは好ましくありません。Mercurial と連携する外部ツールがもっと増えてくれれば良いのですが。
最初にエコシステムと書いたように、DVCS としての機能の差については大して気にはしていません。ただ、DVCS に連携する外部ツールを作ろうと言う人がまず Git もしくは GitHub を前提にしてしまうようになってきている風潮は気になっています。ここで Mercurial が選択肢から外されてしまうのは、現状のユーザー数の差からすれば当然なのかもしれませんが、こうしたところで今後ますます差が付いてしまうと言うのは好ましくありません。Mercurial と連携する外部ツールがもっと増えてくれれば良いのですが。
Kaz Nishimura
Jan 17, 2015, 6:46:48 PM1/17/15
to mercur...@googlegroups.com
ここにオープンソース プロジェクトで利用されている VCS の比率が示されていますが、Subversion が多いのはたぶんその時期にプロジェクトを開始して移行していないか、既に放棄されたものが多いのだろうかとは思いますが、Git が多いのは GitHub の影響が大きいのではないでしょうかね。Mercurial に関しては CVS にすらまだ及ばないと言うのが非常に残念です。
Kaz Nishimura
Jan 17, 2015, 7:21:02 PM1/17/15
to mercur...@googlegroups.com
連投で申し訳ないですが、Mercurial にとっての GitHub になると期待されていた Bitbucket も今や Git を前面に出しているほどですから、もう期待できそうになさそうですし、オープンソース プロジェクトですらこの状況ですから、事業で使うとなれば当然 Git ではなく Mercurial を使う理由の説明が求められるはずですね。Visual Studio は確か Git 対応しましたよね。RAD Studio も対応しました。他の IDE でも既に Git 対応済みか対応を進めているでしょう。そんな状況で Mercurial でリポジトリを作ってバージョン管理をするという実務上の選択が簡単に実現できるでしょうか。まず無理だろうなと私は思います。
せいぜいが、個人的に hg-git を使うなどして手元 Mercurial にするのができるかどうかと言ったところではないのでしょうか。
せいぜいが、個人的に hg-git を使うなどして手元 Mercurial にするのができるかどうかと言ったところではないのでしょうか。
Kaz Nishimura
Jan 17, 2015, 8:37:33 PM1/17/15
to mercur...@googlegroups.com
もうあきれていると思いますが更に連投失礼。今現在、バグの修正 (や機能追加) に複数のユーザーで懸賞金を付けて、修正した人にそれを支払うシステムの Bountysource というサイトが既にあるのですが、ここの GitHub 連携はほとんど統合と言っても過言ではないほどで、一応 (Mercurial の使える) Bitbucket (やその他の BTS) にも対応をうたってはいるものの、バグが多くてなかなか使い物にならない有様だったりします。
他のオープンソース系のコミュニティ サイトなどでも GitHub の ID を記入する欄が作ってあったりして、GitHub のユーザーでないと相手にされないんじゃないだろうかとさえ思ったりもするほどです。現に私も GitHub のアカウントは作ってはありますが、メインが Mercurial なので他人のリポジトリをフォークして修正を加えるぐらいで、本当は (GitHub を) 使いたくもないぐらいなのですけど、GitHub の外にフォークするとプル リクエストが出せないため、やむを得ず使わされいる感じです。サイト横断的にプル リクエストが可能になると良いのですけどね。
まあそれに比べると、自分のプロジェクトを Mercurial で置いている Bitbucket は、滅多にフォークもされませんし、プル リクエストも全然来ませんねえ。Git で使っている人はそうでもないのでしょうか?
とそんな感じの愚痴混じりの話でした。
他のオープンソース系のコミュニティ サイトなどでも GitHub の ID を記入する欄が作ってあったりして、GitHub のユーザーでないと相手にされないんじゃないだろうかとさえ思ったりもするほどです。現に私も GitHub のアカウントは作ってはありますが、メインが Mercurial なので他人のリポジトリをフォークして修正を加えるぐらいで、本当は (GitHub を) 使いたくもないぐらいなのですけど、GitHub の外にフォークするとプル リクエストが出せないため、やむを得ず使わされいる感じです。サイト横断的にプル リクエストが可能になると良いのですけどね。
まあそれに比べると、自分のプロジェクトを Mercurial で置いている Bitbucket は、滅多にフォークもされませんし、プル リクエストも全然来ませんねえ。Git で使っている人はそうでもないのでしょうか?
とそんな感じの愚痴混じりの話でした。
Kaz Nishimura
Feb 6, 2015, 2:56:23 AM2/6/15
to mercur...@googlegroups.com
最近は Visual Studio Online というサービスでも Git リポジトリをサポートしているのですね。
http://www.visualstudio.com/en-us/get-started/share-your-code-in-git-vs.aspx
もしかしたら、バージョン管理ツールは Git しか知らない人が日に日に増殖しているのかもしれません。Mercurial があることも知ってほしいのですが、現在の周辺環境からすると、仮に知ってもらえたとしても使ってもらえるところまでは道が遠そうです。
余談ですが、Git に MQ に相当するものがないのはなぜだろうと考えて、Git では一時ブランチ作成と削除のコストが著しく低いことに最近気が付きました。ブランチの変更をすべて採用するならリベースで持って行けば良いし、部分的に採用するにはチェリーピックという手段もあって、不要になったブランチは削除すればなかったことにできるので、MQ のような仕組みがなくても特に困らないのでしょうねえ。
http://www.visualstudio.com/en-us/get-started/share-your-code-in-git-vs.aspx
もしかしたら、バージョン管理ツールは Git しか知らない人が日に日に増殖しているのかもしれません。Mercurial があることも知ってほしいのですが、現在の周辺環境からすると、仮に知ってもらえたとしても使ってもらえるところまでは道が遠そうです。
余談ですが、Git に MQ に相当するものがないのはなぜだろうと考えて、Git では一時ブランチ作成と削除のコストが著しく低いことに最近気が付きました。ブランチの変更をすべて採用するならリベースで持って行けば良いし、部分的に採用するにはチェリーピックという手段もあって、不要になったブランチは削除すればなかったことにできるので、MQ のような仕組みがなくても特に困らないのでしょうねえ。
Toshi MARUYAMA
Feb 6, 2015, 3:22:44 AM2/6/15
to mercur...@googlegroups.com
まるやまです。
On 2015-02-06 16:56 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
> 最近は Visual Studio Online というサービスでも Git リポジトリをサポートしているのですね。
> http://www.visualstudio.com/en-us/get-started/share-your-code-in-git-vs.aspx
>
> もしかしたら、バージョン管理ツールは Git しか知らない人が日に日に増殖しているのかもしれま
> せん。Mercurial があることも知ってほしいのですが、現在の周辺環境からすると、仮に知ってもら
> えたとしても使ってもらえるところまでは道が遠そうです。
>
> 余談ですが、Git に MQ に相当するものがないのはなぜだろうと考えて、
あるらしいです。
http://stackoverflow.com/questions/952651/git-equivalent-to-hg-mq
> Git では一時ブランチ作成
> と削除のコストが著しく低いことに最近気が付きました。ブランチの変更をすべて採用するならリ
> ベースで持って行けば良いし、部分的に採用するにはチェリーピックという手段もあって、
自分の知る限りリビジョン１つに対してしかできず、
Mercurialのgraftと比べて機能不足に感じます。
> 不要になったブランチは削除すればなかったことにできるので、
Gitのブランチの削除は極めて危険な操作です。
> MQ のような仕組みがなくても特に困らないのでしょうねえ。
MercurialのMQは置き換えられる計画です。
http://mercurial.selenic.com/wiki/MqDeprecationPlan
Mercurialは、Gitのような危険な操作を伴わない、
今風のコラボレーションツールを目指しているように感じます。
以上です。
On 2015-02-06 16:56 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
> 最近は Visual Studio Online というサービスでも Git リポジトリをサポートしているのですね。
> http://www.visualstudio.com/en-us/get-started/share-your-code-in-git-vs.aspx
>
> もしかしたら、バージョン管理ツールは Git しか知らない人が日に日に増殖しているのかもしれま
> せん。Mercurial があることも知ってほしいのですが、現在の周辺環境からすると、仮に知ってもら
> えたとしても使ってもらえるところまでは道が遠そうです。
>
> 余談ですが、Git に MQ に相当するものがないのはなぜだろうと考えて、
http://stackoverflow.com/questions/952651/git-equivalent-to-hg-mq
> Git では一時ブランチ作成
> と削除のコストが著しく低いことに最近気が付きました。ブランチの変更をすべて採用するならリ
> ベースで持って行けば良いし、部分的に採用するにはチェリーピックという手段もあって、
自分の知る限りリビジョン１つに対してしかできず、
Mercurialのgraftと比べて機能不足に感じます。
> 不要になったブランチは削除すればなかったことにできるので、
Gitのブランチの削除は極めて危険な操作です。
> MQ のような仕組みがなくても特に困らないのでしょうねえ。
MercurialのMQは置き換えられる計画です。
http://mercurial.selenic.com/wiki/MqDeprecationPlan
Mercurialは、Gitのような危険な操作を伴わない、
今風のコラボレーションツールを目指しているように感じます。
以上です。
Toshi MARUYAMA
Feb 6, 2015, 3:34:55 AM2/6/15
to mercur...@googlegroups.com
まるやまです。
On 2015-02-06 17:22 +0900, MARUYAMA Toshio wrote:
>> Git では一時ブランチ作成
>> と削除のコストが著しく低いことに最近気が付きました。ブランチの変更をすべて採用するならリ
>> ベースで持って行けば良いし、部分的に採用するにはチェリーピックという手段もあって、
>
> 自分の知る限りリビジョン１つに対してしかできず、
> Mercurialのgraftと比べて機能不足に感じます。
Git 1.7.2から複数リビジョンのcherry-pickが出来るようになったのですね。
https://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.7.2.txt
> * "git cherry-pick" learned to pick a range of commits
> (e.g. "cherry-pick A..B" and "cherry-pick --stdin"), so did "git
> revert"; these do not support the nicer sequencing control "rebase
> [-i]" has, though.
>
> * "git cherry-pick" and "git revert" learned --strategy option to specify
> the merge strategy to be used when performing three-way merges.
残念ながら、CentOS 6のGitのバージョンは1.7.1ですが。
以上です。
On 2015-02-06 17:22 +0900, MARUYAMA Toshio wrote:
>> Git では一時ブランチ作成
>> と削除のコストが著しく低いことに最近気が付きました。ブランチの変更をすべて採用するならリ
>> ベースで持って行けば良いし、部分的に採用するにはチェリーピックという手段もあって、
>
> 自分の知る限りリビジョン１つに対してしかできず、
> Mercurialのgraftと比べて機能不足に感じます。
https://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.7.2.txt
> * "git cherry-pick" learned to pick a range of commits
> (e.g. "cherry-pick A..B" and "cherry-pick --stdin"), so did "git
> revert"; these do not support the nicer sequencing control "rebase
> [-i]" has, though.
>
> * "git cherry-pick" and "git revert" learned --strategy option to specify
> the merge strategy to be used when performing three-way merges.
残念ながら、CentOS 6のGitのバージョンは1.7.1ですが。
以上です。
Kaz Nishimura
Feb 6, 2015, 6:46:16 PM2/6/15
to mercur...@googlegroups.com
引用文中に書き加えさせてもらいます。読みにくかったらすみません。
2015/02/06 17:22 "Toshi MARUYAMA" <marut...@yahoo.co.jp>:
>
> まるやまです。
>
>
> On 2015-02-06 16:56 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
>>
>> 最近は Visual Studio Online というサービスでも Git リポジトリをサポートしているのですね。
>> http://www.visualstudio.com/en-us/get-started/share-your-code-in-git-vs.aspx
>>
>> もしかしたら、バージョン管理ツールは Git しか知らない人が日に日に増殖しているのかもしれま
>> せん。Mercurial があることも知ってほしいのですが、現在の周辺環境からすると、仮に知ってもら
>> えたとしても使ってもらえるところまでは道が遠そうです。
>>
>> 余談ですが、Git に MQ に相当するものがないのはなぜだろうと考えて、
>
>
> あるらしいです。
> http://stackoverflow.com/questions/952651/git-equivalent-to-hg-mq
>
すみません。情報不足でした。MQ のように広く使われていないのはなぜかと言う意味で読み替えてください。
>> Git では一時ブランチ作成
>> と削除のコストが著しく低いことに最近気が付きました。ブランチの変更をすべて採用するならリ
>> ベースで持って行けば良いし、部分的に採用するにはチェリーピックという手段もあって、
>
>
> 自分の知る限りリビジョン１つに対してしかできず、
> Mercurialのgraftと比べて機能不足に感じます。
>
graft の代わりに使うことはここでは話題にしていませんよ。パッチキュー内の一部パッチだけを適用するような使い方を想定しています。
>> 不要になったブランチは削除すればなかったことにできるので、
>
>
> Gitのブランチの削除は極めて危険な操作です。
>
確かに危険ではあるのですが、マージしなかったブランチの削除には一応歯止めがかかっているようですし、既にプッシュ済みであればプルで取り戻せるはずですので、一時的な一連のパッチを扱う仕組みとしては、Git ユーザーにとっては十分なのではないでしょうか。
パッチキューと違って途中で枝分かれさせることも簡単ですしね。
>> MQ のような仕組みがなくても特に困らないのでしょうねえ。
>
>
> MercurialのMQは置き換えられる計画です。
> http://mercurial.selenic.com/wiki/MqDeprecationPlan
>
> Mercurialは、Gitのような危険な操作を伴わない、
> 今風のコラボレーションツールを目指しているように感じます。
>
いくら目指していると言ったところで、広く利用されるようにならなければマイナー ツールからの脱却はできませんよ。Git は多くの周辺ソフトやサービスの支援を勝ち取って既にメインストリームになってきていると感じています。Mercurial が Git に対して明確で分かりやすい利点を示すことができなければ、Git しか知らない人々を引き付けることはできないだろうと考えます。
実際に Git を使ってみて明らかに不便な点は見つからなかった (使える機能の組み合わせで代用可能だった) ので、Git しか知らないユーザーにとっては他のバージョン管理ツールを使おうと言う動機には繋がりにくいでしょうね。
> 以上です。
>
>
>
>
>
> --
> from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
> ※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
> --- このメールは Google グループのグループ「mercurial-ja」の登録者に送られています。
>
> このグループから退会し、グループからのメールの配信を停止するには mercurial-ja...@googlegroups.com にメールを送信してください。
> その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。
Toshi MARUYAMA
Feb 6, 2015, 10:42:01 PM2/6/15
to mercur...@googlegroups.com
まるやまです。
これ以上、このMLで続ける内容ではないような感じがしますが、
ご了承ください。
On 2015-02-07 08:46 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
> 引用文中に書き加えさせてもらいます。読みにくかったらすみません。
>
> 2015/02/06 17:22 "Toshi MARUYAMA" <marut...@yahoo.co.jp <mailto:marut...@yahoo.co.jp>>:
> >
> > まるやまです。
> >
> >
> > On 2015-02-06 16:56 +0900, Kaz Nishimura <kaz...@vx68k.org <mailto:kaz...@vx68k.org>>
>
> >> 不要になったブランチは削除すればなかったことにできるので、
> >
> >
> > Gitのブランチの削除は極めて危険な操作です。
> >
>
> 確かに危険ではあるのですが、マージしなかったブランチの削除には一応歯止めがかかっているよう
> ですし、既にプッシュ済みであればプルで取り戻せるはずですので、一時的な一連のパッチを扱う仕
> 組みとしては、Git ユーザーにとっては十分なのではないでしょうか。
これはローカルの作業領域の話ですよね？
私が常々問題視しているのは、Gitはリモートのブランチすら容易に削除できることです。
この対応が、MercurialのEvolveだと理解しています。
>
> パッチキューと違って途中で枝分かれさせることも簡単ですしね。
>
> >> MQ のような仕組みがなくても特に困らないのでしょうねえ。
> >
> >
> > MercurialのMQは置き換えられる計画です。
> > http://mercurial.selenic.com/wiki/MqDeprecationPlan
> >
> > Mercurialは、Gitのような危険な操作を伴わない、
> > 今風のコラボレーションツールを目指しているように感じます。
> >
>
> いくら目指していると言ったところで、広く利用されるようにならなければマイナー ツールからの
> 脱却はできませんよ。Git は多くの周辺ソフトやサービスの支援を勝ち取って既にメインストリーム
> になってきていると感じています。Mercurial が Git に対して明確で分かりやすい利点を示すこと
> ができなければ、Git しか知らない人々を引き付けることはできないだろうと考えます。
> 実際に Git を使ってみて明らかに不便な点は見つからなかった (使える機能の組み合わせで代用可
> 能だった) ので、Git しか知らないユーザーにとっては他のバージョン管理ツールを使おうと言う動
> 機には繋がりにくいでしょうね。
プレゼンなどは積極的にされてますが、何が足りないとお考えですか？
http://mercurial.selenic.com/wiki/Presentations
以上です。
これ以上、このMLで続ける内容ではないような感じがしますが、
ご了承ください。
On 2015-02-07 08:46 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
> 引用文中に書き加えさせてもらいます。読みにくかったらすみません。
>
> >
> > まるやまです。
> >
> >
> > On 2015-02-06 16:56 +0900, Kaz Nishimura <kaz...@vx68k.org <mailto:kaz...@vx68k.org>>
> wrote:
> >>
> >> 最近は Visual Studio Online というサービスでも Git リポジトリをサポートしているのですね。
> >> http://www.visualstudio.com/en-us/get-started/share-your-code-in-git-vs.aspx
> >>
> >> もしかしたら、バージョン管理ツールは Git しか知らない人が日に日に増殖しているのかもしれま
> >> せん。Mercurial があることも知ってほしいのですが、現在の周辺環境からすると、仮に知ってもら
> >> えたとしても使ってもらえるところまでは道が遠そうです。
> >>
> >> 余談ですが、Git に MQ に相当するものがないのはなぜだろうと考えて、
> >
> >
> > あるらしいです。
> > http://stackoverflow.com/questions/952651/git-equivalent-to-hg-mq
> >
>
> すみません。情報不足でした。MQ のように広く使われていないのはなぜかと言う意味で読み替えて
> ください。
>
> >> Git では一時ブランチ作成
> >> と削除のコストが著しく低いことに最近気が付きました。ブランチの変更をすべて採用するならリ
> >> ベースで持って行けば良いし、部分的に採用するにはチェリーピックという手段もあって、
> >
> >
> > 自分の知る限りリビジョン１つに対してしかできず、
> > Mercurialのgraftと比べて機能不足に感じます。
> >
>
> graft の代わりに使うことはここでは話題にしていませんよ。パッチキュー内の一部パッチだけを適
> 用するような使い方を想定しています。
すいませんが、何を問題視しているのか、全く理解できません。
> >>
> >> 最近は Visual Studio Online というサービスでも Git リポジトリをサポートしているのですね。
> >> http://www.visualstudio.com/en-us/get-started/share-your-code-in-git-vs.aspx
> >>
> >> もしかしたら、バージョン管理ツールは Git しか知らない人が日に日に増殖しているのかもしれま
> >> せん。Mercurial があることも知ってほしいのですが、現在の周辺環境からすると、仮に知ってもら
> >> えたとしても使ってもらえるところまでは道が遠そうです。
> >>
> >> 余談ですが、Git に MQ に相当するものがないのはなぜだろうと考えて、
> >
> >
> > あるらしいです。
> > http://stackoverflow.com/questions/952651/git-equivalent-to-hg-mq
> >
>
> すみません。情報不足でした。MQ のように広く使われていないのはなぜかと言う意味で読み替えて
> ください。
>
> >> Git では一時ブランチ作成
> >> と削除のコストが著しく低いことに最近気が付きました。ブランチの変更をすべて採用するならリ
> >> ベースで持って行けば良いし、部分的に採用するにはチェリーピックという手段もあって、
> >
> >
> > 自分の知る限りリビジョン１つに対してしかできず、
> > Mercurialのgraftと比べて機能不足に感じます。
> >
>
> graft の代わりに使うことはここでは話題にしていませんよ。パッチキュー内の一部パッチだけを適
> 用するような使い方を想定しています。
>
> >> 不要になったブランチは削除すればなかったことにできるので、
> >
> >
> > Gitのブランチの削除は極めて危険な操作です。
> >
>
> 確かに危険ではあるのですが、マージしなかったブランチの削除には一応歯止めがかかっているよう
> ですし、既にプッシュ済みであればプルで取り戻せるはずですので、一時的な一連のパッチを扱う仕
> 組みとしては、Git ユーザーにとっては十分なのではないでしょうか。
これはローカルの作業領域の話ですよね？
私が常々問題視しているのは、Gitはリモートのブランチすら容易に削除できることです。
この対応が、MercurialのEvolveだと理解しています。
>
> パッチキューと違って途中で枝分かれさせることも簡単ですしね。
>
> >> MQ のような仕組みがなくても特に困らないのでしょうねえ。
> >
> >
> > MercurialのMQは置き換えられる計画です。
> > http://mercurial.selenic.com/wiki/MqDeprecationPlan
> >
> > Mercurialは、Gitのような危険な操作を伴わない、
> > 今風のコラボレーションツールを目指しているように感じます。
> >
>
> いくら目指していると言ったところで、広く利用されるようにならなければマイナー ツールからの
> 脱却はできませんよ。Git は多くの周辺ソフトやサービスの支援を勝ち取って既にメインストリーム
> になってきていると感じています。Mercurial が Git に対して明確で分かりやすい利点を示すこと
> ができなければ、Git しか知らない人々を引き付けることはできないだろうと考えます。
> 実際に Git を使ってみて明らかに不便な点は見つからなかった (使える機能の組み合わせで代用可
> 能だった) ので、Git しか知らないユーザーにとっては他のバージョン管理ツールを使おうと言う動
> 機には繋がりにくいでしょうね。
http://mercurial.selenic.com/wiki/Presentations
以上です。
Kaz Nishimura
Feb 8, 2015, 4:19:36 AM2/8/15
to mercur...@googlegroups.com
引用文中に (不要部分削除の上) 書き加えます。ご了承ください。
2015-02-07 12:41 GMT+09:00 Toshi MARUYAMA <marut...@yahoo.co.jp>:
確かにここでする話題ではないのかもしれませんが、ほかに適当な場所がないのでご容赦ください。
まるやまです。
これ以上、このMLで続ける内容ではないような感じがしますが、
ご了承ください。
確かにここでする話題ではないのかもしれませんが、ほかに適当な場所がないのでご容赦ください。
>> Git では一時ブランチ作成
>> と削除のコストが著しく低いことに最近気が付きました。ブランチの変更をすべて採用するならリ
>> ベースで持って行けば良いし、部分的に採用するにはチェリーピックという手段もあって、
>
>
> 自分の知る限りリビジョン１つに対してしかできず、
> Mercurialのgraftと比べて機能不足に感じます。
>
graft の代わりに使うことはここでは話題にしていませんよ。パッチキュー内の一部パッチだけを適
用するような使い方を想定しています。
すいませんが、何を問題視しているのか、全く理解できません。
MQ において、パッチ キュー内の順序を入れ替えたりすることで、一部のパッチだけを適用してコミット (hg qfinish) するようなことは、チェリーピックで十分対応できるだろうと言うだけの話です。
>> 不要になったブランチは削除すればなかったことにできるので、
>
>
> Gitのブランチの削除は極めて危険な操作です。
>
確かに危険ではあるのですが、マージしなかったブランチの削除には一応歯止めがかかっているよう
ですし、既にプッシュ済みであればプルで取り戻せるはずですので、一時的な一連のパッチを扱う仕
組みとしては、Git ユーザーにとっては十分なのではないでしょうか。
これはローカルの作業領域の話ですよね？
私が常々問題視しているのは、Gitはリモートのブランチすら容易に削除できることです。
この対応が、MercurialのEvolveだと理解しています。
リモート ブランチの削除は実際に危険だと思いますが、そこまでやるユーザーはその危険性を承知の上で実行するだろうと期待していますので、私としては問題とは思っていません。
> MercurialのMQは置き換えられる計画です。
> http://mercurial.selenic.com/wiki/MqDeprecationPlan
>
> Mercurialは、Gitのような危険な操作を伴わない、
> 今風のコラボレーションツールを目指しているように感じます。
>
いくら目指していると言ったところで、広く利用されるようにならなければマイナー ツールからの
脱却はできませんよ。Git は多くの周辺ソフトやサービスの支援を勝ち取って既にメインストリーム
になってきていると感じています。Mercurial が Git に対して明確で分かりやすい利点を示すこと
ができなければ、Git しか知らない人々を引き付けることはできないだろうと考えます。
実際に Git を使ってみて明らかに不便な点は見つからなかった (使える機能の組み合わせで代用可
能だった) ので、Git しか知らないユーザーにとっては他のバージョン管理ツールを使おうと言う動
機には繋がりにくいでしょうね。
プレゼンなどは積極的にされてますが、何が足りないとお考えですか？
http://mercurial.selenic.com/wiki/Presentations
いくらプレゼンを作ろうが、ユーザーの目に触れなければユーザーの獲得にはつながりません。
現実にいくつかの IDE では標準で Git をサポートしていますが、Mercurial はサポートしていません。その IDE を使う人にとっては、Mercurial はないも同然なのです。同様に GitHub や Visual Studio Online などのバージョン管理リポジトリをホスティングするサービスでは Git はサポートしていますが、Mercurial はサポートしていません。(本来なら Mercurial における GitHub の役を果たすはずだった Bitbucket も、今では Git を前面に出していますので当てにできませんし。)
鶏と卵のどちらが先かという話になってしまいますが、このままでは Git と同様の機能を持った Mercurial と言うソフトウェアがあることすら知らずに、Git でバージョン管理を始めるユーザーが増え続けるだけです。比較した上で Git の方が良いとの判断なら納得もできますが、比較すらしてもらえないのは残念でなりません。
現状がそんな感じですので、Mercurial が Git より圧倒的に優れているというキラー機能を宣伝しない限り、バージョン管理システムとして並び立つどころか、ユーザー数に限らず (IDE や周辺ソフトウェアにより提供される) 利便性でも追いつくこともままならないのではないかと言うのが、私の最も懸念するところです。
私も微力ながら Mercurial の宣伝に力を貸しているつもりですが、現在の Git を中心として形成されつつあるエコシステムに、個人の力で対抗するには限界を感じてきています。そんな中で Mercurial にとって明るい話題はないだろうかと言うのがこのトピックを始めたきっかけでもあります。
本当に何か明るい話題はないものですかね?
Toshi MARUYAMA
Feb 8, 2015, 6:21:14 AM2/8/15
to mercur...@googlegroups.com
まるやまです。
On 2015-02-08 18:19 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
> 引用文中に (不要部分削除の上) 書き加えます。ご了承ください。
>
> 2015-02-07 12:41 GMT+09:00 Toshi MARUYAMA <marut...@yahoo.co.jp
> <mailto:marut...@yahoo.co.jp>>:
> 採用するならリ
> >> ベースで持って行けば良いし、__部分的に採用するにはチェリーピックという手段も
> あって、
> >
> >
> > 自分の知る限りリビジョン１つに対してしかできず、
> > Mercurialのgraftと比べて機能不足に感じます。
> >
>
> graft の代わりに使うことはここでは話題にしていませんよ。__パッチキュー内の一部パッ
> チだけを適
> ているよ__う
> ですし、__既にプッシュ済みであればプルで取り戻せるはずですので、__一時的な一連の
> パッチを扱う仕
> 組みとしては、Git ユーザーにとっては十分なのではないでしょうか。
>
>
> これはローカルの作業領域の話ですよね？
> 私が常々問題視しているのは、__Gitはリモートのブランチすら容易に削除できることです。
> この対応が、__MercurialのEvolveだと理解しています。
>
>
> リモート ブランチの削除は実際に危険だと思いますが、そこまでやるユーザーはその危険性を承知
> の上で実行するだろうと期待していますので、私としては問題とは思っていません。
本当にそれが危険な操作だと理解してやっていれば問題ないとは思いますが、
実際はどうなのでしょうか？
"git push -f"の危険性など。
Gitもその辺を認識していて、安全性確保の方向に向かっているように感じます。
https://github.com/blog/1957-git-2-3-has-been-released
https://github.com/gitster/git/blob/v2.3.0/Documentation/RelNotes/2.3.0.txt
> > MercurialのMQは置き換えられる計画です。
> > http://mercurial.selenic.com/__wiki/MqDeprecationPlan
> ツールからの
> 脱却はできませんよ。Git は多くの周辺ソフトやサービスの支援を勝ち取って既にメインス
> ト__リーム
> になってきていると感じています。Mercurial が Git に対して明確で分かりやすい利点を
> 示すこと
> うと言う動
> 機には繋がりにくいでしょうね。
>
>
>
> プレゼンなどは積極的にされてますが、__何が足りないとお考えですか？
> http://mercurial.selenic.com/__wiki/Presentations
それでも不足していると思われてるのですか？
http://mercurial.selenic.com/wiki/ChangesetEvolution
以上です。
On 2015-02-08 18:19 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
> 引用文中に (不要部分削除の上) 書き加えます。ご了承ください。
>
> 2015-02-07 12:41 GMT+09:00 Toshi MARUYAMA <marut...@yahoo.co.jp
>
> まるやまです。
>
> これ以上、このMLで続ける内容ではないような感じがしますが、
> ご了承ください。
>
>
> 確かにここでする話題ではないのかもしれませんが、ほかに適当な場所がないのでご容赦ください。
>
> >> Git では一時ブランチ作成
> >> と削除のコストが著しく低いことに最近気が付きました。__ブランチの変更をすべて
> まるやまです。
>
> これ以上、このMLで続ける内容ではないような感じがしますが、
> ご了承ください。
>
>
> 確かにここでする話題ではないのかもしれませんが、ほかに適当な場所がないのでご容赦ください。
>
> >> Git では一時ブランチ作成
> 採用するならリ
> >> ベースで持って行けば良いし、__部分的に採用するにはチェリーピックという手段も
> あって、
> >
> >
> > 自分の知る限りリビジョン１つに対してしかできず、
> > Mercurialのgraftと比べて機能不足に感じます。
> >
>
> graft の代わりに使うことはここでは話題にしていませんよ。__パッチキュー内の一部パッ
> チだけを適
> 用するような使い方を想定しています。
>
>
> すいませんが、何を問題視しているのか、全く理解できません。
>
>
> MQ において、パッチ キュー内の順序を入れ替えたりすることで、一部のパッチだけを適用してコ
> ミット (hg qfinish) するようなことは、チェリーピックで十分対応できるだろうと言うだけの話です。
>
>
>
> >> 不要になったブランチは削除すればなかったことにできるので、
> >
> >
> > Gitのブランチの削除は極めて危険な操作です。
> >
>
> 確かに危険ではあるのですが、__マージしなかったブランチの削除には一応歯止めがかかっ
>
>
> すいませんが、何を問題視しているのか、全く理解できません。
>
>
> MQ において、パッチ キュー内の順序を入れ替えたりすることで、一部のパッチだけを適用してコ
> ミット (hg qfinish) するようなことは、チェリーピックで十分対応できるだろうと言うだけの話です。
>
>
>
> >> 不要になったブランチは削除すればなかったことにできるので、
> >
> >
> > Gitのブランチの削除は極めて危険な操作です。
> >
>
> ているよ__う
> ですし、__既にプッシュ済みであればプルで取り戻せるはずですので、__一時的な一連の
> パッチを扱う仕
> 組みとしては、Git ユーザーにとっては十分なのではないでしょうか。
>
>
> これはローカルの作業領域の話ですよね？
> 私が常々問題視しているのは、__Gitはリモートのブランチすら容易に削除できることです。
> この対応が、__MercurialのEvolveだと理解しています。
>
>
> リモート ブランチの削除は実際に危険だと思いますが、そこまでやるユーザーはその危険性を承知
> の上で実行するだろうと期待していますので、私としては問題とは思っていません。
本当にそれが危険な操作だと理解してやっていれば問題ないとは思いますが、
実際はどうなのでしょうか？
"git push -f"の危険性など。
Gitもその辺を認識していて、安全性確保の方向に向かっているように感じます。
https://github.com/blog/1957-git-2-3-has-been-released
https://github.com/gitster/git/blob/v2.3.0/Documentation/RelNotes/2.3.0.txt
> > MercurialのMQは置き換えられる計画です。
> > http://mercurial.selenic.com/__wiki/MqDeprecationPlan
> <http://mercurial.selenic.com/wiki/MqDeprecationPlan>
> >
> > Mercurialは、Gitのような危険な操作を伴わない、
> > 今風のコラボレーションツールを目指しているように感じます。
> >
>
> いくら目指していると言ったところで、__広く利用されるようにならなければマイナー
> >
> > Mercurialは、Gitのような危険な操作を伴わない、
> > 今風のコラボレーションツールを目指しているように感じます。
> >
>
> ツールからの
> 脱却はできませんよ。Git は多くの周辺ソフトやサービスの支援を勝ち取って既にメインス
> ト__リーム
> になってきていると感じています。Mercurial が Git に対して明確で分かりやすい利点を
> 示すこと
> ができなければ、Git しか知らない人々を引き付けることはできないだろうと考えます。
> 実際に Git を使ってみて明らかに不便な点は見つからなかった (使える機能の組み合わせ
> で代用可
> 能だった) ので、Git しか知らないユーザーにとっては他のバージョン管理ツールを使お__
> 実際に Git を使ってみて明らかに不便な点は見つからなかった (使える機能の組み合わせ
> で代用可
> うと言う動
> 機には繋がりにくいでしょうね。
>
>
>
> プレゼンなどは積極的にされてますが、__何が足りないとお考えですか？
> http://mercurial.selenic.com/__wiki/Presentations
> <http://mercurial.selenic.com/wiki/Presentations>
>
>
> いくらプレゼンを作ろうが、ユーザーの目に触れなければユーザーの獲得にはつながりません。
>
> 現実にいくつかの IDE では標準で Git をサポートしていますが、Mercurial はサポートしていませ
> ん。その IDE を使う人にとっては、Mercurial はないも同然なのです。同様に GitHub や Visual
> Studio Online などのバージョン管理リポジトリをホスティングするサービスでは Git はサポート
> していますが、Mercurial はサポートしていません。(本来なら Mercurial における GitHub の役を
> 果たすはずだった Bitbucket も、今では Git を前面に出していますので当てにできませんし。)
>
> 鶏と卵のどちらが先かという話になってしまいますが、このままでは Git と同様の機能を持った
> Mercurial と言うソフトウェアがあることすら知らずに、Git でバージョン管理を始めるユーザーが
> 増え続けるだけです。比較した上で Git の方が良いとの判断なら納得もできますが、比較すらして
> もらえないのは残念でなりません。
>
> 現状がそんな感じですので、Mercurial が Git より圧倒的に優れているというキラー機能を宣伝し
> ない限り、バージョン管理システムとして並び立つどころか、ユーザー数に限らず (IDE や周辺ソフ
> トウェアにより提供される) 利便性でも追いつくこともままならないのではないかと言うのが、私の
> 最も懸念するところです。
>
> 私も微力ながら Mercurial の宣伝に力を貸しているつもりですが、現在の Git を中心として形成さ
> れつつあるエコシステムに、個人の力で対抗するには限界を感じてきています。そんな中で
> Mercurial にとって明るい話題はないだろうかと言うのがこのトピックを始めたきっかけでもあります。
>
> 本当に何か明るい話題はないものですかね?
キラー機能としてEvolutionが開発されていると理解してますが、
>
>
> いくらプレゼンを作ろうが、ユーザーの目に触れなければユーザーの獲得にはつながりません。
>
> 現実にいくつかの IDE では標準で Git をサポートしていますが、Mercurial はサポートしていませ
> ん。その IDE を使う人にとっては、Mercurial はないも同然なのです。同様に GitHub や Visual
> Studio Online などのバージョン管理リポジトリをホスティングするサービスでは Git はサポート
> していますが、Mercurial はサポートしていません。(本来なら Mercurial における GitHub の役を
> 果たすはずだった Bitbucket も、今では Git を前面に出していますので当てにできませんし。)
>
> 鶏と卵のどちらが先かという話になってしまいますが、このままでは Git と同様の機能を持った
> Mercurial と言うソフトウェアがあることすら知らずに、Git でバージョン管理を始めるユーザーが
> 増え続けるだけです。比較した上で Git の方が良いとの判断なら納得もできますが、比較すらして
> もらえないのは残念でなりません。
>
> 現状がそんな感じですので、Mercurial が Git より圧倒的に優れているというキラー機能を宣伝し
> ない限り、バージョン管理システムとして並び立つどころか、ユーザー数に限らず (IDE や周辺ソフ
> トウェアにより提供される) 利便性でも追いつくこともままならないのではないかと言うのが、私の
> 最も懸念するところです。
>
> 私も微力ながら Mercurial の宣伝に力を貸しているつもりですが、現在の Git を中心として形成さ
> れつつあるエコシステムに、個人の力で対抗するには限界を感じてきています。そんな中で
> Mercurial にとって明るい話題はないだろうかと言うのがこのトピックを始めたきっかけでもあります。
>
> 本当に何か明るい話題はないものですかね?
それでも不足していると思われてるのですか？
http://mercurial.selenic.com/wiki/ChangesetEvolution
以上です。
Kaz Nishimura
Feb 8, 2015, 6:12:13 PM2/8/15
to mercur...@googlegroups.com
Evolution には私も期待しているのですが、いくら待っても標準でイネーブルになりませんね。標準でイネーブルされて誰でも簡単に使えるようにならないと宣伝には弱いと思います。
更に書けば、それが Git ユーザーの欲しいと思う機能なのかどうか。Git ユーザーが使いたいと思わなければ、到底キラー機能たり得ないとも思います。
Git でもプロジェクトによっては Gerrit https://code.google.com/p/gerrit/ のようなツールを使って、リモート リポジトリへの直接プッシュをできないようにして運用しているところもありますからね。Mercurial に対応しているレビュー ツールと言うと Review Board ぐらいですか?
2015/02/08 20:21 "Toshi MARUYAMA" <marut...@yahoo.co.jp>:
--
from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
--- このメールは Google グループのグループ「mercurial-ja」の登録者に送られています。
このグループから退会し、グループからのメールの配信を停止するには mercurial-ja+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。
Toshi MARUYAMA
Feb 8, 2015, 9:50:53 PM2/8/15
to mercur...@googlegroups.com
まるやまです。
On 2015-02-09 08:12 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
> Evolution には私も期待しているのですが、いくら待っても標準でイネーブルになりませんね。標準
> でイネーブルされて誰でも簡単に使えるようにならないと宣伝には弱いと思います。
情報公開はされてますし、
http://mercurial.selenic.com/wiki/3.2sprint/notes
このMLで問題提起しても何も始まらないので、使ってみてフィードバックするか、
次回のsprintに参加されてはどうですか？
http://mercurial.selenic.com/wiki/3.4sprint
> 更に書けば、それが Git ユーザーの欲しいと思う機能なのかどうか。Git ユーザーが使いたいと思
> わなければ、到底キラー機能たり得ないとも思います。
Facebook規模のプロジェクトだとGitでは問題ありのため、
FacebookがMercurialに積極的に開発参加していると理解しています。
> Git でもプロジェクトによっては Gerrit https://code.google.com/p/gerrit/ のようなツールを
> 使って、リモート リポジトリへの直接プッシュをできないようにして運用しているところもありま
> すからね。Mercurial に対応しているレビュー ツールと言うと Review Board ぐらいですか?
以上です。
On 2015-02-09 08:12 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
> Evolution には私も期待しているのですが、いくら待っても標準でイネーブルになりませんね。標準
> でイネーブルされて誰でも簡単に使えるようにならないと宣伝には弱いと思います。
情報公開はされてますし、
http://mercurial.selenic.com/wiki/3.2sprint/notes
このMLで問題提起しても何も始まらないので、使ってみてフィードバックするか、
次回のsprintに参加されてはどうですか？
http://mercurial.selenic.com/wiki/3.4sprint
> 更に書けば、それが Git ユーザーの欲しいと思う機能なのかどうか。Git ユーザーが使いたいと思
> わなければ、到底キラー機能たり得ないとも思います。
FacebookがMercurialに積極的に開発参加していると理解しています。
> Git でもプロジェクトによっては Gerrit https://code.google.com/p/gerrit/ のようなツールを
> 使って、リモート リポジトリへの直接プッシュをできないようにして運用しているところもありま
> すからね。Mercurial に対応しているレビュー ツールと言うと Review Board ぐらいですか?
Katsunori Fujiwara
Feb 9, 2015, 12:53:21 AM2/9/15
to mercurial-ja
藤原です。
2015年2月8日 20:21 Toshi MARUYAMA <marut...@yahoo.co.jp>:
私も evolve には期待するところが大きいですが、エンドユーザレベルで
は、revsets や filesets の方が利便性が見えやすい気が。
http://mercurial-users.jp/manual/hg.1.html#revsets
http://mercurial-users.jp/manual/hg.1.html#filesets
公開されている Git の man ページを見る限りでは、当該機能は現状提供
されていないように見えますが、私の見落としでは無いですよね？
以前 (2013 頃？) Google Summer of Code (GSoC) の Git における参加
者募集のアイディア例の中にも、revsets 相当機能が列挙されていたので、
機能としての必要性は感じているんだなぁ、と思った記憶があります。
まぁ、コア機能として提供されていなくても、現行のフィルタリングオプ
ションや bisect、外部シェルスクリプトとの組み合わせ等で無理矢理実
現するのが「Git 的」な気もしますが（笑）
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
2015年2月8日 20:21 Toshi MARUYAMA <marut...@yahoo.co.jp>:
は、revsets や filesets の方が利便性が見えやすい気が。
http://mercurial-users.jp/manual/hg.1.html#revsets
http://mercurial-users.jp/manual/hg.1.html#filesets
公開されている Git の man ページを見る限りでは、当該機能は現状提供
されていないように見えますが、私の見落としでは無いですよね？
以前 (2013 頃？) Google Summer of Code (GSoC) の Git における参加
者募集のアイディア例の中にも、revsets 相当機能が列挙されていたので、
機能としての必要性は感じているんだなぁ、と思った記憶があります。
まぁ、コア機能として提供されていなくても、現行のフィルタリングオプ
ションや bisect、外部シェルスクリプトとの組み合わせ等で無理矢理実
現するのが「Git 的」な気もしますが（笑）
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
Katsunori Fujiwara
Feb 9, 2015, 3:01:32 AM2/9/15
to mercurial-ja
藤原です。
2015年2月9日 11:50 Toshi MARUYAMA <marut...@yahoo.co.jp>:
> On 2015-02-09 08:12 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
>>
>> Evolution には私も期待しているのですが、いくら待っても標準でイ
>> ネーブルになりませんね。標準でイネーブルされて誰でも簡単に使え
>> るようにならないと宣伝には弱いと思います。
>
>
> 情報公開はされてますし、
> http://mercurial.selenic.com/wiki/3.2sprint/notes
> このMLで問題提起しても何も始まらないので、使ってみてフィードバックするか、
> 次回のsprintに参加されてはどうですか？
> http://mercurial.selenic.com/wiki/3.4sprint
「要望があれば、微力でも構わないので、積極的に開発に参加して欲しい」
という思いは、Mercurial に限らずどこの OSS も同じだと思います。
但し、「要望があるなら (開発に) 参加してみては？」という発言は、言
い回しや、前後の文脈、それを受け取る人次第では、発言主にそういった
意図がなくても、「開発に参加しないなら文句言うな」という意図に誤解
されてしまう危険があります。
「当事者同士は、お互いに納得している」場合でも、それ以外の購読者や、
後からアーカイブを読む人が誤解してしまう可能性があります。
ユーザ系 ML の場合、この手の誤解は厄介なので、MARUYAMA さんをはじ
め、ML に投函される皆さんは、この種の発言が「余計な誤解を生じる可
能性が高い」点に十分ご注意ください。
mercurial-ja ML は、他愛も無い機能要望から、面倒な障害に関する相談
まで、幅広く受け付けておりますので、ご意見・ご質問等はお気軽にお寄
せください。
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
2015年2月9日 11:50 Toshi MARUYAMA <marut...@yahoo.co.jp>:
> On 2015-02-09 08:12 +0900, Kaz Nishimura <kaz...@vx68k.org> wrote:
>>
>> Evolution には私も期待しているのですが、いくら待っても標準でイ
>> ネーブルになりませんね。標準でイネーブルされて誰でも簡単に使え
>> るようにならないと宣伝には弱いと思います。
>
>
> 情報公開はされてますし、
> http://mercurial.selenic.com/wiki/3.2sprint/notes
> このMLで問題提起しても何も始まらないので、使ってみてフィードバックするか、
> 次回のsprintに参加されてはどうですか？
> http://mercurial.selenic.com/wiki/3.4sprint
という思いは、Mercurial に限らずどこの OSS も同じだと思います。
但し、「要望があるなら (開発に) 参加してみては？」という発言は、言
い回しや、前後の文脈、それを受け取る人次第では、発言主にそういった
意図がなくても、「開発に参加しないなら文句言うな」という意図に誤解
されてしまう危険があります。
「当事者同士は、お互いに納得している」場合でも、それ以外の購読者や、
後からアーカイブを読む人が誤解してしまう可能性があります。
ユーザ系 ML の場合、この手の誤解は厄介なので、MARUYAMA さんをはじ
め、ML に投函される皆さんは、この種の発言が「余計な誤解を生じる可
能性が高い」点に十分ご注意ください。
mercurial-ja ML は、他愛も無い機能要望から、面倒な障害に関する相談
まで、幅広く受け付けておりますので、ご意見・ご質問等はお気軽にお寄
せください。
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
ohira
Feb 12, 2015, 8:29:44 PM2/12/15
to mercur...@googlegroups.com
おおひらです。いつもお世話になっております。
藤原さんが紹介されていた関連ツールに興味があります。
お使いの方、お試しになった方、感想などいただけませんでしょうか。
自分は、rhodecodeしか試していないのですが、
phabricatorよりは良さそうな感じでした。(インストールして多少試してみただけです)
ネット上での声の大きさこそ少ないものの、守秘義務契約を締結しての受
託開発や、自社の競争力の源泉となるようなクローズドなソフトの開発は
少なくありません。
Katsunori Fujiwara
Feb 14, 2015, 10:31:03 AM2/14/15
to mercurial-ja
藤原です。
2015年2月13日 10:29 ohira <shin....@gmail.com>:
> 藤原さんが紹介されていた関連ツールに興味があります。
> お使いの方、お試しになった方、感想などいただけませんでしょうか。
>
> https://hglabhq.com/
> https://rhodecode.com/
> https://kallithea-scm.org/
> https://www.scm-manager.org/
>
> 自分は、rhodecodeしか試していないのですが、phabricatorよりは良さ
> そうな感じでした。(インストールして多少試してみただけです)
Kallithea は rhodecode 派生ですが、飯野さんが色々パッチを送付して
いるみたいですし、UI周りの使い勝手は結構違ってきているのかな？
自身の修正点以外にも、Kallithea での特徴的な機能向上等があれば、是
非紹介して欲しいところですね > 飯野さん
phabricator は出自がそもそも facebook の社内ツールですが、
facebook の開発プロセス向けの味付けだったりするんですしょうか？あ
るいは単に機能の出来の良し悪しの差とか？(笑) > phabricatorよりは良さそう
> 2015年1月16日金曜日 0時55分56秒 UTC+9 FUJIWARA Katsunori:
>>
>> ネット上での声の大きさこそ少ないものの、守秘義務契約を締結しての受
>> 託開発や、自社の競争力の源泉となるようなクローズドなソフトの開発は
>> 少なくありません。
>>
>> しかし、そういったクローズドな開発であっても、リポジトリ管理やバグ
>> 管理のために、何らかのシステムを導入する必要が出てきます。例えば、
>> Mercurial のリポジトリ管理なら HgLab, Rhodecode, Kallithea,
>> SCM-Manager、バグ管理なら Bugzilla, Trac, Redmine 等々。少なくとも
>> 「Excel でバグ管理」はやりたくない筈（笑）。
>>
>> http://mercurial.selenic.com/wiki/MercurialHosting#Intranet_hosting
>>
>> Rhodecode がライセンス変更によって有償化の敷居を下げたのは、この手
>> のクローズドな開発のニーズが、マネタイズ可能な程度には存在すること
>> を意味しているのかなぁ、などと推測してます。
>>
>> 個人的には、こういった、いわゆるオンプレミス用途向けの、リポジトリ
>> 管理ツールやバグ管理ツール(の連携機能)に期待するところが大きいです。
>> 「便利なのは Git じゃなくて GitHub」と言う人もいるぐらいですし（笑）
>>
>> Rhodecode に関しては、有償化がちゃんとビジネスとして成立して欲しい
>> 一方で、利用する側としては、規模制限によって導入の心理的敷居が上がっ
>> てしまうのが悩ましいところです。また、fork した Kallithea と、上手
>> いこと棲み分けできるとよいのですが……。
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
2015年2月13日 10:29 ohira <shin....@gmail.com>:
> 藤原さんが紹介されていた関連ツールに興味があります。
> お使いの方、お試しになった方、感想などいただけませんでしょうか。
>
> https://hglabhq.com/
> https://rhodecode.com/
> https://kallithea-scm.org/
> https://www.scm-manager.org/
>
> 自分は、rhodecodeしか試していないのですが、phabricatorよりは良さ
> そうな感じでした。(インストールして多少試してみただけです)
いるみたいですし、UI周りの使い勝手は結構違ってきているのかな？
自身の修正点以外にも、Kallithea での特徴的な機能向上等があれば、是
非紹介して欲しいところですね > 飯野さん
phabricator は出自がそもそも facebook の社内ツールですが、
facebook の開発プロセス向けの味付けだったりするんですしょうか？あ
るいは単に機能の出来の良し悪しの差とか？(笑) > phabricatorよりは良さそう
> 2015年1月16日金曜日 0時55分56秒 UTC+9 FUJIWARA Katsunori:
>>
>> ネット上での声の大きさこそ少ないものの、守秘義務契約を締結しての受
>> 託開発や、自社の競争力の源泉となるようなクローズドなソフトの開発は
>> 少なくありません。
>>
>> しかし、そういったクローズドな開発であっても、リポジトリ管理やバグ
>> 管理のために、何らかのシステムを導入する必要が出てきます。例えば、
>> Mercurial のリポジトリ管理なら HgLab, Rhodecode, Kallithea,
>> SCM-Manager、バグ管理なら Bugzilla, Trac, Redmine 等々。少なくとも
>> 「Excel でバグ管理」はやりたくない筈（笑）。
>>
>> http://mercurial.selenic.com/wiki/MercurialHosting#Intranet_hosting
>>
>> Rhodecode がライセンス変更によって有償化の敷居を下げたのは、この手
>> のクローズドな開発のニーズが、マネタイズ可能な程度には存在すること
>> を意味しているのかなぁ、などと推測してます。
>>
>> 個人的には、こういった、いわゆるオンプレミス用途向けの、リポジトリ
>> 管理ツールやバグ管理ツール(の連携機能)に期待するところが大きいです。
>> 「便利なのは Git じゃなくて GitHub」と言う人もいるぐらいですし（笑）
>>
>> Rhodecode に関しては、有償化がちゃんとビジネスとして成立して欲しい
>> 一方で、利用する側としては、規模制限によって導入の心理的敷居が上がっ
>> てしまうのが悩ましいところです。また、fork した Kallithea と、上手
>> いこと棲み分けできるとよいのですが……。
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
Takumi IINO
Feb 19, 2015, 10:05:19 PM2/19/15
to mercur...@googlegroups.com
こんにちは、飯野(@troter)です。
# このスレッド、一部乱闘っぽくて非常に良いですね。
RhodeCode-2.2.5を仕事で使っています。(が、GitBucketに置き換わりつつ有ります、、)
KallitheaにはYUI-2.9をjQueryに置き換えるパッチを送ってる人です。
最初にRhodeCodeとKallitheaの関係を軽く説明します。次のようになっています。
(a) RhodeCode-2.2.x
pypiに登録されているやつ。
(b) RhodeCode-3.x
次のリリース。early accessに申し込むと3.0-rc1が使えるらしい。
2.2.xから3000コミット以上の変更点が入っている。らしい。
(c) Kallithea
RhodeCode-2.2.5相当からのfork。
メインの開発者はMercurialコミッターもやってるUnityの人達。
Unityの人たちは0.1ではなく開発版使ってるっぽい。
僕が触ったことがあるのは(a)と(c)です。
Kallitheaがforkしてから現在の最新版1619d9ebc1b9までの間に、大きな変更点としては
次のものが入っています。
* pull-request(PR)関連の機能追加
- 自分の関連するPRの一覧ページが追加
- PR詳細の機能追加
- PRの説明編集機能
- PRを複製して編集機能
- PRのステータスにかかわらずPRをクローズ可能に！
* Retinaディスプレイ対応
- gravatorのアイコンが綺麗になる、とか
- pngのアイコンがsvg、webフォントに、とか
* 依存ライブラリのバージョンの更新
- 最新のMercurialが利用できる
- 2.8.2 vs 3.3
- 最新のdulwitchが(ry
* 高速化
- インデックス追加
- リポジトリ操作の最適化
* その他沢山の変更、バグフィックス、リファクタリング
- hg-svn連携改善
- ミラーリポジトリでsshのリポジトリが利用可能に
- コミット詳細の表示改善
- PAM認証がデフォルトで選択可能に
- などなど
RhodeCode-2.2.xと比べるといろいろ改修されているKallitheaのほうが使い勝手は良いですが、
多分開発版を使っていくことになると思うので、その分のコストがかかると思います。
# まだ見ぬRhodeCode-3.0がすごいことになっているのを期待したいです。
# 自分で申し込めって話ですが。。
2015年2月15日日曜日 0時31分03秒 UTC+9 FUJIWARA Katsunori:
FUJIWARA Katsunori(flying.foozy@gmail.com)
Kaz Nishimura
Feb 27, 2015, 9:20:18 PM2/27/15
to mercur...@googlegroups.com
私個人としては Mercurial 押しなので、もっと Mercurial に対応したソフトウェアが増えて欲しいと思っているのですが、良くて Git と Mercurial の両対応、そうでなければ Git だけというのが普通になりつつあると感じているので、この流れを少しでも変えるために活動しようとしてはいます。(Mercurial オンリーだと関心を集められないのが困ったものですが。)
しかし、オープンソース絡みだと GitHub の存在が大きすぎて、Mercurial はあまり使ってもらえないのですよね。多くの人には存在すら認知されないというのはとても残念なことだと常々思っています。業務関係でも Visual Studio とかは Git に標準対応していますから、少なくとも中央リポジトリを Git にするというのは、多くの企業にとって既に現実的な選択肢になっているのかなとも思います。(そして Mercurial を使いたい人は hg-git を使うと。)
Mercurial の一度コミットした (少なくともパブリックにした) ものは簡単に消せないと言う仕様は、Git に対する業務管理上の利点だと思うのですがねえ。
しかし、オープンソース絡みだと GitHub の存在が大きすぎて、Mercurial はあまり使ってもらえないのですよね。多くの人には存在すら認知されないというのはとても残念なことだと常々思っています。業務関係でも Visual Studio とかは Git に標準対応していますから、少なくとも中央リポジトリを Git にするというのは、多くの企業にとって既に現実的な選択肢になっているのかなとも思います。(そして Mercurial を使いたい人は hg-git を使うと。)
Mercurial の一度コミットした (少なくともパブリックにした) ものは簡単に消せないと言う仕様は、Git に対する業務管理上の利点だと思うのですがねえ。
Reply all
Reply to author
Forward
0 new messages