[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2chのread.cgiへ]
Update time : 05/09 19:59 / Filesize : 174 KB / Number-of Response : 728
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

バージョン管理システムについて語るスレ3



1 名前:デフォルトの名無しさん mailto:sage [2008/12/04(木) 14:02:52 ]
バージョン管理システムについて語りましょう。

関連スレ
CVS 1.3 [UNIX板]
pc11.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ〜 Rev.3 [プログラム板]
pc11.2ch.net/test/read.cgi/tech/1113141518/
Subversion r10 [プログラム板]
pc11.2ch.net/test/read.cgi/tech/1215565366/
subversion バージョン管理【サブバージョン】 [Linux板]
pc11.2ch.net/test/read.cgi/linux/1154701996/
git スレッド [Linux板]
pc11.2ch.net/test/read.cgi/linux/1197798039/
Bazaarでバージョン管理【bzr>git,svn,cvs】 [プログラム板]
pc11.2ch.net/test/read.cgi/tech/1218083381/

前スレ
バージョン管理システムについて語るスレ2
pc11.2ch.net/test/read.cgi/tech/1215520728/
前前スレ
バージョン管理システムについて語るスレ
pc11.2ch.net/test/read.cgi/tech/1193332500/

559 名前:デフォルトの名無しさん mailto:sage [2009/02/24(火) 07:08:27 ]
>>551
こと著作権に関して常識的にってのは通用しない
著作権法がすべて
そしてそれは常識とずれてるから世の中問題になってるわけで

560 名前:デフォルトの名無しさん mailto:sage [2009/02/24(火) 10:34:22 ]
>>559
BBSとかの規約もズレてる気はする

561 名前:デフォルトの名無しさん mailto:sage [2009/02/24(火) 11:20:07 ]
2chに帰属ってのも実際は争ってみないとわからないんじゃないの。

562 名前:デフォルトの名無しさん mailto:sage [2009/02/24(火) 11:59:49 ]
そういうのがめんどくさいから、パッチ書いたらどこかにアップしてURLを示すのが吉。

563 名前:デフォルトの名無しさん mailto:sage [2009/02/24(火) 12:42:14 ]
>>551
常識て。w

著作権は著作物に自動発生するだけ。
バグがどうとか関係ない。

564 名前:デフォルトの名無しさん mailto:sage [2009/02/24(火) 13:11:43 ]
そのパッチ程度だと創作的と認められるか微妙かもしれんけどね。

565 名前:デフォルトの名無しさん mailto:sage [2009/02/24(火) 13:57:05 ]
ここに#include <stdio.h>とかi++;とか書いたらこれも2chのチョサッケーンになるのか

566 名前:デフォルトの名無しさん mailto:sage [2009/02/24(火) 13:57:53 ]
バカじゃねえの

567 名前:デフォルトの名無しさん mailto:sage [2009/02/24(火) 15:49:22 ]
取り込む側が、余計なリスクを負うかどうかの問題なんだよ



568 名前:デフォルトの名無しさん mailto:sage [2009/02/24(火) 16:00:59 ]
>>565
その程度だと著作物としての創作的表現に入らないから np


569 名前:デフォルトの名無しさん mailto:sage [2009/02/24(火) 16:29:53 ]
>バカじゃねえの
は2chの著作物になりました

570 名前:デフォルトの名無しさん mailto:sage [2009/02/24(火) 20:24:35 ]
のまネコはavexの著作物

571 名前:デフォルトの名無しさん mailto:sage [2009/02/24(火) 23:39:16 ]
前提条件としての議論の余地が多分にあるが
仮に2chに書かれたコードがGPLのpatchであるとして、
仮に2chにそのコードの著作権があるとして、
そのコードが、GPLの派生である以上、GPLでなければならないならば、
2chが自らの著作物として、そのコードがGPLであると主張した場合、
どのような問題が発生するのだろうか?

572 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 01:23:29 ]
日本語でおk

