アカウント名:
パスワード:
開発のソースツリーがプロジェクトごとでなく会社で1つのツリーになっていてweb/proj1 /proj2みたいになっていた場合Subversionなら下位のだけでいけるけれど,Gitはそれが出来ないのが難点それとも今はできるようになったのかな?
完全な主観ですが。
pros:- とにかくブランチが手軽に作成でき、マージも (SVN と比較すれば) 楽ちん- commit, log, diff などの基本操作がローカルで完結するため高速- GitHub などの周辺サービスが洗練されており使いやすい- GitHub が発明した Pull request ベースでの開発が、コードレビューと一体となって効率的- rebase, filter-branch など歴史の改ざんが可能(もちろん remote 側の設定次第で reject もできるから悪用は防げる)- git-flow に代表されるワークフローや、権威型など、プロジェクトの都合に合わせて運用しやすい
cons:- git clone 時に歴史を丸ごとダウンロードするため、歴史が長いリポジトリだと時間がかかる(ただし最近の git なら --depth で省くこともできる)- リポジトリが肥大化しがち(特に大きな画像等の asset 類を扱う場合)- コマンドが非直感的(git reset や git checkout 等 git の内部構造を把握していないと理解しづらいコマンドがある)
...- リポジトリが肥大化しがち(特に大きな画像等の asset 類を扱う場合)...
diff 出力表示など内容そのものの履歴管理が必要ないのであれば git-annex [branchable.com] などはいかが?
git の外部で大きいファイル管理するための類似プロジェクト色々ありますよね。
- git-annex [branchable.com]- git-fat [github.com]- git-media [github.com]- git-largefile [github.com]
ただ、やはり git だけで上手いこと取り扱ってほしいものですが、アーキテクチャ的に難しそうですね。
Facebook による [facebook.com]と、git はスケールしない (we concluded that Git's internals would be difficult to work with for an ambitious scaling project.)、という結論に至ったようですし、git 3.0.0 ではこの辺りの改善を期待したいところです。
巨大なバイナリファイルを使うプロジェクトに参加していることもあって、gitがスケールしないってを痛感しています。ソースコードなんかだと分散型バージョン管理以外あり得ないよねと言えるくらいに便利だと思ってますが、画像とかがががが
上で紹介されていた中で構成がシンプルそうなgit-fatに挑戦してみた。Windows環境で動かすのにぼちぼち手間取ったがひとまず動作。結論から言うと使えそう。というか参加しているプロジェクトで使ってみようかしらん。あ、でもgit-annexも試しておきたいな。
今使っているバージョン管理システムに何の不満もなく完全に満足している人にはそりゃどんなアピールだろうと意味ないでしょう。
分散リポジトリでもあるので、マスターが死んでも直ぐに再構築可能というところが売りだったようなそのせいで途中からチェックアウトが出来ないのかも・・・?とりあえず簡単なリポジトリの分割ができれば特に言う事もないんだけど
他の言語も同じリポジトリに入れたいならともかく、Visual Studioから使うだけならTFSでいいじゃん。Subversion的な欠点はTFSにはないし、Gitだとゲートチェックインとか一部機能が使えないから一長一短だぞ。
Vssじゃないだけまし
バージョン管理システムなんでどれも対して変わらない。新しいのいちいち覚えるのは面倒だ。そう思ってた時期が自分にもありました。
しかし、ブランチの圧倒的な軽さ、次元の違うマージの賢さコードレビューを含めての分散開発のやりやすさなど、今ではgit以外使う気になりません。
> ATの車で満足している人にMTに移行しようぜ
逆でしょ。MT使ってる人にAT薦めてるんですよ。しかもそのAT、あなたがMTで運転した時より格段に燃費良かったりする。
git svnでいいじゃん。使いたい奴だけ。
git svnでダメな理由が知りたい。つまり、共有リポジトリをgitにする理由が。
Gitのブランチでの履歴がgit svn dcommitで一つにまとまってしまってGitのメリットが生かせないから、共有リポジトリもGitにしてしまった方がいいと思う。
Git でのブランチに関する問題 [git-scm.com]
SubGitならなんとかなるみたいだけど。
しばらく使ってたけど、このあたりの問題がめんどくさく感じられるようになってそれならquiltでいいやとsvn + quiltで最近やっている。
基本的には同意。まあ、マージはマージとして残したいなぁと思う事もままある。
ただし、そもそもgitについていけない人と仕事したくないとも思う。
何のための分散型だと思っているんですか。移行したい人/できる人から順次移行していけばいいでしょうに。
ローカルで気軽にコミットして作業できる(ローカルでどんだけ間違おうがどんだけ実験しようがサーバーに影響でない)とことか、リポジトリの移動が楽とか、コンフリクトが起きたときにマージ明日でいいやと帰れるとか、SVNのタグとかブランチって機能じゃなくてローカルルールなとことか。
ロックしたいバイナリファイルなんかはSVNも使いますけど、ソース管理はSVNには戻りたくないかなー。コミットして平気かなって思わずとりあえずローカルでコミットしておけるのが大きいですかね。その後失敗しても履歴はローカルに残ってますし。基本機能しかつかってないですけど便利に感じています。(まぁ私はMercurialですけど)
vss使ってた会社にsvn入れさせて、svnから移行させるの簡単そうだからと個人的に使ってたhgから乗り換えてbzr1年ぐらい試してたんだけど、gitlabのおかげでgitに移行しました。あのブランチの軽さやgitlabで簡単にレポジトリ作れるのがすごい便利。特にアカウントの管理がすごい楽。公開鍵を一人ずつ手作業で登録してたssh+svnからだいぶ楽になりました。他の社員とか自分じゃアカウント登録できないから派遣さんに同じ秘密鍵共有とかさせてたし。
なんつーか、gitlab(github)がすごい便利。
GitLabいいですよねブラウザベースで履歴見るときたまにエンコーディングエラーで表示できない履歴がでたりするけど…
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つのパッチであったという情報は消えるので、そこは劣っているのかしら
複数人で開発したこと無いなら分からないかもね。一人で開発するならgitとsvnどっち使っても一緒。結局自分が分かれば良いわけだし、gitを使ったところでまとめて修正して「色々コミット」みたいな履歴しか残さない人には意味無いし、svnでもちゃんと運用すれば納得いくような変更管理が出来るし。
OSSに関して言えば、「みんなが使っている」につきる。# WindowsとかExcelの何がいいんですかね。バージョン管理システムがマイナーなものだとコントリビューターに参加してもらうための障壁が1つ増える。
バージョンが上がってもリポジトリの互換性がなくならないこと。この業界にいてそれが重要だと思わないんだったらマジヤバイ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
Subversionから移行して失敗 (スコア:0)
開発のソースツリーが
プロジェクトごとでなく
会社で1つのツリーになっていて
web/proj1
/proj2
みたいになっていた場合
Subversionなら
下位のだけでいけるけれど,Gitはそれが出来ないのが難点
それとも今はできるようになったのかな?
Re:Subversionから移行して失敗 (スコア:2)
SVN と比べて、Git の何がいいんでしょうね?という。
私は自転車とトラックのように共存するものだと思いますが、サーバーをGit に移行しようぜ!と勧める Git 屋さんの気持ちがわかりません。二段階commitがイイとか、ATの車で満足している人にMTに移行しようぜとアピールするもんじゃないかなと。
Re:Subversionから移行して失敗 (スコア:5, 参考になる)
完全な主観ですが。
pros:
- とにかくブランチが手軽に作成でき、マージも (SVN と比較すれば) 楽ちん
- commit, log, diff などの基本操作がローカルで完結するため高速
- GitHub などの周辺サービスが洗練されており使いやすい
- GitHub が発明した Pull request ベースでの開発が、コードレビューと一体となって効率的
- rebase, filter-branch など歴史の改ざんが可能(もちろん remote 側の設定次第で reject もできるから悪用は防げる)
- git-flow に代表されるワークフローや、権威型など、プロジェクトの都合に合わせて運用しやすい
cons:
- git clone 時に歴史を丸ごとダウンロードするため、歴史が長いリポジトリだと時間がかかる(ただし最近の git なら --depth で省くこともできる)
- リポジトリが肥大化しがち(特に大きな画像等の asset 類を扱う場合)
- コマンドが非直感的(git reset や git checkout 等 git の内部構造を把握していないと理解しづらいコマンドがある)
Re:Subversionから移行して失敗 (スコア:1)
...
- リポジトリが肥大化しがち(特に大きな画像等の asset 類を扱う場合)
...
diff 出力表示など内容そのものの履歴管理が必要ないのであれば git-annex [branchable.com] などはいかが?
Re:Subversionから移行して失敗 (スコア:1)
git の外部で大きいファイル管理するための類似プロジェクト色々ありますよね。
- git-annex [branchable.com]
- git-fat [github.com]
- git-media [github.com]
- git-largefile [github.com]
ただ、やはり git だけで上手いこと取り扱ってほしいものですが、アーキテクチャ的に難しそうですね。
Facebook による [facebook.com]と、git はスケールしない (we concluded that Git's internals would be difficult to work with for an ambitious scaling project.)、という結論に至ったようですし、git 3.0.0 ではこの辺りの改善を期待したいところです。
Re: (スコア:0)
巨大なバイナリファイルを使うプロジェクトに参加していることもあって、gitがスケールしないってを痛感しています。
ソースコードなんかだと分散型バージョン管理以外あり得ないよねと言えるくらいに便利だと思ってますが、画像とかがががが
Re: (スコア:0)
上で紹介されていた中で構成がシンプルそうなgit-fatに挑戦してみた。
Windows環境で動かすのにぼちぼち手間取ったがひとまず動作。
結論から言うと使えそう。というか参加しているプロジェクトで使ってみようかしらん。
あ、でもgit-annexも試しておきたいな。
Re: (スコア:0)
今使っているバージョン管理システムに何の不満もなく完全に満足している人にはそりゃどんなアピールだろうと意味ないでしょう。
Re: (スコア:0)
分散リポジトリでもあるので、マスターが死んでも直ぐに再構築可能というところが売りだったような
そのせいで途中からチェックアウトが出来ないのかも・・・?
とりあえず簡単なリポジトリの分割ができれば特に言う事もないんだけど
Re: (スコア:0)
# て主張したのにTFSになった…何を言ってるのか分からねーと思うが俺も何をされたのか分からなかった
Re: (スコア:0)
他の言語も同じリポジトリに入れたいならともかく、Visual Studioから使うだけならTFSでいいじゃん。
Subversion的な欠点はTFSにはないし、Gitだとゲートチェックインとか一部機能が使えないから一長一短だぞ。
Re: (スコア:0)
Vssじゃないだけまし
Re: (スコア:0)
Re: (スコア:0)
バージョン管理システムなんでどれも対して変わらない。
新しいのいちいち覚えるのは面倒だ。
そう思ってた時期が自分にもありました。
しかし、ブランチの圧倒的な軽さ、次元の違うマージの賢さ
コードレビューを含めての分散開発のやりやすさなど、
今ではgit以外使う気になりません。
> ATの車で満足している人にMTに移行しようぜ
逆でしょ。
MT使ってる人にAT薦めてるんですよ。
しかもそのAT、あなたがMTで運転した時より格段に燃費良かったりする。
Re:Subversionから移行して失敗 (スコア:2)
が、仮にGitが良いとして問題は・・・。まぁ 会社における OS の移行みたいなもんでしょうね。
新しいソース管理システム使うとなると、移行が必要です。履歴を含めて変換が正しく成功するかリスクもあります。
既にSVN に百人規模でぶら下がってて、彼らの再トレーニングが必要。
Win XP -> Vista でわざわざ移行した会社さんがあったかどうかしりませんが、
3.1 -> 95 ぐらいのインパクトがあって、移行による効率アップが明白にならないと
わざわざ人員リソースを手配して1ヵ月単位で移行することはないでしょう。
Re: (スコア:0)
git svnでいいじゃん。使いたい奴だけ。
git svnでダメな理由が知りたい。
つまり、共有リポジトリをgitにする理由が。
Re:Subversionから移行して失敗 (スコア:1)
Gitのブランチでの履歴がgit svn dcommitで一つにまとまってしまってGitのメリットが生かせないから、共有リポジトリもGitにしてしまった方がいいと思う。
Git でのブランチに関する問題 [git-scm.com]
SubGitならなんとかなるみたいだけど。
Re: (スコア:0)
しばらく使ってたけど、このあたりの問題がめんどくさく感じられるようになって
それならquiltでいいやとsvn + quiltで最近やっている。
Re: (スコア:0)
基本的には同意。
まあ、マージはマージとして残したいなぁと思う事もままある。
ただし、そもそもgitについていけない人と仕事したくないとも思う。
Re: (スコア:0)
何のための分散型だと思っているんですか。移行したい人/できる人から順次移行していけばいいでしょうに。
Re: (スコア:0)
ローカルで気軽にコミットして作業できる(ローカルでどんだけ間違おうがどんだけ実験しようがサーバーに影響でない)とことか、
リポジトリの移動が楽とか、コンフリクトが起きたときにマージ明日でいいやと帰れるとか、
SVNのタグとかブランチって機能じゃなくてローカルルールなとことか。
ロックしたいバイナリファイルなんかはSVNも使いますけど、ソース管理はSVNには戻りたくないかなー。
コミットして平気かなって思わずとりあえずローカルでコミットしておけるのが大きいですかね。
その後失敗しても履歴はローカルに残ってますし。
基本機能しかつかってないですけど便利に感じています。
(まぁ私はMercurialですけど)
Re: (スコア:0)
vss使ってた会社にsvn入れさせて、svnから移行させるの簡単そうだからと個人的に使ってたhgから乗り換えてbzr1年ぐらい試してたんだけど、
gitlabのおかげでgitに移行しました。あのブランチの軽さやgitlabで簡単にレポジトリ作れるのがすごい便利。
特にアカウントの管理がすごい楽。公開鍵を一人ずつ手作業で登録してたssh+svnからだいぶ楽になりました。
他の社員とか自分じゃアカウント登録できないから派遣さんに同じ秘密鍵共有とかさせてたし。
なんつーか、gitlab(github)がすごい便利。
Re: (スコア:0)
GitLabいいですよね
ブラウザベースで履歴見るとき
たまにエンコーディングエラーで表示できない履歴がでたりするけど…
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つのパッチであったという情報は消えるので、そこは劣っているのかしら
Re: (スコア:0)
複数人で開発したこと無いなら分からないかもね。
一人で開発するならgitとsvnどっち使っても一緒。
結局自分が分かれば良いわけだし、gitを使ったところでまとめて修正して「色々コミット」みたいな履歴しか残さない人には意味無いし、svnでもちゃんと運用すれば納得いくような変更管理が出来るし。
Re: (スコア:0)
> 例えば、コードを書いて、同じファイルにAとBという、別の観点の修正があったとき、svnは1コミットにしかできない。
これ gitだとどう回避するの?
git add -p ?
ちょっとならいいけど、これだと限界があるような。
Re: (スコア:0)
OSSに関して言えば、「みんなが使っている」につきる。
# WindowsとかExcelの何がいいんですかね。
バージョン管理システムがマイナーなものだとコントリビューターに参加してもらうための障壁が1つ増える。
Re: (スコア:0)
バージョンが上がってもリポジトリの互換性がなくならないこと。
この業界にいてそれが重要だと思わないんだったらマジヤバイ
Re: (スコア:0)
最新の機能を利用したかったら svnadmin upgrade とかが必要だけど、互換性は保たれていたと思う。
作業コピーは 1.7 で大幅に変わったけど、 svn upgrade で変更出来るし、最悪チェックアウトし直すという手もある。