アカウント名:
パスワード:
開発のソースツリーがプロジェクトごとでなく会社で1つのツリーになっていてweb/proj1 /proj2みたいになっていた場合Subversionなら下位のだけでいけるけれど,Gitはそれが出来ないのが難点それとも今はできるようになったのかな?
svnなんて単なるバックアップツールであって、gitにおける履歴とは全く別物。どちらも車という例えからして的外れ。
「きれいな履歴を残す」ことこそが重要であり、それを最大限サポートするという哲学でgitは設計されている。
例えば、コードを書いて、同じファイルにAとBという、別の観点の修正があったとき、svnは1コミットにしかできない。しかも、その段階で、適切なコミットメッセージを考えなければならない。これはプログラミングの思考を大きく阻害するし、結果、コミットメッセージも、1コミットで行われて修正の粒度も、後から履歴を見たときに役に立たなくなる。(だから単なるバックアップツール)
これを問題と思えないであれば、プログラマーとしての経験が足りないだけ。
ブランチで出来ないの・・・(震え声)
svnのブランチを使って、こうすればできる、と言ってもらえればそれに反論しますが?
1.diffを書き出す2.変更を取り消し3.diffからAに関する部分だけ抜き出して適用してコミット4.diffの残りを適用してコミットとか?gitはよく知らないのでちょっと検索してみただけなんですが、gitなら git add -p を使うと簡単ってことでしょうか?
# emacsって差分ファイルを変更するとき行を調節してくれて便利です
なるほど、そこまですればsvnでもいいと本気で言っているのでしたら反論の余地ありません。他のsvn派にぜひ、git派への反論意見として教えてあげればよろしいかと。
分散とブランチが簡単とかよりも、git add -p (とステージ)が、gitで、一番重要な機能だと思っています。bzrにもinteractiveとかあるけど、結局ステージじゃないのでmercurialは知りませんが
どちらかと言うと、今回 git add -p を知って Git いいな、と思いました。逆に、Git派の意見でよく見るのは「分散型でブランチ簡単だよ」で、「git add -p 便利」って書いてあるのを見たことが無かったので、Git派にこの機能を推すよう広めたらどうでしょうか。
git add -p なんて面倒くさいことになる前に、最初から分けて修正して分けてコミットしないとダメというか、たとえgit add -p がどれだけ便利だとしても、> コードを書いて、同じファイルにAとBという、別の観点の修正があったとき、svnは1コミットにしかできない。これは、そもそも「同じファイルにAとBと別の観点の修正」をしてしまった時点で負けてるかな、と。
で、そういう複数の修正が同一ファイルに行われた時の管理の便利さ、という点で、私はMercurial + mq [hatena.ne.jp]派。修正を「パッチ」という形で管理するので、後から適用順番の入れ替えとかが自由自在。
まあ、mq 自体は、単独のパッチ管理システム quilt をMercurial に取り込んだもので、自分はやったことないけどquiltはsvnでも使用可能 [srad.jp]みたい。mq は mercurial に標準で付いてくるのが強みですかね。同様のものはgit にもいくつかある [kernel.org]みたいです。
#こないだ、何年かぶりぐらいにコード修正することになったプロジェクトは、コード管理がCVSでした。2002年に作ったプロジェクトで前回更新が2007年…。どうしたものか思案中。
> これは、そもそも「同じファイルにAとBと別の観点の修正」をしてしまった時点で負けてるかな、と。
AとBが別の観点であったという認識は、プログラミングをしている最中には気づかない場合がある。AとBは細かい粒度では確かに別だけど、よくよく考えたら1コミットでも良かった場合、実は、その後のコミットCも含めると、Aと B+Cという2コミットの方が良かった場合、Aは実はA1+A2であり、コミット的にはA1とA2+Bの方が良かった場合、重要なのは、プログラミングという作業と、ログの整理とが分けられる事。
add -p 相当の機能がhgにもあるという意見ではなさそうですね。#長らくbzrを使わされてきたので、いまさらhgがどうなのか調べるつもりもなく
mq(quilt)の機能というかメリットは、A1、A2、B、Cいう4つのチェンジセットを作ってしまえば、あとから「A1とA2とBとC」として扱えるだけでなく、「A1+A2+Bと、C」でも「A1+A2と、B+C」でも、あるいは、コミットの順番すら入れ替えて「A2+Cと、A1+B」にすることすら、自由自在に組み替え直せるところです。
これができる前提として割とこまめにとりあえず分割してチェンジセットを作る必要があるわけですが、私自身の意見としては、そもそもAが実はA1とA2に分けられる…と言ってるレベルでは粒度が荒すぎると思ってる、ってことで。
#とはいえ、後からチェンジセットをさらに分割したくなることもたまにはあるのは確かですが、#mqが管理しているチェンジセットとは差分(パッチ)ファイルそのものですので、git add -p で edit で処理する程度のことは、差分ファイルそのものの手修正である程度は可能です。
「これができる前提として割とこまめにとりあえず分割してチェンジセットを作る」作っておかなければならない、と言っているわけですよね?gitではそれはいつでも、何度でもやり直せる、そしてその時にgit add -p が非常に便利。hgでも同様の機能があれば、上記の前提となるたチェンジセット作る作業自体を効率よくできるという話だと思います。
>「A1とA2とBとC」として扱えるだけでなく、「A1+A2+Bと、C」でも「A1+A2と、B+C」でも、>あるいは、コミットの順番すら入れ替えて「A2+Cと、A1+B」にすることすら、自由自在に組み替え直せるところです。については、ほぼgit rebase -i でできそうなきもしますが、A2+Cをsquashしちゃうと1コミットになってしまって、2つのパッチであったという情報は消えるので、そこは劣っているのかしら
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
Subversionから移行して失敗 (スコア:0)
開発のソースツリーが
プロジェクトごとでなく
会社で1つのツリーになっていて
web/proj1
/proj2
みたいになっていた場合
Subversionなら
下位のだけでいけるけれど,Gitはそれが出来ないのが難点
それとも今はできるようになったのかな?
Re: (スコア:2)
SVN と比べて、Git の何がいいんでしょうね?という。
私は自転車とトラックのように共存するものだと思いますが、サーバーをGit に移行しようぜ!と勧める Git 屋さんの気持ちがわかりません。二段階commitがイイとか、ATの車で満足している人にMTに移行しようぜとアピールするもんじゃないかなと。
Re: (スコア:0)
svnなんて単なるバックアップツールであって、gitにおける履歴とは全く別物。
どちらも車という例えからして的外れ。
「きれいな履歴を残す」ことこそが重要であり、
それを最大限サポートするという哲学でgitは設計されている。
例えば、コードを書いて、同じファイルにAとBという、別の観点の修正があったとき、
svnは1コミットにしかできない。
しかも、その段階で、適切なコミットメッセージを考えなければならない。
これはプログラミングの思考を大きく阻害するし、
結果、コミットメッセージも、1コミットで行われて修正の粒度も、
後から履歴を見たときに役に立たなくなる。(だから単なるバックアップツール)
これを問題と思えないであれば、プログラマーとしての経験が足りないだけ。
ブ・・・ (スコア:0)
ブランチで出来ないの・・・(震え声)
Re: (スコア:0)
svnのブランチを使って、こうすればできる、と言ってもらえれば
それに反論しますが?
Re:ブ・・・ (スコア:1)
1.diffを書き出す
2.変更を取り消し
3.diffからAに関する部分だけ抜き出して適用してコミット
4.diffの残りを適用してコミット
とか?
gitはよく知らないのでちょっと検索してみただけなんですが、
gitなら git add -p を使うと簡単ってことでしょうか?
# emacsって差分ファイルを変更するとき行を調節してくれて便利です
svn-init() {
svnadmin create .svnrepo
svn checkout file://$PWD/.svnrepo .
}
Re: (スコア:0)
なるほど、そこまですればsvnでもいいと本気で言っているのでしたら反論の余地ありません。
他のsvn派にぜひ、git派への反論意見として教えてあげればよろしいかと。
分散とブランチが簡単とかよりも、
git add -p (とステージ)が、gitで、一番重要な機能だと思っています。
bzrにもinteractiveとかあるけど、結局ステージじゃないので
mercurialは知りませんが
Re:ブ・・・ (スコア:1)
どちらかと言うと、今回 git add -p を知って Git いいな、と思いました。
逆に、Git派の意見でよく見るのは「分散型でブランチ簡単だよ」で、
「git add -p 便利」って書いてあるのを見たことが無かったので、
Git派にこの機能を推すよう広めたらどうでしょうか。
svn-init() {
svnadmin create .svnrepo
svn checkout file://$PWD/.svnrepo .
}
Re:ブ・・・ (スコア:1)
git add -p なんて面倒くさいことになる前に、最初から分けて修正して分けてコミットしないとダメというか、たとえgit add -p がどれだけ便利だとしても、
> コードを書いて、同じファイルにAとBという、別の観点の修正があったとき、svnは1コミット
にしかできない。
これは、そもそも「同じファイルにAとBと別の観点の修正」をしてしまった時点で負けてるかな、と。
で、そういう複数の修正が同一ファイルに行われた時の管理の便利さ、という点で、私はMercurial + mq [hatena.ne.jp]派。
修正を「パッチ」という形で管理するので、後から適用順番の入れ替えとかが自由自在。
まあ、mq 自体は、単独のパッチ管理システム quilt をMercurial に取り込んだもので、自分はやったことないけどquiltはsvnでも使用可能 [srad.jp]みたい。
mq は mercurial に標準で付いてくるのが強みですかね。同様のものはgit にもいくつかある [kernel.org]みたいです。
#こないだ、何年かぶりぐらいにコード修正することになったプロジェクトは、コード管理がCVSでした。2002年に作ったプロジェクトで前回更新が2007年…。どうしたものか思案中。
Re: (スコア:0)
> これは、そもそも「同じファイルにAとBと別の観点の修正」をしてしまった時点で負けてるかな、と。
AとBが別の観点であったという認識は、プログラミングをしている最中には気づかない場合がある。
AとBは細かい粒度では確かに別だけど、よくよく考えたら1コミットでも良かった場合、
実は、その後のコミットCも含めると、Aと B+Cという2コミットの方が良かった場合、
Aは実はA1+A2であり、コミット的にはA1とA2+Bの方が良かった場合、
重要なのは、プログラミングという作業と、ログの整理とが分けられる事。
add -p 相当の機能がhgにもあるという意見ではなさそうですね。
#長らくbzrを使わされてきたので、いまさらhgがどうなのか調べるつもりもなく
Re:ブ・・・ (スコア:1)
mq(quilt)の機能というかメリットは、
A1、A2、B、Cいう4つのチェンジセットを作ってしまえば、あとから
「A1とA2とBとC」として扱えるだけでなく、「A1+A2+Bと、C」でも「A1+A2と、B+C」でも、
あるいは、コミットの順番すら入れ替えて「A2+Cと、A1+B」にすることすら、自由自在に組み替え直せるところです。
これができる前提として割とこまめにとりあえず分割してチェンジセットを作る必要があるわけですが、
私自身の意見としては、そもそもAが実はA1とA2に分けられる…と言ってるレベルでは粒度が荒すぎると思ってる、ってことで。
#とはいえ、後からチェンジセットをさらに分割したくなることもたまにはあるのは確かですが、
#mqが管理しているチェンジセットとは差分(パッチ)ファイルそのものですので、git add -p で edit で処理する程度のことは、差分ファイルそのものの手修正である程度は可能です。
Re: (スコア:0)
「これができる前提として割とこまめにとりあえず分割してチェンジセットを作る」
作っておかなければならない、と言っているわけですよね?
gitではそれはいつでも、何度でもやり直せる、そしてその時にgit add -p が非常に便利。
hgでも同様の機能があれば、上記の前提となるたチェンジセット作る作業自体を効率よくできるという話だと思います。
>「A1とA2とBとC」として扱えるだけでなく、「A1+A2+Bと、C」でも「A1+A2と、B+C」でも、
>あるいは、コミットの順番すら入れ替えて「A2+Cと、A1+B」にすることすら、自由自在に組み替え直せるところです。
については、ほぼgit rebase -i でできそうなきもしますが、
A2+Cをsquashしちゃうと1コミットになってしまって、2つのパッチであったという情報は消えるので、そこは劣っているのかしら