573 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 01:30:50 ]
いつから著作権スレになったんだ?

574 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 02:03:58 ]
スレ移動しようぜ、向こうは過疎ってるし。

こっちはこっちで
同じ話題を短い周期で
繰り返してる気がするけどなw


575 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 08:43:47 ]
>>541
lanchpadはなんか規模がでかすぎる感じ。
インターフェースがわかりにくし、パッっとみ何するサイトなのか、なにしたらいいのかわからん。
githubとかBitBucket.orgみたいなコンパクトなリポジトリホスティングがほしす。

いってしまうと、googlecode projectみたいなのでいいんですよね。
それが、forkできればコラボが楽だなあ、という程度
(じゃあ、bzr-svnで(以下略))

あとlanchpadのサイト重いのもイヤイヤ感に拍車を掛ける。

lanchpadの利点がよくわからないから、どうしても否定的になってしまうな

576 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 08:45:25 ]
そういえば、TortoiseGitってどうですか?
そこそこ使えますか?
日本語対応具合とか
TortoiseGitで足りない機能ある時はコマンドライン版は何使ってます?

577 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 10:48:28 ]
>>575
Launchpad使ってるけど、その辺の意見には同意
Bazaarでの開発にはとても役に立つし、実際に便利に使わせてもらっているんだが
画面のゴチャゴチャ感と重さはどうにかならないかなーと思う
メニュー項目が必ず全部(使っていない項目も含めて)表示されることも、ゴチャゴチャ感を増している

ちなみにLaunchpadの利点は
・独自ブランチ→マージ提案が便利(ほかのホスティングでも似た機能はあると思うけど)
・共同翻訳(Translations)に強い
あたりかな



578 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 11:51:44 ]
>>576
試してから書き込め

579 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 15:51:48 ]
margeが優れてるのはdarcsでいいの?

580 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 16:13:12 ]
mergeが優れているのは人。

581 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 16:22:50 ]
>>579
mercurial or git

582 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 23:11:11 ]
そもそもmergeが優れているってどういうこと

583 名前:デフォルトの名無しさん mailto:sage [2009/02/26(木) 00:16:08 ]
SubversionとMercurial使ってるけど、俺も「Mercurialはmergeが優れている」って
聞く度にいつも、いまいち意味が分からんと思う。

584 名前:デフォルトの名無しさん mailto:sage [2009/02/26(木) 00:44:14 ]
branchは、破棄されるか、trunk(master)に統合されるか二択。
そういったprojectなら、gitやhgはbranchしたのが何時だったか思い出す
必要が無い。mergeが優れているのは、その一点のみ。
その主張は、ほとんどの場合正しい。

585 名前:デフォルトの名無しさん mailto:sage [2009/02/26(木) 01:34:55 ]
ああ、branchで作ったディレクトリを見失う(どこにブランチ作ったか忘れる)心配がないって事ね
でもそれmergeが優れているわけではなくて、単なるbranch方式の違いだよな

586 名前:デフォルトの名無しさん mailto:sage [2009/02/26(木) 02:08:42 ]
マージの優劣って言葉通りじゃなくて、マージトラッキングや
その自由度・速度を含めたことだと思うが・・・

587 名前:デフォルトの名無しさん mailto:sage [2009/02/26(木) 02:16:08 ]
Mercurialって、マージの自由度低くない?
統合する方向のマージに強制されてるような気になってる来るというか、
cherry-pickingしにくい仕組み。

むしろ、Subversionぐらいの放任主義の方が自由感がある。



588 名前:デフォルトの名無しさん [2009/02/26(木) 02:28:45 ]
git or mercurialは3-way マージでsubversionは2-way マージだったはず。

589 名前:デフォルトの名無しさん [2009/02/26(木) 02:32:41 ]
>>587
機能を追加するたびに、bookmarkがbranchを使えばそもそもcherry-pickingする必要がない。
gitとmercurialは両方とも、mergeとcherry-pickingを区別してたと思う。

590 名前:デフォルトの名無しさん mailto:sage [2009/02/26(木) 02:50:41 ]
>588
3-way マージって、
(1)自分が編集したバージョン
(2)第三者が編集したバージョン
(3)上の(1)の元になったバージョン
の3-wayでしょ?

なら、Subversionと一緒じゃん?

591 名前:デフォルトの名無しさん mailto:sage [2009/02/27(金) 00:19:15 ]
>>590
Subversionって、ファイル単位でコンフリクトしたらCになって終了(解消してね)
じゃなかったっけ。今は違うのかな。
svkとかGitだと行単位でぶつかってなければ良い感じにマージしてくれる。

592 名前:デフォルトの名無しさん mailto:sage [2009/02/27(金) 00:22:56 ]
CVSの昔から、行単位でぶつかってなければ自動マージだろう……。


593 名前:デフォルトの名無しさん mailto:sage [2009/02/27(金) 00:25:56 ]
行単位だよ。

594 名前:デフォルトの名無しさん [2009/02/27(金) 00:53:35 ]
>>590
gitとmercurialは(3)が(1)と(2)の両方の元になったファイル

595 名前:デフォルトの名無しさん mailto:sage [2009/02/27(金) 09:56:06 ]
Linuxレベルならともかく、普通の規模のプロジェクトとか
普通の業務利用とかでそんなに賢いマージが必要
なのは、ちょっとどうかという気もするが・・・

マージだけならSubversionで困らない。
会社でSubversion個人でGitだけど

596 名前:デフォルトの名無しさん mailto:sage [2009/02/27(金) 11:02:52 ]
も少し賢くてもいいけどなぁ
あと Subversion は遅くね?


597 名前:デフォルトの名無しさん mailto:sage [2009/02/27(金) 12:16:30 ]
TortoiseHGでコミットするとき、Mステータスのファイルにデフォルトでチェック付けたい。
どっかで設定できる?
コミットツールはinternalって設定にしてる。



598 名前:デフォルトの名無しさん mailto:sage [2009/02/27(金) 15:48:06 ]
分散SCMだと分岐したまま進められちゃうから、
共通先祖を考慮したマージが必要なんじゃないかな。

Mercurial の内部マージと diff3 のマージってどっちがいいのかな?
衝突時に共通先祖が表示されるんで diff3 使ってるけど・・・


599 名前:デフォルトの名無しさん mailto:sage [2009/02/28(土) 03:32:14 ]
デフォルトでチェックされてるけど

600 名前:デフォルトの名無しさん [2009/02/28(土) 08:09:04 ]
600

601 名前:デフォルトの名無しさん [2009/03/01(日) 13:26:37 ]
分散型のバージョン管理システムの場合、
それぞれのリポジトリはリポジトリ丸ごと
持っているという感じなんでしょうか?

あるリポジトリをマスターと決めたとして、
そのフルのクローンをそれぞれ持っているということでしょうか?

いまはSubversionを使っていて trunk, branches, tags 型で
かんりしてまして、branches の下の自分が作業を進める
ブランチだけ手元のワーキングコピーにチェックアウトして
作業しており、マージはマージ担当(まれに自分)に任せてます。

そもそも分散型だと trunk, branches, tags 型の
管理というのはやらないものなのでしょうか?

分散型のバージョン管理システムの紹介記事を読んでいると、
そもそも「ブランチ」というのはリビジョンツリー(というかDAG)
上の異なるヘッドことを指しており、リポジトリ上で別の
ディレクトリとして分岐されたものという意味ではないですよね?

確かに「ブランチするときはそのブランチ用のリポジトリを
作れば良い」という記述も見ました。そのときリポジトリ丸ごと
クローンするのでしょうか?巨大なプロジェクトだと一部だけ
クローンして作業を進めたいというのはあり得ると思います。

分散型だと「あるリポジトリが消失しても別のリポジトリを
マスターと思えばよい」という記述も見ましたので、
分散している各リポジトリはそれぞれ対等にフルのツリーを
持っているのでしょうか?

602 名前:デフォルトの名無しさん mailto:sage [2009/03/01(日) 13:50:00 ]
VCS毎に違いはあるだろうけど、たいていはローカル(というかハードリンク可能な場所)なら
ハードリンクでリポジトリの内容を共有して領域節約できる。
ネットワーク経由の場合もフルに取ってくるんじゃなくて、最新からこのリビジョンまでって指定も出来る。

「ブランチ」って言葉の使い方も、VCS毎に変わるから一概に言えないな。
gitやhgは同じリポジトリの中でブランチ出来るけど、bazaarはリポジトリも別になるとか。

結局のところいくら記事読んでも、実際使ってみないと実感わかないと思うよ。
きっと分散じゃないVCS使い始めたときもそうだっただろ。
Subversion使ってるなら、svkとかgit-svn使ってみるとか。

603 名前:デフォルトの名無しさん mailto:sage [2009/03/01(日) 14:11:54 ]
そもそも「リポジトリ」という言葉の意味すらシステムによって違うしな

>>601
端的に言うと、分散型の進め方では
「フルのクローンをそれぞれ持っている」という理解はおおよそ合ってる
各作業メンバーが、「masterの履歴+自分が行った変更の履歴」を持ってるような感じ

> 巨大なプロジェクトだと一部だけ
> クローンして作業を進めたいというのはあり得ると思います。
一部だけ持ってこれるような仕組みがあるよ
たとえばBazaarなら、履歴なしで最新版のファイルだけを取ってこれるようなオプションがある

604 名前:601 [2009/03/01(日) 14:58:56 ]
>>602-603 ありがとうございます
>gitやhgは同じリポジトリの中でブランチ出来るけど、bazaarはリポジトリも別になるとか。

分散型といってもいろいろあるんですね、流儀が(当たり前か)。

>>602 wrote ネットワーク経由の場合もフルに取ってくるんじゃなくて、
>最新からこのリビジョンまでって指定も出来る。
>>603 wrote たとえばBazaarなら、履歴なしで最新版のファイルだけ
>を取ってこれるようなオプションがある

リビジョン範囲は指定できるものもあるんですね。
「分散型」を十把一絡げで理解しようとしたのが間違いでした。

605 名前:601 mailto:長文すみません [2009/03/01(日) 15:01:29 ]
最も強く疑問に思ったのは、あるプロジェクトのリポジトリ内に
「アプリの主要部分、いくつかの下請けライブラリ、
ドキュメント、UI関係」などがあったとき、
自分が担当しているライブラリ、ドキュメントの部分だけを
クローンして作業を進めるということができるのだろうか、という点でした。

これは最初から「ドキュメント用のリポジトリ」などに分離
しておくのが分散型の流儀なのだろうか?という点です。
これもDVCSによって異なるのかもしれませんが。

もう一つの疑問が、そのように完全に分離したとして、
共通の祖先をもたない複数のリポジトリを複数あつめて
一つのプロジェクトを遂行するのは難しいのでは?ということです。

たとえばプロジェクトの途中で「これは共通のライブラリで実現するように分離しよう」
などという決定が 可能なのだろうか、と懸念しています。

Pythonを常用しているので、まずはMercurialとBazaarから主に上記の点について
実感をもつべく使い始めてみようと思いますが、DVCSの機能もさることながら
運用上のポリシー という側面も大きいと思うので、実際に使っておられる方の
アドバイス(ベターなプラクティス)があればぜひお聞かせください。

606 名前:デフォルトの名無しさん mailto:sage [2009/03/01(日) 16:48:13 ]
そもそも分離したいという目的は?
リポジトリの物理的大きさの問題であれば
いまさらそんな気にすることはないと思うけど・・・

管理面の規模の問題なら、分割するのもありかもね。
JDK7 なんかは分かれてるし。
分割した方が管理コストがさげられるならそうするべきでしょう。

607 名前:デフォルトの名無しさん [2009/03/01(日) 18:47:10 ]
sarabande.info/doc/bzr/user-guide
ここの画像無くなってる?



608 名前:デフォルトの名無しさん mailto:sage [2009/03/02(月) 20:27:43 ]
>>601さん、なかなか興味深い質問ですね。
分散VCSを使い始めた人の意見や疑問点をもっと聞いてみたいので、ほかにも質問があれば遠慮なく書いてください。
もちろんすべてに答えられるわけではないですが、他の人にも参考になると思います。

>>606
ディスクスペースを節約するために必要なディレクトリだけ持ってくるというのはあり得る。
たとえばゲームのように画像や動画や音声ファイルがある場合、それらもリポジトリに登録するべきだけど、
そうするとリポジトリサイズが膨らみすぎて、いくらHDDが安いと言ってもちょっと困る。
リポジトリからとってくるネットワーク資源もばかにならない。

あと、ディレクトリごとにアクセス権をつけたいという要求もある。
たとえば画像ファイルは全員がアクセス可能だけど、元となるPhotoshopファイルはデザイナーだけがアクセス可能にしたい、とか。
#この場合はリポジトリを分けた方が自然かも。

609 名前:デフォルトの名無しさん mailto:sage [2009/03/03(火) 02:43:14 ]
>>608
メディアファイルをリポジトリに「登録するべき」と決めつけずに、
分散かどうかに関わらず、リソースなども照らし合わせて管理方法を検討すべきだろうね。
最新ファイルしかいらないのにそもそもリポジトリを公開すべきなのか、とかも。

サブプロジェクトへの権限委譲については、
やっぱりJDK7みたいにするのがいいんじゃないかな。
アクセス制限も分散は難しいし、ロックもないし、
人間どうしの折衝や信頼は結構重要。


610 名前:デフォルトの名無しさん mailto:sage [2009/03/03(火) 09:52:12 ]
>>605
あまり回答にはなってないだろうけど参考までに。

何度も書いたが、CVS は modules ファイルを駆使してリポジトリツリーの
好きなところからちぎってきて組み合わせられるのが便利だった。
管理が良くも悪くもファイル単位ゆえ、自作ライブラリディレクトリから
アプリに必要なファイルのみチョイスするような芸当もできた。

今は Subversion を飛ばして Mercurial を使用(試用)中だけど、さすがに
CVS のような細かいことはできそうにないし、ハードウェアリソースも KB 単位で
ケチるような状況ではないので、ライブラリに関しては独立したリポジトリとして
開発時のディレクトリ構成を工夫している。

ただ、ファームウェアのような非常に小さなプロジェクトがたくさんあるような状況では、
いちいちリポジトリを分けるか一まとめにしてしまうかは悩むところ。分けると同期も面倒に
なってくる。今のところ、とりあえず一まとめにしているけど、もっといい方法はないか思案中。
大きなプロジェクトで使うことに主眼が置かれているんだろうな。

611 名前:デフォルトの名無しさん mailto:sage [2009/03/03(火) 22:23:29 ]
>>608
> あと、ディレクトリごとにアクセス権をつけたいという要求もある。
> たとえば画像ファイルは全員がアクセス可能だけど、元となるPhotoshopファイルはデザイナーだけがアクセス可能にしたい、とか。
> #この場合はリポジトリを分けた方が自然かも。
こういう事やりたいなら、PerforceやTeam Foundation Serverのような、
クライアント・サーバー型のバージョン管理システムが適してる。

612 名前:デフォルトの名無しさん mailto:sage [2009/03/03(火) 23:08:29 ]
python3000で組まれたバージョン管理ツールってないのかな?

bzrやhg何かの古株が対応するよりも新しく作る方が
早いかもしれんし。

613 名前:デフォルトの名無しさん mailto:sage [2009/03/04(水) 13:17:49 ]
windowsで日本語も使えるのはどれになるのでしょうか?
darcsの話題があんまり出ないのは死んだプロジェクトになってしまったのでしょうか?

614 名前:デフォルトの名無しさん mailto:sage [2009/03/04(水) 14:19:36 ]
>>613
全部試せよ。
それが嫌ならSubversionを押し戴け。

615 名前:デフォルトの名無しさん mailto:sage [2009/03/04(水) 21:21:08 ]
日本語を使えるので人に勧められるのはSubversionしかない

616 名前:デフォルトの名無しさん mailto:sage [2009/03/04(水) 23:22:18 ]
日本語コミットメッセージが書ければうちでは十分。


617 名前:デフォルトの名無しさん mailto:sage [2009/03/04(水) 23:22:27 ]
svnで不満があるならsvk使えばいいし。
svn最強。



618 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 02:30:42 ]
svnは良くも悪くも無難でいいけど、svkはいろいろ酷い目にあった。


619 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 09:52:59 ]
TortoiseHgの欠点は、
・付属のhgだと日本語ファイル名×
・TortoiseHgだと日本語ファイル名OK
・でも、hg mv がないwww

ので、現時点で日本語ファイル名のファイルの移動する手段がありませんw
ワロタ

620 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 09:53:30 ]
> ・でも、hg mv がないwww
・でも、TortoiseHgにはhg mv 相当がないwww

スマソ

621 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 09:55:53 ]
>>613
WindowsでGUIでやりたいとなると、TortoiseSVNしか選択子なしですわ

622 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 10:51:26 ]


623 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 11:00:22 ]
trac + svnで充分満足であります

624 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 15:21:59 ]
hg来たな

625 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 18:09:59 ]
>>624
0.7入れてみた。
毎回アンインストール→再起動→インストール→再起動を強いられるのは勘弁して欲しいな。
あと、テーマ機能とか付いたみたいだけど、そんなことしてる場合じゃないだろって感じ。
まだまだですな。

626 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 19:38:47 ]
>>610
ライブラリ毎にリポジトリをつくったら、あとは
プロジェクトのリポジトリをつくって
ライブラリをhg pull --forceで取り込んでmergeすればok.


627 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 20:00:26 ]
git push でエラーが出ます。

$ git push
Counting objects: 9, done.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 924 bytes, done.
Total 6 (delta 3), reused 0 (delta 0)
To git@github.com:myname/project.git
3648514..9fc4c3a ot -> ot
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'git@github.com:myname/project.git'

これはどういう意味で、どう対処すればいいでしょうか。



628 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 20:04:29 ]
うちの環境では0.7+ini設定で日本語使えてる感じがするな
まあたまたまなのかもしれん

629 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 20:07:30 ]
>>626
意味がよくわからない。
最後の節の、小さなプロジェクトがたくさんある場合の対処法?

630 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 22:53:08 ]
>> 628
TortoiseHg 0.7にwin32mbcsエクステンションの設定で、わりといい線までいくみたいですね。
でも、ディレクトリ名の最後の文字が0x5cを含んでいたりすると、まだコケる模様。


631 名前:デフォルトの名無しさん mailto:sage [2009/03/05(木) 22:53:56 ]
アンカー失敗したorz

632 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 00:39:14 ]
>>627
>>282

633 名前:デフォルトの名無しさん [2009/03/06(金) 02:06:53 ]
>>630
多分TortoiseHgだとファイル名を指定してaddしてるんで動いているように見えるだけ。
Mercurial 1.2でも直ってない。

634 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 02:15:23 ]
正直、日本語ファイル名の対応でいうと
SVN>bazzar>git>mercurial
何もしないでバイト列で扱うgitのほうが、まだマシだ

635 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 04:50:33 ]
もう疲れたよ、パトラッシュ・・・

636 名前:デフォルトの名無しさん [2009/03/06(金) 08:58:53 ]
Mercurial Patch
ttp://bitbucket.org/witten/win32mbcs-patch

637 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 10:52:03 ]
git のfast forwardって何ですか。
マニュアルみてもさっぱりわかりません。



638 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 11:10:00 ]
>>636
何勝手に2chの著作物を断りもなく公開してんだよ?

639 名前:デフォルトの名無しさん mailto:sage [2009/03/06(金) 22:07:18 ]
>>635
マネスレに(・∀・)カエレ!!


640 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 01:36:05 ]
1.6.2

641 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 01:42:16 ]
>>637
www.kernel.org/pub/software/scm/git/docs/user-manual.html#fast-forwards

642 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 09:27:55 ]
                       /
                 ,. 、       /   /
               ,.〃´ヾ.、  /  /
             / |l     ',  / /  2chの著作物です!
        ,、     ,r'´  ||--‐r、 ',      パッチは2chの著作物でした!
       l.l. ,..ィ'´    l',  '.j '.     パッチは2chの著作物でした!
       'r '´          ',.r '´ !|  \
       l!     ....:.:.:.:.:.:ヽ、   ,l    \
        ゝ、.,_ ---‐‐‐----ゝ、ノ
        | |
         .| |
          | |
        | |
           | |


643 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 19:40:51 ]
個人で使う分には関係ないだろ。
本家には未来永劫取り込まれないだろうが。

644 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 19:52:07 ]
だがちょっと待ってほしい。
2ちゃんねるが初出だとどうして言えるだろうか。

どこかに公開されていたものが2ちゃんねるに投稿されたのではないか。
2ちゃんねるにそれを書き込んだ人物が、
当該文書の原著作者であったとどうして証明できるだろうか。

645 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 20:00:20 ]
方式主義なら話は単純だったんだろうか。

646 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 20:32:44 ]
話を3日前にもどそう

647 名前:デフォルトの名無しさん mailto:sage [2009/03/07(土) 22:28:02 ]
bzr revert -r date:2009-03-04



648 名前:デフォルトの名無しさん mailto:sage [2009/03/08(日) 02:27:26 ]
著作権ってある程度芸術性みたいなのが求められたりするし、
そのパッチ単体程度だと、著作物にならないんじゃね。
まぁ、慣例的にもそこに文句つけたりしないだろうし、
どうでもいいが。

649 名前:デフォルトの名無しさん mailto:sage [2009/03/08(日) 04:31:46 ]
日本ではたぶんそうなる。
問題は、日本だけで開発されてるようなプロジェクトじゃないってこと。
将来の開発者を含む全ての開発者が、今後活動する可能性がある全ての国や地域の法規に照らして判断する必要がある。
そうじゃないと、例えば何も知らずに加わった新開発者が、旅行先で突然逮捕されるかもしれない。

ぶっちゃけ、そんなリスクのあるパッチ取り込むより、自分達で書き直すほうがまし、っていうか。

650 名前:デフォルトの名無しさん mailto:sage [2009/03/08(日) 09:00:28 ]
TortoiseHg付属hgの日本語ファイル名周りしらべたけど、hg mvが駄目ってのは勘違いだったみたいスマソ。

hg commit(hg ci)で、addした駄目文字ファイル名のファイルがコミットできないみたい。
hg mv が駄目だと思ったのは、mv時にremoveしてaddされるので、その後のcommitがおかしいためみたいです。

検証過程:

>touch 表の噂.txt # touchは空ファイル作ってるだけです。
>touch test.txt # ただしBorland版touchね
>hg st
? test.txt
? 表の噂.txt
>hg ci -A -m "added from command line" # 追加しながらコミット。ここまではよい
adding test.txt
adding 表の噂.txt
>hg st # コミットできてねえ!add相当は一応できてる
A 表の噂.txt
>hg add . # 念のため
>hg ci -m "added from command line retry"
nothing changed # ええ!?無視ですか?
>hg st
A 表の噂.txt # ダメポwww

つーわけで、>>636 を試してみるぜ

651 名前:デフォルトの名無しさん mailto:sage [2009/03/08(日) 09:13:43 ]
あれ?もしかして、>>636ってソースからコンパイルがいるのかよ・・・
Bazzarみたいにプラグイン形式じゃないのか orz
面倒クセー

652 名前:デフォルトの名無しさん mailto:sage [2009/03/08(日) 13:04:22 ]
TortoiseHg 0.7 かなりよいですねー。

コミットツールがようやく置き換えられて、ファイル名や以前のコミットログの参照は、
駄目文字含め文字化けしなくなった。
diffの表示も中身がSJIS、UTF-8でも問題ない。
(このコミット時の簡易diff表示は他のTortoise系でもほしいくらい)

残念ながら、Rename Fileはリネームのダイアログが文字化けするし、
win32mbcsのエラーで実際にリネームできないし、
ドラッグアンドドロップでのリネームはまだ非対応なものの、
Guess Renamesで適当にリネームした後、リネームの自動検出ができる。
そっちは駄目文字含め、日本語ファイル名OK、なので実質は問題ないだろう。

これで、コマンドライン版 hg なくても日常作業は事足りるようになった。

しかし、hgのコマンドライン版は日本語リソース追加されてて、日本語で出てきてびっくりしたw

653 名前:630 mailto:sage [2009/03/08(日) 13:46:07 ]
>>652
日本語ファイル名対応は、まだ完全ではないようなので要注意ですよ。

654 名前:デフォルトの名無しさん mailto:sage [2009/03/08(日) 14:23:16 ]
>>651
本体の1.2のソースダウンロードしてローカルリポジトリ作って>>636のパッチ当てて
できたhgext/win32mbcs.pyとmecurial/util.pyをTortoiseHg/library.zipの中の同じ位置に配置すればとりあえず動くっぽい

655 名前:652 mailto:sage [2009/03/08(日) 15:11:02 ]
TortoiseHg 0.7 で 実質、>>619の問題は一応解消した。

>>650 は相変わらず駄目だが、直接ファイル名指定してやると一応通る

>hg ci -m "added from command line retry" 表の噂.txt
>hg st        # OK
>

だけどまあちょっと怖いね。


しかし、bitbucket.rogに日本語ファイル名のファイルをpushしたら、
未だに更新ファイルの詳細ページがInternal Server Errorで見れねえw
これ、大分前から変わってないな

656 名前:デフォルトの名無しさん mailto:sage [2009/03/08(日) 21:34:15 ]
TortoiseHg 0.7のコミットツールの
ログ入力欄のフォントが気に入らない。
変更できねえかな。

657 名前:デフォルトの名無しさん mailto:sage [2009/03/10(火) 19:06:14 ]
TortoiseHgの翻訳をLaunchpadでするって激しく何か間違っている感が…。



658 名前:デフォルトの名無しさん mailto:sage [2009/03/11(水) 20:31:36 ]
git push

git push origin master
の違いがわかりません。だれか教えて。

あと
git checkout -b dev origin/dev
としたあとにpushするのって、
git push
でいいのか
git push origin dev
としなきゃいけないのか、どっちでしょう。

マニュアルのここを読めでもいいので、教えてください。

659 名前:デフォルトの名無しさん mailto:sage [2009/03/11(水) 23:50:36 ]
>>658

git push だけの場合は<repository>と<refspec>を省略したことになるので、
.git/configにremoteとmergeが指定されていればそこにpushしようとするよ。

git checkout -b dev origin/dev とした場合は、devにremoteとmergeが指定されてる
はずなので、省略してgit pushだけでもおk。

git pushはExamplesが俺はすごい分かりやすいと思う
ttp://www.kernel.org/pub/software/scm/git/docs/git-push.html#_examples






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<174KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef