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

実際、テキスト形式のソースコード（プログラミング言語とかマークアップとか）
ならいくらでも差分取れるから、分散型でもマージすりゃいいじゃん、
って考えられるけど、差分取れないとか、人が差分見ても意味不明とか、
そういうファイルフォーマットメインでやらなきゃいけない場合、
どうすりゃいいんだろうね。

つかまあ、そういうフォーマット使う限りはどうにもならないかね…

30 ：デフォルトの名無しさん：2010/09/08(水) 06:57:28

そういう時は目で差分取るしかないんじゃないかなぁ。
diff とってマージと意味はかわらないよね。

Word Excel は差分取るプログラムとか探すと見つかるし
そう悲観したもんじゃないと思うけど。

というわけで文章はいいんだけどさ、画像とかどうしょもないよね。

31 ：デフォルトの名無しさん：2010/09/08(水) 09:22:02

TortoiseSVN の TortoiseIDiff が出たばっかりの頃は面白がって使っていたけど
最近はさっぱり使わなくなったな。
画像を重ねて透かして見るのが楽しかったｗ

32 ：デフォルトの名無しさん：2010/09/08(水) 13:09:26

>>24
せっくす(笑)

33 ：デフォルトの名無しさん：2010/09/09(木) 02:14:02

人種差別と排外主義を許さない人たちが見せた本性
人種差別と排外主義を許さない人たちが見せた本性
http://www.youtube.com/watch?v=B4iM0b8mSQ8&feature=related
http://www.youtube.com/watch?v=B4iM0b8mSQ8&feature=related
人種差別と排外主義を許さない人たちが見せた本性
人種差別と排外主義を許さない人たちが見せた本性

34 ：デフォルトの名無しさん：2010/09/09(木) 23:51:50

CodePlex.com donates $25,000 to Mercurial project
http://blogs.msdn.com/b/codeplex/archive/2010/09/06/codeplex-com-donates-25-000-to-mercurial-project.aspx

Microsoftも、ついにTeam Foundation Serverを捨てる覚悟ができたか。

35 ：デフォルトの名無しさん：2010/09/10(金) 00:22:18

>>34
たった200万円くらいじゃねえか。

36 ：デフォルトの名無しさん：2010/09/10(金) 00:22:26

TFSとMercurialじゃ方向性が全然違うだろう。

それはともかく、せっかく支援するならWindowsの日本語ファイル名をなんとかして…くれないよなぁ。

37 ：デフォルトの名無しさん：2010/09/10(金) 02:43:39

200万つったらTFSの1ライセンス分くらいか？

38 ：デフォルトの名無しさん：2010/09/10(金) 03:00:03

>>36
おい、UTF-16対応フラグだろ、それはｗ Python3の内部はUTF-16だっけ？
UTF-8そっちのけになってマルチプラットフォームでやりとり不可の可能性すらあるだろがｗｗｗ

39 ：デフォルトの名無しさん：2010/09/10(金) 09:55:43

MSにとってapache傘下になったsvnよりhgの方が都合が良いってことか？

40 ：デフォルトの名無しさん：2010/09/10(金) 14:30:43

消去法だったり…

open source と、いうか、
不特定な人々でソースコードを突いた方が、
解決する類の問題がある事に気付く。
↓
`不特定な人' って事で、
分散型＆無料＆オープンの中で、VCSを物色する。
↓
git -> linux のイメージ
bzr -> gnu のイメージ
hg -> これかな

みたいな

41 ：デフォルトの名無しさん：2010/09/10(金) 14:58:04

hgはOpenJDK,OpenOfficeでSUNってイメージがあったのだが、そのSUNが・・・

42 ：デフォルトの名無しさん：2010/09/10(金) 15:06:15

使ってる人達じゃなくて、作った人の話でしょ。

43 ：デフォルトの名無しさん：2010/09/10(金) 15:19:42

>>42
コミットのログにアットマークsun.comならいるけど

44 ：デフォルトの名無しさん：2010/09/10(金) 17:12:37

>>42
作った人ならmercurialはLinuxのイメージじゃないか？

45 ：デフォルトの名無しさん：2010/09/11(土) 00:59:54

tortoisesvnにまったく不満ないんだけどなにかある？

46 ：デフォルトの名無しさん：2010/09/11(土) 01:01:48

>>45 CPU 負荷 HDD アクセス負荷が高すぎる気がする。

47 ：デフォルトの名無しさん：2010/09/11(土) 03:21:23

mercurial で、git ci --amend 相当のことってできますか。
直前のコミットコメントを修正するのに、git ci --amend がすごく便利なので、
同じような機能がmercurialにあれば教えてください。

48 ：デフォルトの名無しさん：2010/09/11(土) 04:24:20

>>47
http://stackoverflow.com/questions/623052/how-to-edit-incorrect-commit-message-in-mercurial

49 ：デフォルトの名無しさん：2010/09/11(土) 06:45:23

>>45
エクスプローラにフック入れてくるからSVN使う作業時以外でもモッサリにされた。

50 ：デフォルトの名無しさん：2010/09/11(土) 07:23:58

>>45
Subversionに対する不満ならたくさんあるが、そういうことではなく？

51 ：デフォルトの名無しさん：2010/09/11(土) 07:26:16

>>45
vistaからexplorerでリビジョン番号とか表示できなくなって使う意味が減った。

52 ：デフォルトの名無しさん：2010/09/11(土) 07:39:57

>>45
Windowsでしか使えないこと

53 ：デフォルトの名無しさん：2010/09/11(土) 07:48:12

>>47
直前だったらrollback

54 ：デフォルトの名無しさん：2010/09/11(土) 08:07:30

>>45
バージョンアップ時にアンインストールが必要だったりして
複数回の再起動が必要だったりすること
業務中にはちょっと切ない。特に、他人にバージョンアップさせるときに

55 ：デフォルトの名無しさん：2010/09/11(土) 14:23:24

TortoiseSVN、TortoiseGitが再起動要求する場面は
ログアウト→ログインで事足りるはずだよ

56 ：デフォルトの名無しさん：2010/09/11(土) 18:05:35

再起動後にファイルの削除やリネームがスケジューリングされてることがあるから
それだけじゃ済まないだろ。

57 ：デフォルトの名無しさん：2010/09/11(土) 19:52:56

強制的にexplorer落とすDropboxよりはナンボかマシｗ

58 ：デフォルトの名無しさん：2010/09/14(火) 17:03:58

Subversion r12スレより誘導されてまいりました。

1人でphpの開発をしております。
本番サーバー、開発サーバー、バックアップサーバー、3台のサーバーがあります。

今はFTPで開発サーバーに接続、動作確認、開発サーバーから本番サーバーにrsyncで同期

という方法をとっております。

本番サーバー、開発サーバーとも、日毎にバックアップサーバーに保存しております。

開発にはsubversionがあたりまえ、というようなことを耳にしましたが、このような開発環境でsubversionを導入するメリットというのはどんなものがあるのでしょうか？

59 ：デフォルトの名無しさん：2010/09/14(火) 17:16:14

それはバージョン管理システムのメリットとは何かと問うているに等しいよ。
その言語と環境に特化していうべきことはない。
どっかの入門記事読んで試験的に導入してみた方が早い。
バックアップとは別にバージョン管理をするメリットは十分にあるとだけ言っておこう。

# 屋根裏尾はあえて使ってないみたいだけど

60 ：デフォルトの名無しさん：2010/09/14(火) 17:19:09

>日毎にバックアップサーバーに保存

履歴がはっきりしてるならこれでいいよ

61 ：デフォルトの名無しさん：2010/09/14(火) 17:30:54

>>58
何も困ってないのならそのままでもいいかも知れないけど、
導入すれば一般的なバージョン管理システムの恩恵が得られる
・変更内容を追うことができる（ログメッセージが役立つ）
・複数人体制になった時に行き違いを防止することができる（ファイル上書きなど）
・リリースバージョンと開発バージョンをフォークしたり（これは分散型のほうが得意）
・テスト＆バグ報告などを行う場合に、対象バージョンを特定しやすい

62 ：58：2010/09/14(火) 17:34:56

>>59
やはり差分が管理できるというのが一番の利点でしょうか？
環境は準備し、少し触ってみたのですが、いじったらコミットして、サーバーにもFTPで上げないといけないので面倒だなぁと感じております。

>>60
日毎でとってるので2週間程度はさかのぼれますが、1日に複数回、大幅な変更などをしたとき戻りにくい。
1年前とかのファイルは残ってない、というのが問題でしょうか？

63 ：デフォルトの名無しさん：2010/09/14(火) 17:36:58

＞サーバーにもFTPで
いやサーバにリポジトリ作る、、というかサーバにシステム入れて使うのが普通

64 ：デフォルトの名無しさん：2010/09/14(火) 17:43:23

>>63
そのサーバーって開発サーバーのことですよね

65 ：デフォルトの名無しさん：2010/09/14(火) 17:44:57

>>62
大幅な変更があるならそのときだけ日ごとじゃなくて作業ごととかにすりゃいいんじゃね？

66 ：デフォルトの名無しさん：2010/09/14(火) 17:45:48

>>58
FTPで接続とあるから、おそらくPHPコードのマスタはクライアントPC上に
あるのだと思うけど、Subversionによるバージョン管理というのは、
(テスト環境や運用環境ではなく)マスタとなる(PC上にある)PHPコードの変更履歴を
管理することを目的に導入するもの。バックアップの世代管理とは区別して考えなさい。

Subversionの遠い祖先にあたるSCCSというバージョン管理システムのSCCSという単語は、
Source Code Control System(ソースコード制御システム)の略語。
ソース(PHPコード)の管理が基本的な導入の目的だよ。

67 ：デフォルトの名無しさん：2010/09/14(火) 17:49:58

作業コピーごとサーバに置いてソースコード流出

68 ：デフォルトの名無しさん：2010/09/14(火) 17:54:40

>>67
> 作業コピーごとサーバに置いてソースコード流出
svnが各ディレクトリにできるから分散型の方が良いと思うけどどうなんだろう？

69 ：デフォルトの名無しさん：2010/09/14(火) 17:56:10

>>68
> >>67
> > 作業コピーごとサーバに置いてソースコード流出
> svnが各ディレクトリにできるから分散型の方が良いと思うけどどうなんだろう？
ドット入れたつもりが抜けちゃった。
".svn"が各ディレクトリにできるから分散型の方が良いと思うけどどうなんだろう？

70 ：デフォルトの名無しさん：2010/09/14(火) 17:58:37

>>69
できればリリース作業はVCSとは別にスクリプト作っておいたほうが良いと思う

71 ：デフォルトの名無しさん：2010/09/14(火) 18:15:01

>>62
1ヶ月かかる新機能追加(既存ファイル変更しまくり)やってる後半に、現行版の緊急の修正が3個くらい舞い込んできたらどうしてんの？

72 ：58：2010/09/14(火) 18:35:22

後だしですみませんが、開発環境に追加で、Windowsのテキストエディタでコードを記述、FTPでファイルをアップロードしてます。
tortoisesvnの使用です。

>>61
後のことを考えるなら、今のうちから導入しておいたほうがよさげなのですね。

>>63
>>64
リポジトリは開発サーバーに作成してますが、
・手元でファイル修正→コミット
・修正したファイルをアップロード
これは別物ですよね？
手元でファイルを修正→コミット＝アップロード
というのは不可能ですよね。

>>66
マスターのファイルは開発サーバー上にあります。
開発サーバーにFTP接続→ダウンロード＆修正→開発サーバーにアップロード
上でも書いたのですが、バージョン管理と、開発サーバーにアップロードは別物ということですよね？
バージョン管理するために、ひと手間かけるという認識でよいのでしょうか？

>>67
開発サーバーの公開ディレクトリにチェックアウト、編集しアップロードしたらコミットというのを考えましたが、それだと複数人で作業したときの競合がおき、全く利点がないですよね…
コンパイルが不要のphpなので、考えかたがjava等とは違うのでしょうか？

>>71
本番サーバーから直接ファイルをダウンロードして、修正し本番サーバーにアップロード、修正した部分を変更中のものにも適用、というようなことをしています。
直接本番サーバーで作業するため、稀にエラーやらバグが発生しますが、事後修正で対応でいるようなサイトなので…
こんな考えだからsubversionの利点を見出せないのでしょうか…

73 ：デフォルトの名無しさん：2010/09/14(火) 18:46:23

>>72
> 直接本番サーバーで作業するため
> こんな考えだからsubversionの利点を見出せないのでしょうか…
うんそう
そこで仕事が貰えてるなら、もうそのままで良いんじゃない？
君が不可能と考えてる事は簡単に可能だし、懸念してる手間など初めからないし
開発者のあり方として、素人の遊びレベルのクオリティだけど、まぁ、そのままで良いんじゃない？

74 ：66：2010/09/14(火) 18:59:28

>>72
>マスターのファイルは開発サーバー上にあります。
それなら、単純だ。開発サーバにSubversionを導入してコード管理すればいい。

>開発サーバーにFTP接続→ダウンロード＆修正→開発サーバーにアップロード
FTPではなくSamba(for Win)またはNFS(for UNIX)で接続(マウント)し、
開発サーバ上のPHPコードを直にエディタで編集するほうが楽だと思う。
あるいはレンタルサーバのようにサーバマシンがリモートサイトにあるのなら、
sshfsという方法がある。"sshfs" あるいは "FUSE" でググレば情報を見つけられる。
個人的には、vim(エディタ)を習得することがUNIXマスターへの第一歩だと思うけど...。

>バージョン管理するために、ひと手間かけるという認識でよいのでしょうか？
開発サーバ上のSubversionリポジトリに最新コードをチェックインしたら、
その後のテスト環境へのチェックアウトは、手作業ではなくスクリプトで自動化させる。
make/Makefileあるいは類似の自動化ツールを勉強すること。慣れれば手間はかからない。

75 ：デフォルトの名無しさん：2010/09/14(火) 19:07:48

>>72
> 後だしですみませんが、開発環境に追加で、Windowsのテキストエディタでコードを記述、FTPでファイルをアップロードしてます。
> tortoisesvnの使用です。
>
これはWindowsのローカルにリポジトリを置いているってこと？
BDB、FSFSどっち？

76 ：デフォルトの名無しさん：2010/09/14(火) 19:40:15

> 開発にはsubversionがあたりまえ、というようなことを耳にしましたが、このような開発環境でsubversionを導入するメリットというのはどんなものがあるのでしょうか？

> 後だしですみませんが、開発環境に追加で、Windowsのテキストエディタでコードを記述、FTPでファイルをアップロードしてます。
> tortoisesvnの使用です。

svnは使っているの？それとも、これから導入を考えているの？試し程度に少し触った程度なの？
「導入を考えて試しに少し触ったけど、メリットが見出せなかった。」だと思っていたんだけど、
どうも「TortoiseSVN使っているけど、メリットが見出せない」なのかな。
branchもtrunkも作らずにやっているのかしら？

77 ：デフォルトの名無しさん：2010/09/14(火) 19:50:04

> 手元でファイルを修正→コミット＝アップロード
> というのは不可能ですよね。
subversionのpost-commit-hookでアップロードすればいい。

78 ：デフォルトの名無しさん：2010/09/14(火) 19:53:04

こんなことなら元スレでやればよかったなｗ

79 ：デフォルトの名無しさん：2010/09/14(火) 20:08:27

バグがあっても事後修正で対応してゴメンナサイすれば済むサイト(>>72)で、
そのくらいのソフトウェア品質管理水準を許容できる開発体制なのだから、
バージョン管理(SCM: ソフトウェア構成管理)導入の意味(目的/価値)が分からない。

>>73が言ってるように、それで仕事が貰えてるなら、そのままでいいんじゃないかと思う。

80 ：デフォルトの名無しさん：2010/09/14(火) 20:25:53

ftp・rsyncってファイル上書きする可能性のあるので良くやっているなと感心する

81 ：デフォルトの名無しさん：2010/09/14(火) 20:48:03

>>78
そうだなｗ

82 ：デフォルトの名無しさん：2010/09/14(火) 22:33:13

引っ越してきました
末永くよろしくです

Git 2
http://hibari.2ch.net/test/read.cgi/tech/1284467898/

83 ：デフォルトの名無しさん：2010/09/14(火) 23:28:11

>>72
> >>71
> 本番サーバーから直接ファイルをダウンロードして、修正し本番サーバーにアップロード、修正した部分を変更中のものにも適用、というようなことをしています。
> 直接本番サーバーで作業するため、稀にエラーやらバグが発生しますが、事後修正で対応でいるようなサイトなので…
> こんな考えだからsubversionの利点を見出せないのでしょうか…

すげえｗ
いやでも、これで仕事ができてて、食えてるならいいと思うけどな俺は

うちでこの体制の時代によくあったのは、本番サーバーにアップしてあるのを弄ってアップしたら
先方もいじっていて先方の変更が消えて、とかその逆があったりとか
げんなりくることが多かったな。あれはひどかったなｗ

今のままで廻っているなら別にいいと思うけどね。
将来的に困ると思うなら、自分の趣味ででもしばらく使ってみた方がいいよ
なれるまでちょっとした手間が増えるので面倒なのと、自分なりに便利さや効率的なやり方を実感していないと
他人に勧めにくい。

84 ：デフォルトの名無しさん：2010/09/14(火) 23:30:18

他人に「素人の遊び」と言われようが、馬鹿だと言われようが
飯食えてるんだったら気にする必要ないと思うけどな

効率的な開発手法ばかり追っててまともに飯食えてない俺だからそう感じるんだろうけど

85 ：デフォルトの名無しさん：2010/09/14(火) 23:35:16

ところで>>58は飯を食えているのだろうかw

86 ：デフォルトの名無しさん：2010/09/14(火) 23:43:21

> 本番サーバーから直接ファイルをダウンロードして、修正し本番サーバーにアップロード、修正した部分を変更中のものにも適用、というようなことをしています。
> 直接本番サーバーで作業するため、稀にエラーやらバグが発生しますが、事後修正で対応でいるようなサイトなので…
> こんな考えだからsubversionの利点を見出せないのでしょうか…

何のために開発サーバー用意してんだ？

87 ：デフォルトの名無しさん：2010/09/15(水) 00:04:38

まずはsambaを使って開発サーバ上のファイルを直接変更する環境にしてからだろう
そもそもこの程度の使い方ならsubversionはオーバースペック
cvsでも充分

88 ：デフォルトの名無しさん：2010/09/15(水) 00:15:46

サーバがLinuxとは書いてないし、sambaのポートが開いていないリモートかもしれない

89 ：デフォルトの名無しさん：2010/09/15(水) 00:34:02

cvsはないわーｗ
どう考えたら、svnはやめてcvsということになるんだ

Windowsを除けば、分散バージョン管理でいいんじゃんという時代になってきてるのに

90 ：デフォルトの名無しさん：2010/09/15(水) 00:41:44

CVSはファイル名の変更や移動、それにディレクトリを管理できないという欠点があるからね。
SVN等の後継システムが登場したのだから、すみやかに引退してもらうのが正解。
RCSは単体テキストファイルの管理に限定すれば便利なツールだから、この先生き残るだろうけど。

91 ：デフォルトの名無しさん：2010/09/15(水) 06:33:37

>>90
> RCSは単体テキストファイルの管理に限定すれば便利なツールだから、この先生き残るだろうけど。

これも、gitやbzrが入っていればそれでいいって話で。

92 ：デフォルトの名無しさん：2010/09/15(水) 06:55:45

最後に残るのはsvnだけどね
他のお遊びscmとは意識レベルが全然違う

93 ：デフォルトの名無しさん：2010/09/15(水) 07:18:54

最後に残るのはlatexだけどね
他のお遊び(ry

94 ：デフォルトの名無しさん：2010/09/15(水) 07:58:40

>>91
確かに、ソースコード管理については(svnやgitがあるから)rcsの出る幕は無いだろね。
ただ、rcsはちょっとしたテキストファイルの来歴管理(たとえばhttpd,confや.bashrc)には
十分だし、ほぼすべてのUNIXマシンでインストールされているし、Windowsにも移植されてる。
だからrcsというプログラムそのものが消え去ることは無いだろう、ってことを言いたかった。

95 ：デフォルトの名無しさん：2010/09/15(水) 08:03:41

ただ残ってるだけで誰も使ってないコマンドってあるよね
そんな生き残りに価値はあるんだろうか

96 ：デフォルトの名無しさん：2010/09/15(水) 08:08:39

cvsの*,vってrcsとの互換ってまだあるんだっけ？

97 ：デフォルトの名無しさん：2010/09/15(水) 10:17:28

>>94
* python とかがない状態でも動く
* リポジトリフォーマットがテキストなので、復旧だけなら他のコマンドを使ってもできる
ってあたりが、システムファイルいじる時には安心できるよね。

98 ：デフォルトの名無しさん：2010/09/15(水) 13:16:00

>>99-91
ちょっとスレ違いかもしれないけど、 homeにあるdotfile管理するときってどうしてる？
.bashrcとかあのへんのUnix系の設定ファイル郡のこと。
別ディレクトリに置いてそっちをバージョン管理して、homeにsymlink貼るって形がいいのかな。

homeに直で.gitとか.bzr作ったら、home以下を見に行ってしまってヤバクない？

しかしWindowsだとsymlink貼るのに管理者権限必要なの面倒なのなんとかしろ

99 ：デフォルトの名無しさん：2010/09/15(水) 13:18:13

悪い安価ミスった >>98は >>90-91についてのはなし

100 ：デフォルトの名無しさん：2010/09/15(水) 13:29:16

おいらはホストごとに別ディレクトリでバージョン管理して symlink だなあ。

home に直はちょっと考えられないかな。
home の使い方によるだろうけれど。

Windows では管理してないやw

101 ：デフォルトの名無しさん：2010/09/15(水) 15:10:24

>>98
>>94だけど、遠慮無しに履歴管理したいファイルがあれば、そこに mkdir RCS している。
だから $HOME/RCS, $HOME/bin, $HOME/lib/RCS, /etc/RCS とかRCSだらけに。でも気にしない。
RCSディレクトリがあることで、そこに履歴管理されているファイルが存在していることが分かるから。
探すのも find . -name RCS を実行すれば、一発で分かる。誰にでも勧められる方法じゃないと思うが参考まで。

もちろんこれは個人の開発マシンに限定すべき事柄。もし本番サーバ等でやるなら、事前に承認を受ける。

102 ：デフォルトの名無しさん：2010/09/16(木) 19:41:39

Mercurial使いたいのだが、日本語でコミットログ書くならBazaar一択？
Mercurialならdeps extensionでsvn:externalsっぽいことできるし、資料も豊富で楽なんだけど…

103 ：デフォルトの名無しさん：2010/09/16(木) 19:44:56

>>102
ログは問題ありません。
HGENCODINGでぐぐって下さい。

104 ：デフォルトの名無しさん：2010/09/16(木) 19:47:22

>>103
即レスサンクス！
これでMercurial安心して使えます

105 ：デフォルトの名無しさん：2010/09/16(木) 22:41:58

>>101
素朴なギモンなんだけど、
RCSディレクトリを作るならRCS使い意味は何があるの？
ディレクトリ作るなら、git/とか作ってgit initしてそこにファイル於けばいいわけだし

106 ：デフォルトの名無しさん：2010/09/16(木) 23:45:24

>>105
目的は、単体の設定ファイルやスクリプトを来歴管理したいという、ごく単純なもの。
gitがインストールされたマシン上でgitに慣れた人が同じ事をするのなら、(rcsではなく)gitを
使えばいいのではないかと。ただ、rcsは大半の環境で使える基本ツールだよ、って事を言いたかった。

git(あるいはsvn等の新しいツール)とrcsとは機能差が歴然としているから、単純な優劣での比較は無意味。
csh/tclsh/zshなど高機能なシェルが考案されてきたけど、未だにshが生き残っているのはナゼか考えてみよう。

107 ：デフォルトの名無しさん：2010/09/16(木) 23:46:59

それは、あれだ
もう枯れきってバージョンアップもないだろうから、
10年経っても大丈夫、みたいなもんじゃなかろうか

違うか。ごめん。

108 ：デフォルトの名無しさん：2010/09/17(金) 00:04:42

いや、まったくそのとおりだよ。
sh/awk/make/cc/yaccと同様に、UNIXが消え去らない限りrcsの知識は無駄にはならない、という意味で。
gitやsvnは(cvsがそうであったように)、さらに新しいツールが登場することで引退の道を歩むかもしれないけど。

109 ：デフォルトの名無しさん：2010/09/17(金) 00:21:31

vssは？

110 ：デフォルトの名無しさん：2010/09/17(金) 00:54:27

>>98
ぶっぱなす。ｗ

最近は、/etc/httpdとかも直にsvn管理
しちゃってる。
別に問題ないだろ。

111 ：デフォルトの名無しさん：2010/09/17(金) 01:12:58

bashやzshの次がでたらそのうちとってかわられるかもしれないけど、shはそういう気がしないな
変わらないことが利点か

LinuxはシステムでPythonの利用が増えてきたけどそういう意味では不安だなｗ

112 ：デフォルトの名無しさん：2010/09/17(金) 02:56:23

shはシェルスクリプトインタプリタとして必要だからね。

PythonはPerlのカウンターパートとして出てきているから、そういう意味では不安が増えているわけ
ではないんだけどね。
それにPythonは複数の別バージョンをインストールしておくのも楽だから。

…とはいっても、Python3の利用が進んできたらいろいろ面倒はありそうだなw

113 ：デフォルトの名無しさん：2010/09/17(金) 06:03:37

ああ、そっか。PythonはPerlの代わりか納得。
別バージョンの同居が考慮されてるのはいいね！

PerlやRubyはどうだっけか

Rubyは1.8と1.9の切り替えにRVMとか別途必要だった気もする

114 ：デフォルトの名無しさん：2010/09/17(金) 06:32:25

perl早く無くなってくれないかな

115 ：デフォルトの名無しさん：2010/09/17(金) 07:08:24

インデントきもいとか言って python 勉強してなかったつけがまわってきたぜ。

etc は .svn とかあると気持ちわるいんだよなぁ・・・
別の場所で編集して export でいいんだろうけど。

116 ：デフォルトの名無しさん：2010/09/17(金) 08:05:43

PythonとPerlはLinux Standard Baseに入って殆どのLinuxでデフォルトでインストールされてるからな。

117 ：デフォルトの名無しさん：2010/09/17(金) 08:23:25

annacondaがpythonだからpythonが無いとインストールができない

118 ：デフォルトの名無しさん：2010/09/18(土) 00:48:45

トータル40GBのバイナリデータをストレスなく扱えるものはありますか？
PERFORCEなら問題ないんだけど、結構高いので。

119 ：デフォルトの名無しさん：2010/09/18(土) 07:30:41

>>118
トータルサイズより、個別のファイルがどのくらいのサイズなのかのほうが重要に思う。
勝手な推論だけど、gitは向かないと思う。なぜならgitはファイルが更新(コミット)されるたびに、内部的に別ファイルとして保存するので、
たとえば1GBのデータをちょこっとだけ変更して保存すると、新しく1GBのファイルを作成して保存するから。
（packすればいいかもしれないけど、どのくらい効果があるか知らない）

120 ：デフォルトの名無しさん：2010/09/18(土) 08:21:30

>>119
え？
git はパッチ、つーか、diffを保存するんじゃないの？

121 ：デフォルトの名無しさん：2010/09/18(土) 08:32:24

バイナリでそれをやるのはsvnだけじゃね？
gitはとりあえず富豪的ってイメージ

122 ：デフォルトの名無しさん：2010/09/18(土) 08:58:49

あ、そか。
バイナリの話か…。
って、svnってそれやるの？w
…だから、あんなクソ重いのかw

123 ：デフォルトの名無しさん：2010/09/18(土) 10:21:36

>>120
gitは丸コピーって聞いたよ

124 ：デフォルトの名無しさん：2010/09/18(土) 10:23:21

>>122
遅いのはリポジトリ圧縮するからじゃないのかな？

125 ：デフォルトの名無しさん：2010/09/18(土) 17:37:20

http://hibari.2ch.net/test/read.cgi/prog/1284212440/149

126 ：デフォルトの名無しさん：2010/09/19(日) 03:30:56

>>119
動画みたいなファイルでも、repackすればかなり小さくなるよ
（もちろん、差分的な更新履歴であることが条件だけど）
ヘタすると元のファイルより小さくなる場合もあるけど、あんまり大きなファイルだと
repackの時にメモリが足りなくなってしまう場合があった。

ただ、毎回repackするのはかったるいし、オブジェクト化する時の圧縮や
repackする時の差分抽出にかなりのCPUパワーとメモリを必要とするので、
動画とかの巨大なバイナリファイルが沢山だったりすると、やっぱ厳しいと思う、、、
超富豪スペックなマシンだとけっこういけたりするんだろうか？

まあ１ファイル数ギガもあったりしたらそんなもんでしょ、という気もするんだけど
PERFORCEがそういうのでもサクサク分散できるんだとしたら、すごいなと思う。

127 ：デフォルトの名無しさん：2010/09/20(月) 00:23:14

つか、gitになれたら、cvsとかsvnは使えない…

128 ：デフォルトの名無しさん：2010/09/21(火) 19:44:37

gitは使いこなせてるとは言えんが、ファイル名をリネームしまくっても
何事もなく追随してくれるのが便利すぎる

129 ：デフォルトの名無しさん：2010/09/21(火) 23:19:32

gitはリネームできてもコピーが出来なかった気が

130 ：デフォルトの名無しさん：2010/09/21(火) 23:45:41

gitはかゆいところに手が届く感じの機能がいいな。
git add -p　とか、 git rebase -i とか

131 ：デフォルトの名無しさん：2010/09/21(火) 23:54:45

gitはファイル名の変更を追跡しない。検出してるだけ。
だから遅いし、変更とファイル名の変更を同時に実行すると検出に失敗する。
hgはファイル名の変更をメタデータとして残すので、やはりannotateとかするのが遅いけど、
コピーにも同じ方式で対応できる。
bzrはファイルにIDを振っているので、annotateとかは速いし、ファイル名変更後に行った修正だけを
cherrypickとかできるけど、copyはまだ実装されていない。

132 ：デフォルトの名無しさん：2010/09/22(水) 00:09:13

gitはリネーム用のコマンドは実質、削除と追加をしてるだけだけど、
ログ見るときに追跡ができるというところがミソだな。
コピーも追跡してくれればいいのにね

133 ：デフォルトの名無しさん：2010/09/22(水) 00:10:23

>>131
> だから遅いし、変更とファイル名の変更を同時に実行すると検出に失敗する。

メタデータがないとこの問題あるのか

134 ：デフォルトの名無しさん：2010/09/22(水) 07:47:08

>>131
とても役に立つことを聞いた。

135 ：デフォルトの名無しさん：2010/09/22(水) 08:32:31

ファイル名とディレクトリ構成の変更をしょっちゅうやるからsvnから離れられない

136 ：デフォルトの名無しさん：2010/09/22(水) 13:48:06

ファイル名を変えたらファイルの中身も1行ぐらいは書き換えないといけないことがほとんどと思うんだが、
実用上大丈夫なのかな……

137 ：デフォルトの名無しさん：2010/09/22(水) 13:55:31

>>136
そういう場合は、2回に分けてコミットすると良い。
例えば、javaでパッケージ構成を変更したときなんかは、先にディレクトリ構成を変更してコミットし、次にpackage宣言を
修正してコミットする。

138 ：デフォルトの名無しさん：2010/09/22(水) 14:18:14

ディレクトリ構成を変更したタイミングで
チェックアウトしたらビルドできないのかあ

139 ：デフォルトの名無しさん：2010/09/22(水) 14:38:42

>>137
その場合、変更要因は１つだけどコミットは２度発生するよね。
変更要因とコミット操作の関係を管理したかったら、タグとか使うしか無いのかな。

140 ：デフォルトの名無しさん：2010/09/22(水) 15:46:34

>>137
ディリクトリ、ファイル名の変更と#includeの変更はまとめて一回のコミットでやってるけど、分けてやる理由ってなんだろう。

141 ：デフォルトの名無しさん：2010/09/22(水) 17:38:41

>>140
つ>>133

142 ：デフォルトの名無しさん：2010/09/22(水) 17:45:28

分けてやると、ビルド通らないリビジョンができるじゃん？それはいいの？

143 ：デフォルトの名無しさん：2010/09/22(水) 18:14:54

git固有の話みたいだけど、分散型の場合、まとめてpull/pushするからコミットの粒度も絡んだ運用の話なんじゃない？

144 ：デフォルトの名無しさん：2010/09/22(水) 18:42:54

>>131
ここまでリネーム・コピーの扱いが違うと
git/hg/bzrをsvnクライアントとして使った時に何かと厄介になりそう

145 ：デフォルトの名無しさん：2010/09/22(水) 18:47:00

話についていけない漏れは、svnを使い続けることに決めたw

146 ：デフォルトの名無しさん：2010/09/22(水) 21:58:53

>>131
変更とファイル名の変更を同時に実行すると検出に失敗するって言っても
そりゃ原形を留めてないほど変更したときの話じゃね？

かなり書き換えてかつリネームしたとき、create になるかと思ったら
rename foo/{bar.js => baz.js} (70%)
みたいに表示されてるし

147 ：デフォルトの名無しさん：2010/09/22(水) 22:13:26

>>131
> hgはファイル名の変更をメタデータとして残すので、やはりannotateとかするのが遅いけど、
> コピーにも同じ方式で対応できる。

どこかのバージョンで挙動が変わった気がしたんで見てみたら1.5からだった
http://mercurial.selenic.com/wiki/UpgradeNotes#A1.5:_Small_behavior_changes
> 1.5: Small behavior changes
> hg annotate now follows copies and renames by default, use --no-follow for old behavior

148 ：デフォルトの名無しさん：2010/09/22(水) 22:35:58

なんかここ最近になって一気に有用な話になってる気がするのは俺だけ？

149 ：デフォルトの名無しさん：2010/09/22(水) 22:36:25

>>145
食わず嫌いしないで、試してみなよ。
gitはベターsvnでもあるんだぜ？

150 ：デフォルトの名無しさん：2010/09/22(水) 22:48:22

βsvnなんぞイラン

151 ：デフォルトの名無しさん：2010/09/22(水) 23:26:40

ベターsvnはTeam Foundation Serverなんじゃない？

http://sourceforge.jp/magazine/10/09/09/0717220
>Subversionと互換性のある独自のバージョン管理システム「Team Foundation Server」を提供している。

152 ：デフォルトの名無しさん：2010/09/22(水) 23:31:20

わかった、言い方が悪かったよw

gitはベターなSubversionクライアントでもある。

で、いいか？w

153 ：デフォルトの名無しさん：2010/09/22(水) 23:35:14

>>146
原形を留めてないほど変更した場合のことを考えると、ファイルの移動って何？
みたいになるよね。Gitのやり方は利にかなってると思う。

154 ：デフォルトの名無しさん：2010/09/22(水) 23:44:17

>>152
TortoiseGitがTortoiseSVNと同じくらいにならないと説得力が無いと思うがな

155 ：デフォルトの名無しさん：2010/09/23(木) 05:30:46

>154
Subversion 使いがみんな TortoiseSVN 使ってるわけでもなし、コマンドラインなら
git-svn は普通に便利だよ。

156 ：デフォルトの名無しさん：2010/09/23(木) 09:18:28

じゃあこうだな

少なくともCUIでの利用に限定すれば、gitはベターなSubversionクライアントでもある。

157 ：デフォルトの名無しさん：2010/09/23(木) 09:29:24

だが、いまだ濁点付き日本語ファイル名に対応してないという
(Macだけ？)

158 ：デフォルトの名無しさん：2010/09/23(木) 10:00:16

>>157
kwsk

159 ：デフォルトの名無しさん：2010/09/23(木) 10:08:33

MacはNFDだから濁点の扱いがWinやLinuxと異なるってだけじゃなくて？

160 ：デフォルトの名無しさん：2010/09/23(木) 14:32:30

gitはLinuxのことしか考えてないから仕方ないよ。
ファイル名=バイト列なんてのは、ファイルシステムによっては成立しないダメダメな前提なんだけど
そもそも環境変数LANGでファイル名の解釈が変わったりするLinuxでは必要な前提だしね。

だがMercurial、てめーは駄目だ。

161 ：デフォルトの名無しさん：2010/09/23(木) 14:58:44

>>160
> そもそも環境変数LANGでファイル名の解釈が変わったりするLinuxでは必要な前提だしね。
kwsk

162 ：デフォルトの名無しさん：2010/09/23(木) 15:14:21

>>161
いや、NTFSやHFS+ならファイル名が格納されるときの文字コードは決まってるけどさ、
extとかのファイル名はメタデータも何も無い単なるバイト列じゃん。
それを文字コードとして解釈するかはLANG次第で、ja_JP.UTF-8からja_JP.EUCに変えたりすると化けるじゃん。

163 ：デフォルトの名無しさん：2010/09/23(木) 15:20:40

>>162
http://hibari.2ch.net/test/read.cgi/tech/1093251312/239-

164 ：デフォルトの名無しさん：2010/09/23(木) 15:35:39

>>163
読んだが、いくつかの流派が不毛な言い合いをしてるだけだろ。
どの流儀でも統一さえ取れていればある意味問題ないとも言えるんだし
163が何派なのかも書いてくれんと、そもそも何を言いたいのかもわからんよ。

165 ：デフォルトの名無しさん：2010/09/23(木) 15:45:00

WindowsのBazaar入れてみたら、Bazaarエクスプローラーは結構いいな。
ウィザード風に次何やるのってのを教えてくれる。
すでにわかっている人にはいらないんだろうけど、ドキュメント読んで使い始めようという時に敷居下がる

どうでもいいが、gitはログ見るのがgitkが一番便利なのはなんとかならんのかｗ
履歴と一緒にdiffも見られるのはいいね

git commit -vやTortoiseHgのコミットするときにdiffが見られるのもかなり便利だわ

ほぼ作り直してるんだろうけど、TortoiseSVN以降使いにくい部分もあれば
使いやすくなっている部分もあるよ。

166 ：デフォルトの名無しさん：2010/09/23(木) 15:47:31

>>159
Macユーザーの書き込みは濁点が離れてるからすぐわかるってやつか

が → か゛

になるようなやつ

167 ：デフォルトの名無しさん：2010/09/23(木) 16:29:01

>>166
それはデマだ。Unicode上でNFDだろうがNFCだろうが、2chはSHIFT-JISだから区別のしようがない。
あと合成文字と「単独の文字として存在している濁点」には何の関係もない。

168 ：デフォルトの名無しさん：2010/09/23(木) 17:33:42

>>164
http://hibari.2ch.net/test/read.cgi/tech/1278923059/12
> ・「wchar_tは>849の嫁。>849の許可無くしてUTF16だの32だの無理矢理突っ込むのは許さん。」
> ・電子演算機では文字化けなんて飾りです。UTF-8/UTF16の人にはそれがわからんのですよ。

169 ：デフォルトの名無しさん：2010/09/23(木) 18:41:26

Macユーザーの書き込みは、
「ば~か」
などを見るとすぐに分かる。

170 ：デフォルトの名無しさん：2010/09/23(木) 18:57:39

どれ。ちょっと書いてみるか。>>169のば～か

171 ：デフォルトの名無しさん：2010/09/23(木) 19:02:36

>>169
ば~か

172 ：デフォルトの名無しさん：2010/09/23(木) 19:06:38

>>169のば～か

バックスラッシュがyenマークになるってのならよくあるが

173 ：デフォルトの名無しさん：2010/09/23(木) 19:09:21

>>169
ば～か

174 ：デフォルトの名無しさん：2010/09/23(木) 19:10:09

よし、漏れも便乗w

>>169
ば～か

175 ：デフォルトの名無しさん：2010/09/23(木) 19:12:46

>>169
%E3%81%B0%EF%BD%9E%E3%81%8B

176 ：デフォルトの名無しさん：2010/09/23(木) 19:59:13

>>169
ば〜か

177 ：デフォルトの名無しさん：2010/09/23(木) 21:25:39

なんだこの大人気

178 ：デフォルトの名無しさん：2010/09/23(木) 21:49:26

暴釣りだね。でも、漏れはそこまで自虐的になれないw

179 ：デフォルトの名無しさん：2010/09/23(木) 21:52:47

ぼうつり

180 ：デフォルトの名無しさん：2010/09/23(木) 22:17:06

>>178
ば～か

181 ：デフォルトの名無しさん：2010/09/24(金) 00:13:53

Macから書き込み。

がぎぐげご。

そうならんぞ。

182 ：デフォルトの名無しさん：2010/09/24(金) 01:47:25

>>181
ば〜か
ば～か

183 ：デフォルトの名無しさん：2010/09/24(金) 01:51:57

>>177
「おとなげ」って読みたくなってきた

184 ：デフォルトの名無しさん：2010/09/24(金) 02:02:42

>>169のせいでスレの空気が一気に低レベルに....

185 ：デフォルトの名無しさん：2010/09/24(金) 02:17:22

>>184
スレのレベルは初めから低かった

186 ：166：2010/09/24(金) 02:18:32

むしろ俺のせいな気がしてならない・・・

187 ：デフォルトの名無しさん：2010/09/24(金) 02:22:55

>>186
若干自意識過剰だな

188 ：デフォルトの名無しさん：2010/09/24(金) 03:01:15

何子のスレ

189 ：デフォルトの名無しさん：2010/09/24(金) 03:39:00

>>167
クライアントによっては「が→か゛」になるよ。
Shift_JIS に変換するのはクライアントなわけだから、NFD への対応が甘ければ化ける。

190 ：デフォルトの名無しさん：2010/09/24(金) 03:45:32

数%にも満たない糞マカーのお陰で、確実に無駄な工数が増えてIT産業の粗利が減ってるわけだ

191 ：デフォルトの名無しさん：2010/09/24(金) 07:33:07

>>189
クライアントソフトの性ならmacに限った話にならないだろ

192 ：デフォルトの名無しさん：2010/09/24(金) 07:44:47

>>191
ば〜か
ば～か

193 ：デフォルトの名無しさん：2010/09/24(金) 07:51:40

>>190
それは、最初に世界中の文字が2バイトに収まると思った馬鹿に言えよ……

194 ：デフォルトの名無しさん：2010/09/24(金) 08:00:35

>>193
UTF-16が馬鹿だと認めたのですね

195 ：デフォルトの名無しさん：2010/09/24(金) 08:21:56

Unicodeの、誰もが無視すべき最悪の馬鹿仕様部分を愚直に実装した愚mac

196 ：デフォルトの名無しさん：2010/09/24(金) 08:28:11

いやほんとにば～かだと思うよ。
ただ現在進行形でNFDにしかない文字にNFCが追加されている部分もあるので、無視すべきとは思わんな。

UTF-16のためにサロゲートペア領域もぽっかり穴が開いてしまってるわけだし、
最初から4バイト使うつもりでいれば合成文字もサロゲートも無かったはずなのに……

197 ：デフォルトの名無しさん：2010/09/24(金) 08:35:41

突っ込んだ文字コードの話はよそでやってください

198 ：デフォルトの名無しさん：2010/09/24(金) 08:45:48

>>197
つ>>160

199 ：デフォルトの名無しさん：2010/09/24(金) 10:51:45

>>160の流れだと言いたいんだろうが、>>196は単にUnicodeの話でしかない。

200 ：デフォルトの名無しさん：2010/09/24(金) 12:10:24

>>199
このスレの管理人を気取るのはいいが、それなら>>196ではなく、
文字コードの話にかこつけて「煽り」をカキコした>>169と
それに釣られた>>170以降のカキコを責めるべきだろ。
今さらノコノコ出勤して、どれだけ無駄な時間が過ぎたと思ってんだ。
管理人なら管理人らしく、仕事をサボってんじゃねえよ。

201 ：デフォルトの名無しさん：2010/09/24(金) 12:36:01

○○くんもやってるからぼくはわるくないもん！

202 ：デフォルトの名無しさん：2010/09/24(金) 12:41:07

UTF-16信者が>>160のような無知・誤解を広めるのはいい迷惑

203 ：デフォルトの名無しさん：2010/09/24(金) 12:45:33

ユニコードって完璧だもんね☆

204 ：デフォルトの名無しさん：2010/09/24(金) 13:01:02

>>169の7Ehの話一切なし

205 ：デフォルトの名無しさん：2010/09/24(金) 15:44:13

>>202
なんでUTF-16信者だと思うんだ？

206 ：デフォルトの名無しさん：2010/09/24(金) 17:29:29

TortoiseSVNを半年ぶりに最新版にしたら、インストールしてもTortoiseのメニューが出てこねー。
でも、スタートメニューからは起動する。
古いの探す旅に出るか。

207 ：デフォルトの名無しさん：2010/09/24(金) 17:51:54

Windows再起動しろ

208 ：デフォルトの名無しさん：2010/09/24(金) 17:54:12

修復インストールしろ

209 ：デフォルトの名無しさん：2010/09/24(金) 18:02:35

ちゃんと64bit版svn入れろや

210 ：デフォルトの名無しさん：2010/09/24(金) 18:06:30

>>208が正解
他はゴミレスなんでスルーで

211 ：デフォルトの名無しさん：2010/09/24(金) 18:20:46

うまく入った。
最終的に、アンインストール→ccleanでレジストリ掃除。
再起動後にインストール→失敗。

あれっ？
取りあえずMicrosoftSecurityEssencialを止めてインストール→成功。
という流れで入った。

お騒がせしました。

212 ：デフォルトの名無しさん：2010/09/28(火) 09:44:09

コンパイルしてできたバイナリってバージョン管理するものなの？

213 ：デフォルトの名無しさん：2010/09/28(火) 09:47:08

前スレでやってLaTeXはその延長

214 ：デフォルトの名無しさん：2010/09/28(火) 12:20:40

>>212
ソースがあればバイナリできるんだからバージョン管理の必要は無い。
だけど、リリースとかの区切りでコミットしておくとビルドしなくてもバイナリを取り出したり比較できたりして便利。

215 ：デフォルトの名無しさん：2010/09/28(火) 18:36:39

>>214
毎回コミットしてたぜ。TortoiseSVN使ってるとオーバーレイアイコンが気になって気になって…

216 ：デフォルトの名無しさん：2010/09/28(火) 18:49:31

タイムスタンプだけ違う内容の同じファイルが大量にできるのが嫌だなぁ。

217 ：デフォルトの名無しさん：2010/09/28(火) 20:53:58

>>215
svnignore 設定するんじゃ駄目？

218 ：デフォルトの名無しさん：2010/09/28(火) 22:48:05

オーバーレイアイコンが気になるだけの話ならば、無視ファイルに突っ込めばいいと思うよ

219 ：デフォルトの名無しさん：2010/09/29(水) 06:46:46

タイムスタンプだけ違う内容の同じファイルはできないだろ？

220 ：デフォルトの名無しさん：2010/09/29(水) 07:09:46

できる

221 ：デフォルトの名無しさん：2010/09/29(水) 12:26:36

>>215
tortoiseSVNなら、変更リストがある。

コミットダイアログで変更されたファイル右クリック→変更リストへ移動→ignore-on-commitとすると、変更リストができる。
変更リストのファイルは変更されていてもコミットのチェックが自動ではつかなくなる。これでコミットを抑制できる。
変更リストはリポジトリには影響しないからローカルで指定できる。

222 ：デフォルトの名無しさん：2010/09/29(水) 12:35:21

>>220
タイムスタンプが違っただけでコミットされたら困るだろう。

223 ：デフォルトの名無しさん：2010/09/30(木) 23:05:27

実行モジュールは納品とかバージョンの単位でコミットする運用だった。
今は Redmine 上に乗せる運用にかわったけど。

224 ：デフォルトの名無しさん：2010/10/03(日) 16:14:56

うちもお客さんの所に納めるものはコミットしてる。

ソースがあればバイナリできると言うけど、バイナリにコンパイルした
日時を埋め込んだりされるのでソースは同じでもバイナリは完全に一致
しないことがあるから。

225 ：デフォルトの名無しさん：2010/10/03(日) 21:30:46

そこらへんはHudsonにまかせる運用にしたな。

226 ：デフォルトの名無しさん：2010/10/04(月) 01:01:08

あぁ、ハチのマークの

227 ：デフォルトの名無しさん：2010/10/04(月) 05:29:39

何でバージョン管理システムってユニコードに憎悪を持ってるの？

228 ：デフォルトの名無しさん：2010/10/04(月) 06:37:10

>>227
なんか妄想激しくないか？

229 ：デフォルトの名無しさん：2010/10/04(月) 08:03:59

>>227
このスレに話を理解できない・ついていけない人が大勢いるのは事実

230 ：デフォルトの名無しさん：2010/10/08(金) 11:25:19

diff Europe USA
http://pds.exblog.jp/pds/1/200710/20/99/b0117999_5491615.jpg

231 ：デフォルトの名無しさん：2010/10/09(土) 00:53:30

>>230
全く1byte文字圏の連中はセクシーがなんたるかを分かってないな。
2byte文字に対応した画像を貼ってください

232 ：デフォルトの名無しさん：2010/10/09(土) 01:14:47

>>231
2bytes圏に美人が多いのは認める。
しかし3bytesを無視するのは許さん。

233 ：デフォルトの名無しさん：2010/10/20(水) 06:01:56

SubversionからGitへ乗り換えを検討してみたけど
導入の手間（特に利用者への負担）と管理の煩雑さを考えると
現状維持がいいのかなと思ってしまった

234 ：デフォルトの名無しさん：2010/10/20(水) 07:28:24

管理ウゼェ勝手にしろがgitだから、管理したいならgitなんて考慮に値しない選択肢だよ

235 ：デフォルトの名無しさん：2010/10/20(水) 07:38:27

利用者がrebaseとかresetとか覚え始めて
ログが破綻するのがsvn->gitの本当の最初の試練

236 ：デフォルトの名無しさん：2010/10/20(水) 08:34:17

>>233
乗り換えらくちんちん

237 ：デフォルトの名無しさん：2010/10/20(水) 08:55:50

>>234
バックアップ取っていたつもりが取れていなくて全てパーになるのですね。わかります。

238 ：デフォルトの名無しさん：2010/10/20(水) 09:13:09

某るｂｙみたくsvn鯖まるごとクラックされたりとか

239 ：デフォルトの名無しさん：2010/10/20(水) 10:32:51

>>233
導入の手間はサーバが無いと何もできないSubversionの方がはるかに手間がかかる

240 ：デフォルトの名無しさん：2010/10/20(水) 13:59:00

Subversion って sshd だけ動いてれば大丈夫っしょ

241 ：デフォルトの名無しさん：2010/10/20(水) 14:27:30

導入の手間（特に利用者への負担）ってのが読めないのかこの馬鹿は
一体どれだけ狭い世界に生きてんだよ

242 ：デフォルトの名無しさん：2010/10/20(水) 14:51:25

乗り換えつってんだから、現状Subversionはインストール済みだろうし
手間はゼロだなｗ

243 ：デフォルトの名無しさん：2010/10/20(水) 15:38:11

>導入の手間（特に利用者への負担）
・git svn clone のミラーを立てる
・svnしか使えないお馬鹿さんはsvnを使い続ける
・gitが使える普通の人はgitを使う

244 ：デフォルトの名無しさん：2010/10/20(水) 17:16:54

・かしこいgitユーザーはsvnユーザーに不都合が出ないように注意する
・svnユーザーに不都合が出た時にはかしこいgitユーザーが何とかする

こうなることが予見される訳だが

245 ：デフォルトの名無しさん：2010/10/20(水) 18:15:38

・かしこいgitユーザーを見よう見まねのかしこくないgitユーザーが出現
こうなることが予見される訳だが

246 ：デフォルトの名無しさん：2010/10/20(水) 18:25:22

・かしこくないgitユーザにはpush権をやらない
・練習用のリポジトリを使わせる
・かしこいgitユーザがログを綺麗にしてからpushする

247 ：デフォルトの名無しさん：2010/10/20(水) 18:52:59

Bazaar導入でスッキリ解決

248 ：デフォルトの名無しさん：2010/10/20(水) 18:54:38

VSS導入でスッキリ解決

249 ：デフォルトの名無しさん：2010/10/20(水) 19:31:53

ClearCase導入でスッキリ解決

そして誰もいなくなった

250 ：デフォルトの名無しさん：2010/10/20(水) 20:25:18

>>246
ログを綺麗にする方法について
具体的に教えて頂けませんか？

251 ：デフォルトの名無しさん：2010/10/20(水) 22:32:19

>>250
git push :master

252 ：デフォルトの名無しさん：2010/10/20(水) 22:47:22

>>251
それがあんまり洒落になってないところがgitの扱いづらさ

253 ：デフォルトの名無しさん：2010/10/20(水) 23:13:28

おまいら svn しか使えない馬鹿ものっていうけどな
svn も使えない馬鹿ものも多いんだぞ

254 ：デフォルトの名無しさん：2010/10/21(木) 00:19:16

>>233 >>239
以前、散々開発してた途中でバージョン管理してないプログラマ一人のプロジェクトが見つかって、
何でリポジトリ作ってないんだよって問いただしたら、
管理者じゃないからリポジトリ作れなかったって話を思い出した

Subvrsionだとサーバーないとしかも管理者(リポジトリのね)じゃないとリポジトリ作れないと思ってたらしい
TortoiseSVNですら、ローカルにリポジトリ作れるから一人プロジェクトでもリポジトリ作れるのにな
後からサーバーにうつせばいいし

ま、これは、コミュニケーション不足が主な原因だったわけだが

255 ：デフォルトの名無しさん：2010/10/21(木) 00:23:58

そもそも、自由に履歴をいじれるバージョン管理ソフトって、
やり過ぎ感が否めない
便利なのはわかるけど、結局何がしたいんだろうって

256 ：デフォルトの名無しさん：2010/10/21(木) 01:12:39

・過去の履歴にパスワードなど個人情報が入ってしまっている
・コミットログを間違えたが、管理者かサーバー側でログ修正を許可しないと修正できないので、
　ソースに改行を挿入してもう一度コミットした

こういうのを経験していると、リモートにアップする前に、
ローカルで簡単に修正できるのは便利だよ
ただ、逆に言うと運用でなんとかしてたのを機能として持つことで覚えることが増えたように感じる
もちろん、必要になってから憶えればよいんだけどね

gitだって基本のコマンドが多く見えるけれど、便利な機能(過去のコミットの修正や履歴のツリーの付け替えなど)
を最初はスルーすることで最小限必要な学習でスタートできる。

257 ：デフォルトの名無しさん：2010/10/21(木) 03:20:57

リポジトリにパスワードなんて突っ込むような大馬鹿野郎がgitをありがたがるという事ね
なるほど

258 ：デフォルトの名無しさん：2010/10/21(木) 06:00:28

脳に蛆が湧いた奴がいるな

259 ：デフォルトの名無しさん：2010/10/21(木) 08:34:18

>>253
cvsを使っていてsvnを選ばなかったのなら勝ち組
バージョン管理をしていないのなら分散型で始めれば良い

260 ：デフォルトの名無しさん：2010/10/21(木) 09:05:44

>>254
コミュ不足というよりは、マニュアルくらい
読めよ、て思った。
そいつ自身の自業自得じゃね？

261 ：デフォルトの名無しさん：2010/10/21(木) 09:08:00

とにかく分散すればありがたい、とハードワイアで結合されたニューロンたち。

262 ：デフォルトの名無しさん：2010/10/21(木) 09:16:47

さぁ、早くsvnでcherry-pickとrebaseをする仕事に戻るんだ

263 ：デフォルトの名無しさん：2010/10/21(木) 09:19:09

>>259
じゃあ俺は勝ち組だな。
cvs → hg & bzr
svn は、cvs を徹底的にこき下ろすコミュニティの態度が気に入らなかった。
別に cvs の悪口言うなってんじゃないけど、ほかを叩くことで自分を持ち上げるような
性根は嫌いだ。

264 ：デフォルトの名無しさん：2010/10/21(木) 09:24:00

ruby は、perl/C++ を徹底的にこき下ろすコミュニティの態度が気に入らなかった。
別に perl/C++ の悪口言うなってんじゃないけど、ほかを叩くことで自分を持ち上げるような
性根は嫌いだ。

265 ：デフォルトの名無しさん：2010/10/21(木) 09:27:52

git は、svn を徹底的にこき下ろすコミュニティの態度が気に入らなかった。
別に svn の悪口言うなってんじゃないけど、ほかを叩くことで自分を持ち上げるような
性根は嫌いだ。

266 ：デフォルトの名無しさん：2010/10/21(木) 09:32:39

敗者の被害妄想

267 ：デフォルトの名無しさん：2010/10/21(木) 10:16:25

たしかに勝者は被害妄想しないな。

268 ：デフォルトの名無しさん：2010/10/21(木) 10:26:32

つうか cvs はねえよ
慣れの問題はあるけどさ

269 ：デフォルトの名無しさん：2010/10/21(木) 10:32:18

>>256
svnにしがみつくことに必死な馬鹿にまともにレスしても無駄だから

270 ：デフォルトの名無しさん：2010/10/21(木) 10:33:17

ここ数年で急に分散型が台頭してきたよな。
どれが淘汰されて、どれが生き残るのか、
まだ分からんので必要に迫られない限り様子見してる。
あと数年は分散型が乱立した状況が続くんでないかと思う。

新しいものに飛びついたからって、勝った事にはならん。
むしろ、飛びついた先の船が沈没しないことを祈りなされ。

271 ：デフォルトの名無しさん：2010/10/21(木) 10:38:09

gitは沈没しなさそう

272 ：デフォルトの名無しさん：2010/10/21(木) 11:05:12

cvs -> svn -> svk -> git ときた俺だけど、理想過ぎてもうGit無しでは生きていけない

273 ：デフォルトの名無しさん：2010/10/21(木) 11:06:16

沈没してもfast-exportで別のVCSに移行できる
svnにしがみついているのは、ブランチが複雑だったり、copyでブランチを作っていなかったりして、
移行もままならないプロジェクト

274 ：デフォルトの名無しさん：2010/10/21(木) 12:07:21

git → linuxが捨てなければ大丈夫
bzr → GNUが捨てなければ大丈夫
hg → microsoftが捨てなければ大丈夫

275 ：デフォルトの名無しさん：2010/10/21(木) 12:19:59

一番怪しいのはhgか

276 ：デフォルトの名無しさん：2010/10/21(木) 12:57:35

Oracleもいるよ? いる…よ？

277 ：デフォルトの名無しさん：2010/10/21(木) 13:44:05

Microsoftはhgラブだったのか

278 ：デフォルトの名無しさん：2010/10/21(木) 13:45:58

svnラブでしょ >>151

279 ：デフォルトの名無しさん：2010/10/21(木) 13:54:52

>>151の記事って表題が
＞米Microsoft、バージョン管理システムMercurial開発プロジェクトに25,000ドル寄贈

280 ：デフォルトの名無しさん：2010/10/21(木) 14:42:47

Mercurialが一番、どこの陣営の色も付いてないから？

281 ：デフォルトの名無しさん：2010/10/21(木) 15:44:00

>>280
実装が一番楽だからじゃないか

282 ：デフォルトの名無しさん：2010/10/21(木) 16:56:58

たった250万円かよ・・・。

283 ：デフォルトの名無しさん：2010/10/21(木) 16:59:51

その頃1ドル85円ぐらいじゃなかったっけ

284 ：デフォルトの名無しさん：2010/10/21(木) 17:06:06

一番必死で一番性格が悪いのがGit陣営だと良く分かった

285 ：デフォルトの名無しさん：2010/10/21(木) 20:56:24

>>280
mercurialはsun色じゃなかったんだ？

286 ：デフォルトの名無しさん：2010/10/21(木) 21:58:47

https://git.wiki.kernel.org/index.php/GitProjects
http://mercurial.selenic.com/wiki/ProjectsUsingMercurial
http://wiki.bazaar.canonical.com/WhoUsesBzr

287 ：デフォルトの名無しさん：2010/10/21(木) 23:23:18

gitでもhgでもbzrでもいいけど分散型に慣れたあとsvnを触るとコミットするのがすごく怖く感じる

288 ：デフォルトの名無しさん：2010/10/22(金) 00:40:41

brancheにCommitする習慣が必要あるね

289 ：デフォルトの名無しさん：2010/10/22(金) 05:49:57

>>274
Googleもhgじゃね？

290 ：デフォルトの名無しさん：2010/10/22(金) 06:35:58

>>289
http://hibari.2ch.net/test/read.cgi/tech/1284467898/84

291 ：デフォルトの名無しさん：2010/10/22(金) 06:41:21

ﾊｹﾞﾊｹﾞうるせー

292 ：デフォルトの名無しさん：2010/10/22(金) 07:34:56

散々、gitの開発者は日本人だ日本人だと煽っておいて、gitの日本人コミッタって在米かよ。
米国でノーベル賞とった日本人研究者を喜んでる日本人みたいじゃねーか。

それにしても、せっかくGoogle社員なのにもったいないね。
GoogleはWindowsの親和性からhg押してるという状況が。

むろんコミッタには罪はないんだが。

293 ：デフォルトの名無しさん：2010/10/22(金) 07:35:45

bzr は、hg や git の日本語対応を徹底的にこき下ろす2chコミュニティの態度が気に入らなかった。
別に hg や git の悪口言うなってんじゃないけど、ほかを叩くことでbzrを持ち上げるような
性根は嫌いだ。

294 ：デフォルトの名無しさん：2010/10/22(金) 08:16:49

googleはpythonだからね。
git push :masterがそうだけど、これが大きな要因だと思う。

http://www.atmarkit.co.jp/news/200904/28/googlecode.html
> ・メンテナンス性。Gitはgit-gcなど、レポジトリの定期的なメンテナンスが不可欠。
> ・ヒストリの重要性。Gitは非常に強力で、コマンドを叩けばあらゆる操作が可能。
> 　リモートサーバ上のレポジトリもコマンド1つで消えてしまう可能性があり危険。
> 　一方、Mercurialは変更不可のオブジェクトが蓄積していくだけ。

295 ：デフォルトの名無しさん：2010/10/22(金) 09:57:07

>>294
その二つは同じことを言ってるだけだよな
gitでgcをoffにしたら解決する話のような

296 ：デフォルトの名無しさん：2010/10/22(金) 10:36:09

>>292-293
そんなことでバージョン管理システム決めるなよｗｗ

個人で、日本語ファイル名を複数の環境で扱わないならどれ使っても良い。
チームで、しかも日本語ファイル名を複数の環境で扱うならbzrが安心。
チームで、みんなにcygwinやmsysをインストールさせるのがいやだったらgitが
選択肢から外れる。

今から個人のバージョン管理するなら、プライベートリポジトリの制限なくなった
BitBucketが使えるhgが良いんじゃないかな。CodePlexもGoogle Codeでも使えるし。

297 ：デフォルトの名無しさん：2010/10/22(金) 10:42:17

>>296
UTF-16が安心？

298 ：デフォルトの名無しさん：2010/10/22(金) 10:51:07

gitはコミッタが日本人だから安心とか言ってるBlogあったけど
彼って多言語対応に一切興味を示さないよね

299 ：デフォルトの名無しさん：2010/10/22(金) 11:22:23

自分が必要してないのに泥沼確定してる多言語対応に手を出したくない
気持ちはわからなくもない

300 ：デフォルトの名無しさん：2010/10/22(金) 12:21:04

元々Gitにかかわろうと思った動機も　コード1200行しかなくて簡単そうだったから　だもんな
面倒な問題の解決については一切期待できない人物

301 ：デフォルトの名無しさん：2010/10/22(金) 13:18:30

>>296
>チームで、みんなにcygwinやmsysをインストールさせるのがいやだったらgitが
>選択肢から外れる。

それは誤解

302 ：デフォルトの名無しさん：2010/10/22(金) 13:40:05

ファイル名にUTF-8が使えるのが多言語対応じゃないのですか？

303 ：デフォルトの名無しさん：2010/10/22(金) 13:50:53

ファイル名にUTF-8が使えるのは多言語化の現実的な実装法の一つだがイコールではない

304 ：デフォルトの名無しさん：2010/10/22(金) 13:55:03

ファイル名をUCSにするのは多言語化の現実的な実装法の一つだがイコールではない

305 ：デフォルトの名無しさん：2010/10/22(金) 13:58:08

svnかhgのどちらでもいいのですが（あれば両方とも）
指定した２つのリビジョン間の差分ファイルのみを
ローカルにコピーする機能ってありませんか？

306 ：デフォルトの名無しさん：2010/10/22(金) 13:59:29

差分ファイルってのは断片ではなく、ソースファイル丸ごとという意味です。

307 ：デフォルトの名無しさん：2010/10/22(金) 14:45:15

>>301
msysやcygwinに依存しないWindows用gitってあるの？

308 ：デフォルトの名無しさん：2010/10/22(金) 15:08:01

っていうか、依存しちゃうとマズイことあるの？
push/pollなどのプロトコルさえ通じれば、実装はなんでもいいのでは？
（おれはどのくらいmsys/cygwinがソレに依存しているか詳しくないのだけど）

309 ：デフォルトの名無しさん：2010/10/22(金) 15:26:12

微妙に名前の違う同じ名前のexeがいくつもあると容易に嫌なことが起きやすいのは
想像できるな

310 ：デフォルトの名無しさん：2010/10/22(金) 15:27:06

http://hibari.2ch.net/test/read.cgi/tech/1284467898/22
> msysGit is not Git for Windows; that is an installer which installs Git -- and only Git.

311 ：デフォルトの名無しさん：2010/10/22(金) 16:04:48

>>308
ファイル沢山入って重い
既存のコマンドと同名で別のコマンドがインストールされる恐れがある。
(Windowsのfindとか)
もともとCygwin/mingw使っている人に新しくmingwかなにかをインストールさせた
場合、環境の切り替えが大変。

>>310
おぉ、gitが入ったmingw環境をインストールさせるのかと思ってた。

312 ：デフォルトの名無しさん：2010/10/22(金) 16:26:02

gitそのものがシェルスクリプトとか使ってるのにどうやってるの？

313 ：デフォルトの名無しさん：2010/10/22(金) 16:35:44

portableGIT使えばいいじゃない

314 ：デフォルトの名無しさん：2010/10/22(金) 16:43:04

>>311
pathが違うから大丈夫
っていうか Git のみインストールすれば
Git 専用の Bash が出来てその中だけで完結出来て
他に悪影響出ないよ

315 ：デフォルトの名無しさん：2010/10/22(金) 16:57:57

>>314
元々msysやcygwin使ってた人からすると、msysやcygwinのbashからgitを呼べないと使い物にならねえ
って言う人がほとんどじゃね？

316 ：デフォルトの名無しさん：2010/10/22(金) 17:04:53

PATH通せばいいだろ

317 ：デフォルトの名無しさん：2010/10/22(金) 17:07:03

msysにしろcygwinにしろ、POSIX APIを.dllで提供してるから
共通のものを使ってくれないとだめだろ
WindowsのPATHだけ通しても、/usr/みたいなPOSIX PATHが別のところになっちゃうぞ

318 ：デフォルトの名無しさん：2010/10/22(金) 17:21:06

gitってまだ外部コマンドに依存しているのが残っているの？

319 ：デフォルトの名無しさん：2010/10/22(金) 17:21:44

WindowsのPATHは通さない

320 ：デフォルトの名無しさん：2010/10/22(金) 19:05:16

GITってlinux（POSIX）依存が抜けないんだよね。
そういう部分で苦労させられると、ハードゲイの方がよく思えてくる。

321 ：デフォルトの名無しさん：2010/10/22(金) 19:11:27

cygwinしかなかった時に比べると進化している。
でも、TortoiseGitは進化するのだろうか？

322 ：デフォルトの名無しさん：2010/10/22(金) 19:28:22

フォーー！

323 ：デフォルトの名無しさん：2010/10/22(金) 22:58:54

>>296
>>263 >>264 >>293

324 ：デフォルトの名無しさん：2010/10/22(金) 23:07:35

>>311
msysGitだとmsys環境だけにパス通したコマンドプロンプト立ち上げる機能ついてきたはず。

VisualStudioでも複数の環境を切り替えて使えるように、一時的にパス通したコマンドプロンプト使えるbatみたいなのついてくるよね
ああいうの

>>312
他のバージョン管理みたいに、libなんたらやらdllで基本的な機能が組み込めると楽なんだけどねー。

TortoiseGitもコマンンドライン版を要求してコマンンドライン版の実装に激しく依存する
文字コードの問題もそう。

325 ：デフォルトの名無しさん：2010/10/22(金) 23:11:56

>>321
TortoiseGitはgitは日本語ファイル名の問題ある、TortoiseGit側にも文字コードの問題ある
二重苦

326 ：デフォルトの名無しさん：2010/10/22(金) 23:17:46

そうなんだ。
GITはファイル名じゃなくて、inodeみたいなidで持ってるんだから、
ファイル名の問題は解決済みなのかと思ってたよ。
そもそも、日本語ファイル名なんか使わないけど。

327 ：デフォルトの名無しさん：2010/10/23(土) 11:57:29

>>300
なにその「濱野は楽したいだけのクソ野郎」みたいな言い草

328 ：デフォルトの名無しさん：2010/10/23(土) 12:25:54

なにもクソも本人談そのままだし
お前がそう感じたならそう言う事なんだろう

329 ：デフォルトの名無しさん：2010/10/23(土) 12:28:33

「面倒な問題」って何ですか？

330 ：デフォルトの名無しさん：2010/10/23(土) 13:40:29

中身見たことないけど1200行とかCのソースとしてはものすごい短いものだから
本気で取り組んだらわからない部分なんてないんじゃないの

331 ：デフォルトの名無しさん：2010/10/23(土) 14:00:33

>>330ほどの馬鹿発言する奴が何故バージョン管理スレに居るのだろう

332 ：デフォルトの名無しさん：2010/10/23(土) 14:09:35

と、1200行のCのソースも理解できない馬鹿が言っています

333 ：デフォルトの名無しさん：2010/10/23(土) 21:38:11

>>330
>>332
こいつは今のGitが1200行で動いてると思ってんのかｗｗｗ

334 ：デフォルトの名無しさん：2010/10/23(土) 21:41:16

何言ってんの。
短い行数でこれだけの機能を実現しているということは
作者にしかわからないトリッキーなコードに決まってるじゃん。

335 ：デフォルトの名無しさん：2010/10/23(土) 21:43:51

1200行で動いてるんなら、マルチバイト対応も、むしろ逆に簡単なんだろうけどな
そういうことではなく、面倒くさいものには触りたくないっていう思想だと思う
非常に正しい思想だとは思う

336 ：デフォルトの名無しさん：2010/10/23(土) 22:10:03

数メガのバイナリファイルが二万くらいあるんだけど、どのバージョン管理システムがお勧めですか？

337 ：デフォルトの名無しさん：2010/10/23(土) 22:24:27

JASRACに管理してもらえ

338 ：デフォルトの名無しさん：2010/10/23(土) 22:36:11

>>334
お前馬鹿すぎ
1200行だかはLinusが一晩ででっち上げたプロト

339 ：デフォルトの名無しさん：2010/10/23(土) 22:59:33

>1200行とかCのソースとしてはものすごい短いものだから
>本気で取り組んだらわからない部分なんてないんじゃないの
>と、1200行のCのソースも理解できない馬鹿が言っています
>短い行数でこれだけの機能を実現しているということは
>作者にしかわからないトリッキーなコードに決まってるじゃん。

恥ずかしい部分抜き出したらほぼ全行だった。
ド素人とかいうレベルの話ではなく、頭の根っこの部分がものすごいお気の毒様な事になっているんだと思う。

340 ：デフォルトの名無しさん：2010/10/24(日) 02:14:49

>>337
ネタじゃなく、真面目な話なんだが…
やっぱりPerforceしかないのか

341 ：デフォルトの名無しさん：2010/10/24(日) 05:10:09

>>335
> 1200行で動いてるんなら、マルチバイト対応も、むしろ逆に簡単なんだろうけどな
マルチバイトって何ですか？

342 ：デフォルトの名無しさん：2010/10/24(日) 05:46:56

>>336
git

343 ：デフォルトの名無しさん：2010/10/24(日) 05:47:56

>>342
酷い奴だな……w

バイナリも差分で保存してくれるのは、svnとbzrだけ、だったっけ？

344 ：デフォルトの名無しさん：2010/10/24(日) 05:58:21

数メガのバイナリを差分で取るの？

345 ：デフォルトの名無しさん：2010/10/24(日) 05:59:20

gitもpackすれば差分になるよ

346 ：デフォルトの名無しさん：2010/10/24(日) 06:06:09

それじゃpackしなければ良いんじゃない？

347 ：デフォルトの名無しさん：2010/10/24(日) 07:05:08

packしなければ速いけどストレージは食うね
バイナリでも差分取れないような更新ばっかりならpackしないようにしたほうが良いかも

348 ：デフォルトの名無しさん：2010/10/24(日) 08:47:20

Mercurialしかない。

349 ：デフォルトの名無しさん：2010/10/24(日) 11:27:56

>>345
ほんとだｗリポジトリ数GB縮んでびっくりしたわｗｗ

350 ：340：2010/10/24(日) 17:00:30

色々情報ありがとうございます！
bzrやgitもバイナリの差分に対応してるんですね。
その為だけにsvn使ってたみたいなもんなんで、ありがたい情報です。

351 ：デフォルトの名無しさん：2010/10/24(日) 18:10:22

Mercurialも差分らしい
8.3.バイナリファイルの取り扱いはどうなっているの？
http://mercurial.selenic.com/wiki/JapaneseFAQ#JapaneseFAQ.2BAC8-TechnicalDetails.A.2BMNAwpDDKMOow1TChMKQw6zBuU9YwimJxMEQwbzBpMEYwajBjMGYwRDCLMG7.2FHw-

バイナリを扱うためのいくつかの拡張がある
http://mercurial.selenic.com/wiki/BfilesExtension

ファイルの中身はいじらないという方針だったのだが、
改行コードを変換するための拡張が本体に取り込まれた。
http://mercurial.selenic.com/wiki/EolExtension

352 ：デフォルトの名無しさん：2010/10/24(日) 21:42:45

>>118, >>340
定期的に Perforce を取り上げるのは営業活動の一環なのか？

353 ：デフォルトの名無しさん：2010/10/24(日) 23:26:55

イントラ内に建てたfreebsd8.1サーバーにsubversionインストールして
ブラウザでhttp://サーバーアドレス/dav/ってするとdav - Revision 0: / って表示される。

クライアントのWin7上にTortoiseSVNもインストールしてあります。
visual studio 2010 proのVC#プロジェクトを管理したいのですが
サーバーに同期（アップロード？コミット？チェックアウト？）させる方法がわかりません。

354 ：デフォルトの名無しさん：2010/10/24(日) 23:38:16

>>353
プロジェクトのディレクトリをエクスプローラーで開いてコンテキストメニューからコミットやアップデートできる。
Visual Studio Professionalならankhsvnとかのプラグイン使った方が楽。

355 ：デフォルトの名無しさん：2010/10/24(日) 23:59:21

個別スレに行け
用語も分からないということは、trunk/branches/tagsも作らずに始めるつもりか？

356 ：デフォルトの名無しさん：2010/10/25(月) 06:03:55

>>355
別にそれで始めたっていいだろが

357 ：353：2010/10/25(月) 07:29:02

用語もわからなくて質問してすいません。

コミット先をでhttp://サーバーアドレス/dav/にしたいのですが

設定がまずいのか現在は、ローカルの
file:///C:/Repositories/dav/trunkになってしまいます。

どうしたら変更できますか？

358 ：デフォルトの名無しさん：2010/10/25(月) 07:33:56

>>357
ここに行け
http://hibari.2ch.net/test/read.cgi/linux/1154701996/

359 ：デフォルトの名無しさん：2010/10/25(月) 13:59:49

バージン管理システムに見えた

360 ：デフォルトの名無しさん：2010/10/27(水) 20:10:38

Gitを統合した「KDevelop 4.1」がリリース
http://sourceforge.jp/magazine/10/10/27/0315212

361 ：デフォルトの名無しさん：2010/10/27(水) 21:41:00

>>359
最近は過去の改竄しまくりで、けしからんな

362 ：デフォルトの名無しさん：2010/10/28(木) 00:43:16

>>361
前彼女の履歴から俺のコミットがロールバックされていた件

363 ：デフォルトの名無しさん：2010/10/28(木) 00:50:29

revertならまだ望みはある

364 ：デフォルトの名無しさん：2010/10/28(木) 12:48:35

別の誰かの記憶にマージされていた

365 ：デフォルトの名無しさん：2010/10/28(木) 14:19:02

お前ら二人とも愛してやる！
fast-forwardだ！

366 ：デフォルトの名無しさん：2010/10/28(木) 15:19:20

VS2010で扱いやすいバー管おしえてください

367 ：デフォルトの名無しさん：2010/10/28(木) 15:47:27

>>366
Mercurial Source Control Plugin for MS Visual Studio
http://visualhg.codeplex.com/

368 ：デフォルトの名無しさん：2010/10/28(木) 15:57:16

>>366
VS2010で扱いやすいのはVSSじゃないかな
使ってる人間が扱いやすいかは別にして

369 ：デフォルトの名無しさん：2010/10/28(木) 16:08:12

>>366
Git Extensions
http://code.google.com/p/gitextensions/
> Git Extensions is a toolkit to make working with Git on Windows more intuitive.
> The shell extension will intergrate in Windows Explorer and presents a context menu
> on files and directories. There is also a Visual Studio plugin to use git from Visual Studio.

TortoiseHgにそっくりのスクリーンがあって、
TortoiseGitよりもこっちの方が良いかも

370 ：デフォルトの名無しさん：2010/10/28(木) 16:50:33

なんで何でもかんでも合体せにゃならんのか。

371 ：デフォルトの名無しさん：2010/10/28(木) 18:36:29

>>367
俺はVisualHGよりは、hgsccの方が好きだな。
でも、両者をチェックしたのは1年以上前だから、今は状況が変わってるかもしれないが。
当時はVisualHGは低機能すぎてイマイチだった。

372 ：デフォルトの名無しさん：2010/10/28(木) 23:56:34

お手軽で普通に使えるので俺はVisualHGのほうがオススメ。

373 ：デフォルトの名無しさん：2010/10/29(金) 01:19:21

>>370
>>366じゃないがIDEやエディタに統合すると便利よ
リアルタイムに変更箇所表示してくれたり、TortoiseXXXみたいにアイコンファイルビューで状態を表示してくれたり

374 ：デフォルトの名無しさん：2010/10/29(金) 01:31:03

>>370が言ってるのは、コマンドをパイプで繋げてお手軽にオレスゲーが出来なくなるのが問題だって事じゃないの

375 ：デフォルトの名無しさん：2010/10/29(金) 03:19:39

>>368
MSはTFSに乗り換えて欲しいようだが

376 ：デフォルトの名無しさん：2010/10/29(金) 08:49:39

>>374
Emacsはデスクトップ環境だそうだが、
GNU EmacsがBazaar、XEmacsがMercurialなんだね。

377 ：デフォルトの名無しさん：2010/11/04(木) 20:10:45

Subversionスレから誘導されて来ました。

Subversion+Hudsonで管理されたプロジェクトに対して、後述のよう
な多段構成の運用をするベストプラクティスは無いでしょうか?

Subversion+Hudsonで管理されたとあるMavenプロジェクトの中の
子プロジェクト(学術分野です)の一つを担当することになりました。
(元締めがSubversion+Hudsonという条件は動かせません)
我々のグループ内でも複数メンバーが共同作業で開発を行います。
そのためメンバー個々人が親プロジェクトのSubversionレポジトリを
直接読み書きするのではなく、グループ内部で内部用のレポジトリを
立てて親レポジトリ上のコードと同期をとり、普段の開発時は内部
レポジトリに対して作業を行い、内部で各テストが終わった段階で
内部レポジトリの更新内容を親レポジトリへと反映する運用を考えて
います。このような場合、

親プロジェクトのSVNレポジトリ <-> 内部レポジトリ+Hudson <-> 各メンバーのマシン

というような運用になるわけですが、このような運用を行う上で良い
構成法などの例は無いでしょうか。

378 ：デフォルトの名無しさん：2010/11/04(木) 20:21:14

>>377
・Subversionのフォルダ単位の分散型のミラーを立てる
・Subversionにpush時に一本道になるように履歴を整える

379 ：デフォルトの名無しさん：2010/11/04(木) 23:03:52

>>377
Mercurialではじめる分散構成管理
第5回　分散による「多段連携」～大規模開発への応用
http://gihyo.jp/dev/feature/01/mercurial/0005?page=1

ここでのマスタリポジトリをSubversionにすれば良い

380 ：デフォルトの名無しさん：2010/11/06(土) 00:31:12

相談なんですが、
現在プログラマーはコードをSubversionで管理してます。
プログラマ以外の共同作業員との間ではバージョン管理ソフトを使っておらず、
最近、

・ファイルの更新したかがわかりづらい、
・コンフリクトというよりどちらかが更新されたファイルを上書きしてしまうことがある
・できれば中央のサーバーがないときも使いたい

といったことがあります。

問題と感じた件のプログラマーはバージョン管理つかおうか、と提案していたようなのですが、
共同作業員側は手元ではファイル名に番号づけて保存していて問題ない、面倒くさい、という理由により、
結局はその作業員との間では、上記問題はだいたい解決できるということでDropboxを使うことになっていました。

実際、機能的に制限され使い方をシンプルにされたDropboxとは簡単さは比較になりません。

もちろんDropboxが許される状況で、それで解決できるくらいのようでしたので(今後はわかりませんが)
無理強いすると反発を招きますし、それ以上は深入りせずにいたのですが、
こういったことが解決できるようなバージョン管理ソフトはないものでしょうか？

381 ：デフォルトの名無しさん：2010/11/06(土) 00:37:38

追記

規模はほんの数人の小規模です。コード書く以外の作業員も最低1人という状況です。
開発者は全員Windowsです。

ローカルネットワークからアクセス出来るファイル共有サーバーはすでにある状態で、
Subversionリポジトリもそうですが別の分散バージョン管理サーバーも設置できる権限はあります。

>>380 の要点ですが、バージョン管理ソフトを導入する利点はわかるが、
導入や利用時の手間がかかるデメリットが上回っている状況です。

382 ：デフォルトの名無しさん：2010/11/06(土) 00:45:02

> 導入や利用時の手間がかかるデメリットが上回っている状況です。

・ならば入れる必要は無いでしょう。
・Trac/Redmineなどでのタスク管理を検討しましょう。

383 ：デフォルトの名無しさん：2010/11/06(土) 00:48:38

Dropbox を入れるデメリットは無視ですかそうですか

384 ：デフォルトの名無しさん：2010/11/06(土) 00:55:11

>>380-381
そのような状況なら、自分のブランチと共同作業員のブランチを用意して
共同作業員のブランチも貴方(もしくはプログラマ)が管理すればいい

385 ：デフォルトの名無しさん：2010/11/06(土) 00:59:18

>>380-381
Trac、Redmineを立てなくても、
５人まで無料で無制限でプライベートリポジトリが持てて、wikiとBTSが付いているbitbucketが良いんじゃね

386 ：デフォルトの名無しさん：2010/11/06(土) 01:39:06

コンフリクトする度にぶち切れて暴れてみせれば、デザイナの方から
バージョン管理システム導入しようって言ってくると思うよ。

387 ：デフォルトの名無しさん：2010/11/06(土) 01:43:31

>>386
それいいなｗ　って思ったけど、デザイナの人ってそういうの気にしなーいんだよね…

388 ：デフォルトの名無しさん：2010/11/06(土) 04:04:37

そんなの人の問題
ブチ切れ方が足りない
「俺のファイルを上書きするんじゃねぇ」とキーボードぶん投げてやれば
バージョン管理の導入に同意してくれるだろ

389 ：デフォルトの名無しさん：2010/11/06(土) 05:44:58

>>386-387
ぶちきれても無駄
そんなことするより
こっちからコンフリクト上書きして
デザイン壊してやればいい

390 ：デフォルトの名無しさん：2010/11/06(土) 05:59:24

>>380
デザイナーを変えればいいんじゃね？

391 ：デフォルトの名無しさん：2010/11/06(土) 06:56:49

社内リポジトリを公開せずに、社外のコントリビューター（ヘルプ、ドキュメント、アイコン、その他、主に非プログラム関連）の
ファイルをバージョン管理するのなら、一番簡単なのは社内の人間を一人貼り付ける。代行チェックイン/アウト。

対象範囲が他とは独立していてファイルが一つくらい古くても大勢には影響でないのであれば、きらくにやってみたら？

392 ：デフォルトの名無しさん：2010/11/06(土) 12:30:41

バージョン管理面倒くさいとか言ったら、次の仕事は頼まないからってなことを匂わす

393 ：デフォルトの名無しさん：2010/11/06(土) 14:05:14

あー同僚のデザイナーにもおるわ、意地でもsvn使わん奴。もう死ねよ

394 ：デフォルトの名無しさん：2010/11/06(土) 14:13:03

そんな屑クビにしろよw

395 ：デフォルトの名無しさん：2010/11/06(土) 14:41:42

バージョン管理のノウハウ的な所についての入門とか手引きは見当たらないけど、
皆どうやって覚えてるんだ？
誰もが習うより慣れろで問題ないというわけでなし。

396 ：デフォルトの名無しさん：2010/11/06(土) 14:47:47

いろいろ書籍出てるけど？

397 ：デフォルトの名無しさん：2010/11/06(土) 14:56:08

書籍「Dropboxで楽々バージョン管理」
・コミットなどの専門用語とは、おさらば
・ブランチ、マージは必要無し

398 ：デフォルトの名無しさん：2010/11/06(土) 18:23:36

近所にいくら勧めてもバージョン管理使わないチームがいてな
いつも、上書きしたとか機能を変更したとか勝手に変えるなとかチーム内でけんかばっかりしている連中がいる。

399 ：デフォルトの名無しさん：2010/11/06(土) 18:53:41

>>397
ブランチはともかく、マージ必要無しって・・・
上書き上等ってことか？

>>387
ぶっちゃけ、デザイナは、ぱっと見て見えてる世界が全てなので、
多少の上書きには動じないってのはあるな

見えなそうなちっちゃいところ（コピーライト表記とか、すこーしだけ色味を変えるとか）で、
すごく微妙だけど許されなさそうな上書きしちゃってみればいいんではないか？

400 ：デフォルトの名無しさん：2010/11/06(土) 19:49:48

ぶっちゃけオンラインストレージよりはグローバルアドレスがひとつ欲しいんだよなあ

401 ：デフォルトの名無しさん：2010/11/06(土) 20:27:10

うちのプロバイダだと固定IPとるのに月5000円かかるからなぁ…

402 ：デフォルトの名無しさん：2010/11/06(土) 20:39:31

月500円ぐらいのVPS契約すれば、グローバルのIP1個貰えるじゃん。

403 ：デフォルトの名無しさん：2010/11/06(土) 21:39:25

固定IPなんか必要ないだろ

404 ：デフォルトの名無しさん：2010/11/06(土) 21:43:59

電気代とか、サーバーの構築費用考えたら、
クラウドでも借りた方が安いんじゃね？

405 ：デフォルトの名無しさん：2010/11/06(土) 22:01:46

このスレ的には、bitbucketかgithubで決まりだろ？

406 ：380：2010/11/06(土) 22:42:00

レスサンクス。参考になりました。俺デザイナ？っていいましたっけ・・・なんでバレてるんでしょ

BTSはすでに使っています。Redmineです。
まだ詳しく見ていないのですが、デザイナさんはチケットの切り方がちょっと大きいかなと感じました。
もうちょっと細かく切ってもらうようにしてみます。
# 意外なことにRedmineはすぐに使ってもらえたんですよね。タスクの共有はかなり困ってたので。

相手が目の前にいるので、こえかけたほうが早いというような状況もあります。
ただそれでも上書きが起こってて、件のプログラマがシステムで解決したがったみたいです。

>>383
Dropboxはメリットがデメリットを上回っている状態で、許可されてます。Gmail使っているような職場ですので・・・。

>>386
この件を提案したプログラマが切れ気味だったのかもしれないです。
プログラマは運用でなんとかするタイプだったので、むしろ相談されてちょっと驚きました。
(早いと判断すると運用でなんとかしてしまう。実際早い)
ただ工数、というか相手の作業員の面倒さや導入時間が増えるのは極力避ける方法でやっているのと、
けっこうデザイナ含め、作業以外の(ちょっと面倒くさい)効率化の話を嫌うので、気を使います。

今は話題は収まっているのですが、盛り返さない程度にもうちょっと話聞いてみます。

>>390
人員変えられたら苦労しないし、むしろ俺が変わって欲しいｗ

407 ：380：2010/11/06(土) 22:47:05

>>397
ワロタｗｗ
実際そんな感じでいい、という流れになってるｗ
プログラマがリソース受け取って手動マージｗ

Dropboxもテキストぐらいマージするモードがほしいくらいです

>>399
> 多少の上書きには動じないってのはあるな

いや、実際そうですよ。
プログラマならテキストにしておけば、
バージョン管理に入れて差分とってマージすればいいくらいが当たり前に染み付いている人も多いと思います。

ですが、扱うデータがグラフィックデータやバイナリほとんどだと
最初から差分やマージの恩恵がうけにくいので、諦めている感じがします。
システムで解決しようとする人たちが少ないのわからないですが、
この辺もう少しプログラマ界隈のようにツールが整っていてもいいのにとは思います。

408 ：380：2010/11/06(土) 23:05:12

ちょっと閃いたのですが、サーバー側にもDropboxクライアントを入れておいて、
作業員がDropboxの共有にファイルを入れたら、サーバー側で取得、
リポジトリの(デザイナは知らない)デザイナ用ブランチに自動コミットというのはありかも。

実際、そこまで手間かけてやる必要あるのか？という問題はありますが、
(こちらに支障でない程度に)なんとかカバーしてあげたいですよね。

409 ：デフォルトの名無しさん：2010/11/07(日) 04:27:31

今のご時勢バージョン管理使えるデザイナっつーのはどこに行っても重宝されるよ。現にここでもニーズがあったろう？って言えば
ぜひ使い方を教えてくれってなるんじゃねーの

410 ：デフォルトの名無しさん：2010/11/07(日) 04:42:27

>>380の人に助言できるとしたら、VCSは、何も差分だけを管理してる訳じゃないよと
履歴すなわち、誰がいつ何をしたか、ってのも残ってるんだよってことかな
DropBoxでも、それはわかるんだろうか

最終的に一つの成果物を作るわけだから、作業中の差分どうこうは結果さえよければ
どうでもいいんだが、いざ問題が出たときに「自分が」それをやって(いない|いた)ことが
保証されるっていうのは、実はものすごく大きい（主に精神安定上）

あと、コミットログがあるので、「なぜ」その変更をしたのか、が一応残っている。
これもDropBoxで再現できているっていうならまあもう言うことはないけれど。

411 ：デフォルトの名無しさん：2010/11/07(日) 09:23:42

Redmineを入れているそうだから、「誰がいつ何をしたか」の記録は残るでしょ。
VCSの機能として欠かせないのにblameがあるけど、バイナリじゃ意味ないし。
Redmineのwikiはblameもできるし。
となると、VCSを使うメリットが見出せないというのも分からないでもない。

412 ：デフォルトの名無しさん：2010/11/07(日) 11:34:14

Redmine の Wiki は微妙に使い辛いんだよなぁ。
Google Docs あたりと上手く連携出来たらいいのにってよく思う。

413 ：デフォルトの名無しさん：2010/11/07(日) 12:10:50

昔の職場、CVS使えってどんだけ言っても面倒くさがって使わない奴らばっかだったんだけど
その理由として「価値を見出せない」というのもあるけど「何もかもオープンになる」のが嫌
ってのもあったような気がするな。
特にデザイナの人ってプログラマと違ってキチキチやらないから単純な間違いも凄く多くて、
それが全部見え見え（メール飛ぶ設定になってたり）になるのが嫌なのかも。

どっかで読んだブログで、新しく来た中国人ブログラマとのコミュニケーションに
ちょっと不安があったんだけど、コミットログを見てると最近の調子が手に取るように分かる、
ってのがあって、なるほどなぁ、と思った。

414 ：デフォルトの名無しさん：2010/11/07(日) 12:20:14

業務でやってるんだから、作業内容にプライバシーなんか無いだろ。
個人の作業用ブランチに毎日コミットさせると良いぞ。

415 ：デフォルトの名無しさん：2010/11/07(日) 13:03:39

いちいち他人のログを見るってどんな暇人だよとおもう。
自分のログだって、デグレートの問題が起きなきゃ見ないよ。

416 ：デフォルトの名無しさん：2010/11/07(日) 13:07:03

え？ログ見ないの？
一行目に目的を書くの常識でしょ？

417 ：デフォルトの名無しさん：2010/11/07(日) 13:18:06

締め切り間際になって出来ていませんでしたと言われたくなかったら、進捗具合とかチェックするだろ。

418 ：デフォルトの名無しさん：2010/11/07(日) 14:12:18

普段は最低でも1日1回、多い時は4～5回コミットしているのに、
あるとき一週間コミットせずにいたら、部長に喫茶店に連れ出されて
面談になったｗ
お客さんの依頼で他の作業をしていただけで、リーダーの指示なんだから
上にも伝わっているものだと思っていたのに。
俺から部長に事情を説明したんだが、その後リーダーの機嫌は悪かった。
まあ知ったことじゃないけどね。

419 ：デフォルトの名無しさん：2010/11/07(日) 14:14:54

うちのところはフックして自動的にコミット内容メールで流してるから、
全員の進捗具合や、何をどう修正・実装したかまでだいたいわかる
つーか、普通こうやっとくもんでしょ

420 ：デフォルトの名無しさん：2010/11/07(日) 14:15:59

コミット内容がメールで流れると、コミットの粒度が無駄に大きくなりそうだ。

421 ：デフォルトの名無しさん：2010/11/07(日) 14:18:47

そういう隠蔽体質を作らないのが管理の本当の仕事だと最近思う

422 ：デフォルトの名無しさん：2010/11/07(日) 14:59:44

上司が隠蔽してのし上がった組織は隠したがるから理解されない

423 ：デフォルトの名無しさん：2010/11/07(日) 15:02:32

徹夜すればなんとかなる気質の人とかはコミットトレースされたがらないんだろうなって気はするなぁ。

424 ：デフォルトの名無しさん：2010/11/07(日) 15:05:25

そんなあなたにgit、Mercurialの--dateオプション

425 ：デフォルトの名無しさん：2010/11/07(日) 15:15:26

>>423
別にトレースされたからってその人の作業結果の価値が下がるわけじゃないと思うんだけどな
評価するやつ次第なところっていう

426 ：デフォルトの名無しさん：2010/11/07(日) 15:18:00

水面下のバタバタを隠せるって点で git は痛し痒し

427 ：デフォルトの名無しさん：2010/11/07(日) 19:12:29

>>420
チーム内の仲のいい奴や意識の高い奴と示し合わせて、
「頻繁にコミットするのが当たり前、コミットを渋る奴はバカ」みたいな空気を
作っちゃうんだよ。
意識の低い奴は周りの雰囲気に合わせて何となく動くから、雰囲気に合わせるだけで
正しい行動が取れるような環境を作ってあげるのがリーダーの仕事だよね。

まあ、俺にはとても無理だけどね。

428 ：デフォルトの名無しさん：2010/11/07(日) 19:53:37

BTS も SCM も俺ひとりしか真面目につかってない
辞めたい

429 ：デフォルトの名無しさん：2010/11/07(日) 21:09:11

>428
俺も昔はその状態だった。半年後ぐらいに改善されたが。

430 ：デフォルトの名無しさん：2010/11/07(日) 21:50:03

ttp://sourceforge.jp/magazine/10/11/01/0937206
俺も、参戦するぜ！

431 ：デフォルトの名無しさん：2010/11/07(日) 21:52:13

>430
＞リポジトリデータはSQLiteで管理する。

キモの部分が他人任せかよ。

432 ：デフォルトの名無しさん：2010/11/07(日) 22:09:21

キモかどうかは判断が分かれるな
バックエンドの処理については実装部分の話で速度に影響する
もしmonotoneが速かったらGITもMercurialも産まれてなかったかもしれない

433 ：デフォルトの名無しさん：2010/11/07(日) 22:14:39

http://po3a.blogspot.com/2007/12/subversion.html
> もし C++ で書かれた VCS が欲しいのなら、Monotone を見てみるといい。
> ほんとに。連中は「本物のデータベース」を使っているよ。
> 「素敵なオブジェクト指向ライブラリ」も使ってる。「ナイスな C++ の抽象化」も
> 使ってる。そして率直なことろ、一部の情報系の人間が喜びそうな
> これらすべての設計上の決定のために、できてきた結果はゲロゲロで
> 保守不可能なカオスだ。

434 ：デフォルトの名無しさん：2010/11/07(日) 22:29:00

ｹﾁｮﾝｹﾁｮﾝだなｗ
Cが至高なのは同意だが

435 ：デフォルトの名無しさん：2010/11/07(日) 22:42:13

Linus は最初 BitKeeper に変る SCM でMonotone を最有力に挙げていたが、
動作速度が遅いから Linus版 Monotone としてGitを作ったんだよな。

436 ：デフォルトの名無しさん：2010/11/07(日) 22:42:59

そこは別にいいんじゃね？

437 ：デフォルトの名無しさん：2010/11/07(日) 22:44:07

しょっちゅう使うツールは速いが正義なんだよなぁ。

438 ：デフォルトの名無しさん：2010/11/07(日) 22:48:02

で、Monotoneは、user-visibleなとこでは、どの辺に新規性があるわけ？
公開鍵がどうこうのあたり？

439 ：デフォルトの名無しさん：2010/11/07(日) 23:00:55

Monotone はファイル名をUTF-8に変換して管理してる。
これは Git に持ち込まなかった概念で、速度を犠牲にしたバカげた設計だと
Linus は思ったのだろう。

440 ：デフォルトの名無しさん：2010/11/07(日) 23:01:40

>>428
同じく。一回提案したら便利そうだから使ってみようって流れになったんだけど、いざ導入したらよくわからんとか難しいとか言って使ってくれなくなった…。ちなみに相手はみんなプログラマ。

441 ：デフォルトの名無しさん：2010/11/07(日) 23:18:04

Mercuの利点ってなに？

442 ：デフォルトの名無しさん：2010/11/07(日) 23:34:18

>>439
Linux上のファイル名をLANGで変換するのであるならば、それはバカげた設計

443 ：デフォルトの名無しさん：2010/11/08(月) 02:52:27

義務教育でバージョン管理のし方は教えておけよ、と思う

444 ：デフォルトの名無しさん：2010/11/08(月) 03:03:40

日記＝コミットログ

445 ：デフォルトの名無しさん：2010/11/08(月) 03:24:26

20年前のcommitにrevertするにはどうすれば

446 ：デフォルトの名無しさん：2010/11/08(月) 03:48:35

種付け＝フォーク

447 ：デフォルトの名無しさん：2010/11/08(月) 04:21:22

結婚＝マージ

448 ：デフォルトの名無しさん：2010/11/08(月) 04:27:37

浮気＝ブランチ

449 ：デフォルトの名無しさん：2010/11/08(月) 09:38:56

子供っていう派生プロジェクトを亡き者には出来ないだろ。。。

450 ：デフォルトの名無しさん：2010/11/08(月) 15:31:29

子供は分散システム

451 ：デフォルトの名無しさん：2010/11/08(月) 16:46:26

性格の不一致＝コンフリクト

452 ：デフォルトの名無しさん：2010/11/08(月) 17:20:20

commit = sex

453 ：デフォルトの名無しさん：2010/11/08(月) 18:02:38

再婚＝リベース

454 ：デフォルトの名無しさん：2010/11/08(月) 21:47:04

一つのリポジトリで複数(というか全て)のプロジェクトを管理できないかと考えています(無料のプライベートリポジトリサービスの多くは作れるリポジトリ数に制限があるようなので)。
個人でバージョン管理システムを使う場合、このような運用をする上で何か問題はありますか？
また、問題は無くともプロジェクト毎にリポジトリを分けた方がいい積極的な理由はありますか？

455 ：デフォルトの名無しさん：2010/11/08(月) 21:54:17

プロジェクトで共有しているライブラリとかたくさん作ってるなら一つにしたほうがいいんじゃないの
完全に別物ならバージョンアップのとき別々の方がいいだろうし

456 ：デフォルトの名無しさん：2010/11/08(月) 21:54:22

457 ：デフォルトの名無しさん：2010/11/08(月) 22:31:57

>>455
ありがとうございます。
やっぱりそんなに問題ないのかな。
共有ライブラリ的なものも色々作るつもりなので、単一リポジトリの方向で検討してみます。

458 ：デフォルトの名無しさん：2010/11/08(月) 22:41:00

いや、分けるべきだ

Pro Git - Pro Git 6.6 Git のさまざまなツールサブモジュール
http://progit.org/book/ja/ch6-6.html
> 「ふたつのプロジェクトはそれぞれ別のものとして管理したい。だけど、一方を他方の一部としても使いたい」

459 ：デフォルトの名無しさん：2010/11/08(月) 22:47:18

>>458
Gitのサブモジュールは正直あまり使い勝手が良いとは言えないな…

Subversionでやるならディレクトリ単位で好きにチェックアウト出来るから
手軽さではこっちのほうが良いと思う。中央集権型になっちゃうけどね。

460 ：デフォルトの名無しさん：2010/11/08(月) 22:50:07

>>456
> 彼女をGNU Screenで

これ分からんw　で、どうするんだ？

461 ：デフォルトの名無しさん：2010/11/08(月) 22:52:52

Gitのsubmoduleが使い安いとはいえんがSubversionの方が良いとは思えないな。

462 ：デフォルトの名無しさん：2010/11/08(月) 22:56:23

プライベートリポジトリ作り放題のbitbucketでのMercurialのsubrepo

463 ：デフォルトの名無しさん：2010/11/09(火) 02:28:28

質問があります。
TortoiseSVNやTortoiseGitやTortoiseBzrでエクスプローラーへの組み込みをなすことはできないでしょうか？
アンインストールするしかないでしょうか？

Tortoise系のツールをシェル拡張で組み込んでおくと、
Windowsでいうシェルを利用したその他ソフトの動作が遅くなるような気がしていて検証したいためです。

464 ：デフォルトの名無しさん：2010/11/09(火) 03:09:31

検証するまでもなく遅くなるよ
右クリックするたびにフォルダー内検索するわけだから

465 ：methane：2010/11/09(火) 03:24:19

TortoiseBZRでは、シェル拡張そのものを一時的に無くすことはできないものの、
バックグラウンドプロセスがディレクトリ内をチェックすること無しに応答するスリープ
機能を実装しています。
タスクトレイアイコンを右クリックでスリープをチェックするとスリープします。

466 ：デフォルトの名無しさん：2010/11/09(火) 04:04:45

Gitのsubmoduleって初めて知った

submoduleはそこのディレクトリ以下が親repo内で「何処そこのrepoのハッシュ某」とされるだけで
親repo内では内部に一切関知しない仕組みってことかな

467 ：デフォルトの名無しさん：2010/11/09(火) 05:07:50

TortoiseXXXはキャッシュあるだろ

468 ：デフォルトの名無しさん：2010/11/09(火) 07:39:41

TortoiseHgはGNOMEのシェル拡張もあります。
TortoiseHgはWindows・GNOMEともキャッシュはありません。
リポジトリ単位でアイコンを表示するしないの選択ができます。
Windowsでは、シェル拡張を入れる入れないの選択も出来た気がします。
シェル拡張を経由せず、コマンドラインから起動できます。
次期バージョンではデスクトップアイコンかスタートメニューで起動できるようになるかもしれません。

469 ：デフォルトの名無しさん：2010/11/09(火) 09:48:13

>>463
特定のディレクトリ以下だけに反応させる設定があったような。

470 ：デフォルトの名無しさん：2010/11/09(火) 09:53:02

結局Tortoiseで使い物になるのってSVNだけ？

471 ：デフォルトの名無しさん：2010/11/09(火) 10:02:44

TortoiseHgはGNOMEのシェル拡張はMercurialのPythonのライブラリを直接呼んでいます。
つまり、hg statusと同様のことをしています。
ですので、キャッシュも必要無く、高速です。

TortoiseHgのWindowsのシェル拡張も以前は同様の処理を行っていました。
しかし、Pythonでやるのは無理があったのか、C++に置き換えられました。
hg statusを叩くと、.hg/dirstateが更新されます。
これのタイムスタンプを確認しています。
これで高速化しています。

472 ：デフォルトの名無しさん：2010/11/09(火) 10:17:10

TortoiseHgをWindowsに入れるとタスクバーのシステムトレイにMercurialのアイコンがあるのが分かると思います。
これはPythonで書かれています。
ファイルを更新すると、システムトレイのアイコンが光ると思います。
この時に.hg/dirstateが更新されます。

473 ：デフォルトの名無しさん：2010/11/09(火) 12:02:30

TortoiseHgって、インスコ済のマシンからバイナリをコピーしてきて、
コマンドラインから個々のツールを起動できるの？
何か、出来そうな雰囲気にも見えるけど。

474 ：デフォルトの名無しさん：2010/11/09(火) 12:20:41

PATHを通せばいけそうな気もしないでもない

475 ：デフォルトの名無しさん：2010/11/09(火) 12:27:19

>>473
> TortoiseHgって、インスコ済のマシンからバイナリをコピーしてきて、
これはやったことが無いので分かりません。

> コマンドラインから個々のツールを起動できるの？
TortoiseHgのインストールしたところにhgtk.exe（現安定バージョン）があると思います。
Linuxのパッケージ配布ですと、/usr/bin/hgtk になっていると思います。

hgtk help と叩いて見てください。
usageが出てきます。
これらのサブコマンドをシェル拡張が起動しています。

476 ：デフォルトの名無しさん：2010/11/09(火) 23:46:25

そうだねぇ、TortoiseでマトモなのはSVNだけな気がする。
他はまだ「急いで作った」感が激しい。

TortoiseSVNがもっと特定のバージョン管理システムに依存してない作りならよかったのにね。
それこそ、TortoiseALLみたいな、設定次第で複数のバージョン管理システムようにできればよかった。

477 ：デフォルトの名無しさん：2010/11/10(水) 07:27:44

>>476
> それこそ、TortoiseALLみたいな、設定次第で複数のバージョン管理システムようにできればよかった。
TortoiseHgは、hgsubversionを使うことでSubversionを、hg-gitを使うことでGitを直接操作することが可能です。

478 ：463：2010/11/10(水) 09:07:03

右クリックのメニューが5～10秒)くらいかかっていたのがTortoise系全部外したら2秒くらいになった。
すごく快適。

最新版では違うかも知れないけど、TortoiseGit、TortoiseBzr、TortoiseSVNともどれもアンインストーラーでシェル拡張だけ外すことができなかったので、
TortoiseHgは重いから前にすでに外してた。
TortoiseHgが重いのじゃなくてGUIだと以前のバージョンでは重いリポジトリで固まってただけなので誤解しないで

シェル拡張外していざというときに使えたらいいと思う。
コマンドラインで使えるけど、履歴やブランチをグラフィカルに見たいことあるからね。
gitはコマンドライン版でもgitkみたいなのあるからいらないかもしれない。

アイコン表示はとても便利なんだけど重いのは仕方がない・・・
IDEに拡張入れてつかうとか回避策はあるし

479 ：463：2010/11/10(水) 09:09:28

TortoiseGitアンインスコしてもまだメニューに残っているんだけどこれはmsysgitのかな

>>475 訂正

> 最新版では違うかも知れないけど、TortoiseGit、TortoiseBzr、TortoiseSVNともどれもアンインストーラーでシェル拡張だけ外すことができなかったので、

最新版では違うかも知れないけど、TortoiseGit、TortoiseBzr、TortoiseSVNともどれもアンインストーラーでシェル拡張だけ外すことができなかったので、
シェル拡張外していざというときに使えたらいいと思う。

>>471-473
TortoiseHgは単体で使えますか。

そもそも外部ツールを呼び出しているだけだろうし、切り離して使えるとすごく助かります。

480 ：methane：2010/11/10(水) 09:22:16

TortoiseBZRはスリープ機能持ってるけど、そもそもシェル拡張外したいっていう話ですね。
アンインストーラーの拡張は面倒だけど、スタートメニューにメニューを追加するのはできそう。
中では regsvr32 呼んでるだけだし。
ただ、per user install と全員のインストールの切り替えとか考え出すと面倒だ。

ちなみに、bzrはインストーラーでTortoiseBZRを外して Bazaar Explorer だけインストールすると、
統合型GUIだけで使えます。

481 ：デフォルトの名無しさん：2010/11/10(水) 09:24:24

トータス（陸亀）なのかタートス（海亀）なのか、そこが問題だ。

482 ：methane：2010/11/10(水) 09:26:31

>>481
オフラインが陸、オンラインが海
シェル拡張はオフラインなのでTortoise
Web上ののリポジトリブラウザはオンラインなので海亀のLoggerhead

483 ：デフォルトの名無しさん：2010/11/10(水) 09:29:34

>>482
アカウミガメって種族の海亀なのか。ちょっと感動。

484 ：デフォルトの名無しさん：2010/11/10(水) 09:35:44

tortoiseBZR使ってるけど、
管理対象フォルダを見に行くと
マシン起動後初回は必ず時間かかって、間違ったアイコンが表示される。

なんか、あわてふためいたあげく間違えるとかかわいくて萌える///

485 ：デフォルトの名無しさん：2010/11/10(水) 10:09:45

>>479
> >>471-473
> TortoiseHgは単体で使えますか。
>
Fedora(Linux)ではパッケージがtortoisehgとtortoisehg-nautilusが分けて配布されています。
tortoisehgに/usr/bin/hgtkが含まれていて、これが画面(PyGTK)の実態です。
コマンドラインから hgtk log や hgtk add をすることで画面が表示されます。

WindowsでもC:\Program Files\TortoiseHg\hgtk.exe があると思います。
Linux同様 hgtk.exe をコマンドラインから実行することで画面があがります。

hgtk とサブコマンドを入れないとusageが流れるだけです。

% ./hgtk
Hgtk - TortoiseHg's GUI tools for Mercurial SCM (Hg)

basic commands:

clone clone tool
commit commit tool
.
.
.

次期バージョン(PyQt)のthgではサブコマンドを指定しない場合、ワークベンチ画面が立ち上がります。
thg --noforkと書かれたバッチファイルをデスクトップなどに用意すると、ワークベンチ画面が立ち上がります。

486 ：デフォルトの名無しさん：2010/11/10(水) 10:21:43

>>478
> TortoiseHgが重いのじゃなくてGUIだと以前のバージョンでは重いリポジトリで固まってただけなので誤解しないで

ログ画面でかなりの数のリビジョンを読み込むので、重いかと思います。
初期設定では500のようです。

mercurial.iniか.hg/hgrcに以下のものを書くと速くなると思います。

[tortoisehg]
graphlimit = 50

またTortoiseHgの画面の「リポジトリ設定」→「ログの表示」→「ログ読み込み件数」で設定できます。

487 ：methane：2010/11/10(水) 10:36:03

>>484
間違ったというか、ステータス取得中は ? を表示して、ステータス取得後に正しいアイコンに
アップデートする仕様になっています。アイコンオーバーレイの仕様上、すぐにステータス返さないと
エクスプローラー自体を待たせてしまうので。

488 ：デフォルトの名無しさん：2010/11/10(水) 12:29:33

WinCvs みたいな独立したツールが好きだったんだがなあ。
なんで Tortoise が普及してしまったのか。

489 ：デフォルトの名無しさん：2010/11/10(水) 12:34:58

WinCvs みたいな独立したツールが好きじゃないから。

490 ：デフォルトの名無しさん：2010/11/10(水) 12:46:08

bzr explorer とか git extentions とかは単体ツールとして良くできてると思うけどなぁ

491 ：463：2010/11/11(木) 06:39:47

シェル拡張外しまくったらエクスプローラーさくさくうごいてワロタｗ
コンテキストメニューの表示が早くなっただけでも大分違いますね

ただ重いところは重いままだったので、問題が切り分けできて助かりました。

>>479
> TortoiseGitアンインスコしてもまだメニューに残っているんだけどこれはmsysgitのかな

msysgitでエクスプローラーのメニュー拡張されていたので一旦アンインストールしました。

492 ：デフォルトの名無しさん：2010/11/11(木) 08:29:01

>>488
やっぱりシェル統合は便利だよ。
エディタやランチャからコンテキストメニュー表示するだけでバージョン管理できるから。
各ツールから個々のsvnのコマンドを呼び出せるようにしようとすると結構手間かかるし。

バージョン管理は主ではなくあくまで従なんだと思う。

493 ：デフォルトの名無しさん：2010/11/11(木) 08:38:02

シェル拡張といってもいろいろあるけどな。ちょっと右クリックメニューを拡張するだけならまだしも、
SVNクライアントの機能をまるごとエクスプローラのプロセス内にロードすりゃ重くもなるか。

494 ：デフォルトの名無しさん：2010/11/11(木) 15:59:02

どんなのが便利と感じるかも人それぞれか
バージョン管理しないときまでバージョン管理に関するものが見えるのは俺は不便だと思うが

495 ：デフォルトの名無しさん：2010/11/11(木) 16:08:54

バージョン管理なんか、シェルに組み込むほど、たいそうなもんじゃないよな。
シェルはOSの基盤だよ。

496 ：デフォルトの名無しさん：2010/11/11(木) 16:15:46

自作のしょうもないシェル拡張入れちゃってるな

497 ：デフォルトの名無しさん：2010/11/11(木) 16:26:37

ファイルシステムにバージョンの概念があったVMSに喧嘩売ってる？

498 ：デフォルトの名無しさん：2010/11/11(木) 17:20:40

あれってシェルがやってくれてるのかと思ってた

499 ：デフォルトの名無しさん：2010/11/11(木) 18:51:58

えくすぷろらライクのファイラーにコンテキストメニュー付くだけでいいんだがな

500 ：デフォルトの名無しさん：2010/11/11(木) 19:06:45

>>499
プログラマはそれでも良いが、デザイナなどの一般のユーザ対象だと、その画面の開き方の説明から始めないといけない。
エクスプローラという共通インターフェースを使っているTortoiseSVNの功績は大きい。

501 ：デフォルトの名無しさん：2010/11/11(木) 20:50:18

>>495
＞シェルはOSの基盤だよ。
ぷ。ｗ
「シェル」をそう呼ぶ所以をご存知？

502 ：デフォルトの名無しさん：2010/11/11(木) 22:18:29

shell と core という言葉の意味においても語源においても
破格の位置付けだと思うけど

503 ：デフォルトの名無しさん：2010/11/12(金) 09:12:42

>>501
出たよ、揚げ足取り薀蓄たれのドアホウが。
「OS の基盤はカーネルだろｗｗｗｗｗ」
とか言いたいのか？
お前、人とまともにコミュニケーション取れないだろ。
いや、お前は取れてると思ってても相手は実に不快な思いをしているはずだ。
お前が友達と思ってるやつの大半はお前のことを友達とは思ってないな。

504 ：デフォルトの名無しさん：2010/11/12(金) 09:17:55

そう言うのをさらっと流せないのがお前の駄目なところだな

505 ：デフォルトの名無しさん：2010/11/12(金) 09:20:22

>>503
間違いを認めずに全力で言い訳を続けるような、お前こそまわりとコミュ
ニケーションとれてないだろ。
お前うざいと思われている事確実。空気読めない発達障害なんだろうな。ｗ

506 ：デフォルトの名無しさん：2010/11/12(金) 09:32:12

Windows NT 3.51 まではウィンドウシステムはコアとは分離していたけど、
NT 4.0 からはコアに含まれたんじゃなかったっけ？

507 ：デフォルトの名無しさん：2010/11/12(金) 09:58:18

それはGDIの事だ。

508 ：デフォルトの名無しさん：2010/11/12(金) 10:18:54

userもカーネルモードだぞ

509 ：デフォルトの名無しさん：2010/11/12(金) 10:54:48

kernel32もuser32もgdi32も一部ユーザー一部特権

510 ：デフォルトの名無しさん：2010/11/12(金) 11:12:44

>>503
ttp://togetter.com/li/66450

511 ：デフォルトの名無しさん：2010/11/13(土) 16:19:10

インスコ済のTortoiseHgをコピーしてきて使う件だけど、試してみたら、
パスを通しておけば、 hgtk log とか hgtk status とかでGUI呼び出して使えるね。

Explorerは汚染されないし、これで十分な気がする。

512 ：デフォルトの名無しさん：2010/11/13(土) 17:52:45

そういう裏技的に使えるようにしても嬉しくない・・・

よく「このツールは便利！」とか聞くけど、「残念なのは・・・」とかで回避法が一緒にくっついてる
そういうのって便利でない上に冷める・・・結局使わない

513 ：デフォルトの名無しさん：2010/11/13(土) 23:45:58

裏技ってか、元々独立して作られたものじゃないの？
hgtkって

514 ：デフォルトの名無しさん：2010/11/14(日) 08:37:27

>>512
むしろそうじゃない便利なツールというものが世の中にあれば教えて欲しいが

それはそれとして、今の話の流れはエクスプローラーが重くなるのでシェル拡張から外した状態で
エクスプローラーに組み込むためのTortoiseツールを使いたいという話なのね。

つまり今の>>463の言うところの「残念なのは・・・」というのはそもそもがエクスプローラーが多少なりとも重くなる、
しかもTortoiseSVN一個ならよいが、TortoiseBzr、TortoiseGitも入れるとさらに重いという点だ。
TortoiseHgは>>463はいれていなかったか。

>>512が「裏技的に使えるようにしても嬉しくない」と思うならエクスプローラーに組み込んで使えばいいだけだし、
>>463には単体で起動出来れば嬉しいわけだし、意味がわからん。

515 ：デフォルトの名無しさん：2010/11/14(日) 08:42:21

まあまあ

>>512
こういう馬鹿がいるから、TotoiseSVNは普及してシェアを獲得したわけだし、
BazaarExplorerのように単体で使えるツールを持っているバージョン管理ソフトならば、
スタートメニューなりにショートカットなり作れば解決する話じゃねーの

できれば、後からインストーラーでシェル拡張のON/OFFを切り替えられればなおよし

516 ：デフォルトの名無しさん：2010/11/14(日) 08:49:11

オープンソースだし分散型なんだから自分用にフォークして改造するか本家にパッチを送れば良いだけ

517 ：デフォルトの名無しさん：2010/11/14(日) 10:49:11

http://www.ohloh.net/tags/tortoise

518 ：デフォルトの名無しさん：2010/11/15(月) 03:10:03

>>516

>>515にできるわけないじゃんｗ

519 ：デフォルトの名無しさん：2010/11/15(月) 07:04:51

TotoiseSVN程度で重いとかほざいてる馬鹿はとっととSSDにしとけ
よほどの無能でもない限りは投資分回収できるだろ
問題解決能力の低さから見て、そのよほどの無能なのかも知れんけどさ

520 ：デフォルトの名無しさん：2010/11/15(月) 07:05:43

今気付いたがスペルミスってんじゃねぇか使えねぇｗ

521 ：デフォルトの名無しさん：2010/11/15(月) 07:10:17

>>519
>>519が見るにディスクアクセスが原因ってことか？
わかった試してみるわ

ソースがあるローカルのストレージは容量の都合で変えられんが
OSのHDDは変えられると思うので

522 ：デフォルトの名無しさん：2010/11/15(月) 13:11:13

>>521
ソースのドライブを変えなければ
ほとんど意味がないと思うが。

TSVNCacheプロセスの優先度を
上げれば。
あんまり勧めないけどな。ｗ

523 ：デフォルトの名無しさん：2010/11/17(水) 14:54:24

以前、TortoiseSVNが見る対象パスを設定できるとか書いたけど間違ってた。すまそ。
実際は、対象から外すパスの設定だった。
Settings→General→ContextMenu→Do not show..のテキストエリアな。
とりあえずエロ画像ドライブとかは設定しといた方がいいよ

524 ：デフォルトの名無しさん：2010/11/17(水) 15:33:24

これは良い情報
㌧㌧

525 ：デフォルトの名無しさん：2010/11/17(水) 15:43:45

アイコンオーバレイの方の対象/除外パスの方が効果があると思うが

526 ：デフォルトの名無しさん：2010/11/17(水) 15:57:09

このスレ、何でTeam Foundation Serverの話題が皆無なの？

527 ：デフォルトの名無しさん：2010/11/17(水) 16:36:14

>>526
みんなVSSで満足しているから

528 ：デフォルトの名無しさん：2010/11/17(水) 19:01:58

貧乏だから。

529 ：デフォルトの名無しさん：2010/11/17(水) 19:16:54

>>526
ClearCaseに到底及ばないから

530 ：デフォルトの名無しさん：2010/11/17(水) 19:52:39

MSDNに入ってれば、Team Foundation Serverタダで使えるようになったのに。
この話題にならなさは異常。

531 ：デフォルトの名無しさん：2010/11/17(水) 20:12:57

MSDNがタダでないから

532 ：デフォルトの名無しさん：2010/11/17(水) 21:38:37

Express版でも出してくれればいいんだけどな。
全く話題に上ったことがない。

533 ：デフォルトの名無しさん：2010/11/17(水) 22:46:07

誰が欲しがるんだよ

534 ：デフォルトの名無しさん：2010/11/17(水) 22:54:00

確かにいまどきMSのEnterpriseな製品を有り難がる人間は少ないだろうな。
ほんの数年前までは、嬉しそうにして購入してる人とかも居たかもしれん。

535 ：デフォルトの名無しさん：2010/11/17(水) 23:00:03

で、Team Foundation Serverとやらは、VSSよりはぶっ壊れなくなったの？

536 ：デフォルトの名無しさん：2010/11/18(木) 00:45:20

誰も使ったことのない、幻のシステムなので知らん。

537 ：デフォルトの名無しさん：2010/11/18(木) 02:07:21

このスレは　無料バージョン管理システムについて語るスレ7　なんで間違えないように

538 ：デフォルトの名無しさん：2010/11/18(木) 03:00:33

microsoft内の開発チームがTeam Foundation Serverを使うようになったら
考えてもいい

539 ：デフォルトの名無しさん：2010/11/18(木) 03:03:17

バリバリ使ってるだろ

540 ：デフォルトの名無しさん：2010/11/18(木) 03:18:07

microsoftが自分で使ってなかったのはVSSの話であって、
TFSは使ってるはず。

541 ：デフォルトの名無しさん：2010/11/18(木) 03:21:20

microsoft内ではパッチベースだと聞いたよ

542 ：デフォルトの名無しさん：2010/11/18(木) 03:28:21

それは逆にかっこいいな！

543 ：デフォルトの名無しさん：2010/11/18(木) 03:30:48

自分が使わないものを人に使わせるのか

544 ：デフォルトの名無しさん：2010/11/18(木) 05:46:48

>>537
そんなことないだろ
たまたま今は無料のものが普及していてコミュニティのひとつとしてここが使われているにすぎんでしょ

有料のものを使うのは公式のサポートが必要なこともあり、
それで済むならここで聞く必要ないからな

545 ：デフォルトの名無しさん：2010/11/18(木) 05:47:38

>>538
自分たちは何使ってんだよ、ということだよな

今はmercurialなんだっけ？

546 ：デフォルトの名無しさん：2010/11/18(木) 09:24:27

mercurialを脱共有するつもりだなM$FTめ

547 ：デフォルトの名無しさん：2010/11/18(木) 16:58:59

いまはHG一択だろ
ふぉー

548 ：デフォルトの名無しさん：2010/11/18(木) 21:31:33

Linuxのコンソールで、diffを行単位だけでなく、変更行の中の変更ワード単位で
（カラフルに）表示させたいんだけど、なんかいいツール有る？

Windowsで言えば、ExamDiffみたいな感じで。

549 ：デフォルトの名無しさん：2010/11/18(木) 21:41:58

vimのdiff mode(vimdiff)とかは？

550 ：デフォルトの名無しさん：2010/11/18(木) 21:44:03

>>548
$ vimdiff foo.txt bar.txt

551 ：デフォルトの名無しさん：2010/11/18(木) 22:03:06

うちの色設定の問題なんだろうが、色が付いたところが塗りつぶされて、
結局差分が分からないという＞ vimdiff
あれ、syntax切ればいいだけかな？

552 ：デフォルトの名無しさん：2010/11/18(木) 22:03:15

vimdiffやってみたけど、結構使えそうだね。
ちょっとワードの分割基準が変だったけど。

あと、こんなのも見つけた。
http://mercurial.selenic.com/wiki/WordDiff
誰かさんの書いたシェルスクリプト + wdiffのようだが、これもまあまあ使える。
見やすいのはvimdiffの方かも。

553 ：デフォルトの名無しさん：2010/11/20(土) 10:09:02

>>548
gitだと--word-diffとか--color-wordsとかで出来るよ

554 ：デフォルトの名無しさん：2010/11/23(火) 12:29:29

>>55
1.6には--word-diffなかったから--color-words試した
いいねこれ

分かち書きがいい加減なのか、変更していない箇所も変更してる箇所と連続していると
差分として認識されてしまうみたいだけど、色が表示できる環境だと見やすい

555 ：554：2010/11/23(火) 12:53:26

>>554のアンカーミス
>>553 へです

556 ：デフォルトの名無しさん：2010/11/23(火) 13:40:44

git使ってると、2chのアンカミスも直す方法があるような錯覚がして仕方ない

557 ：デフォルトの名無しさん：2010/11/23(火) 16:34:07

git reset --hard HEAD^

558 ：デフォルトの名無しさん：2010/11/23(火) 16:38:44

git commit --amend
が素直
しかしすでにpushされてる状況と考えると、gitでもやっぱり手遅れ

559 ：デフォルトの名無しさん：2010/11/23(火) 19:12:16

なんというか、頭をガツンとリセットみたいな

560 ：デフォルトの名無しさん：2010/11/23(火) 23:42:51

2ch用のproxy用意して書き込んだらローカルでは反映されていて、
pushしたら実際に投稿されるのでいいんじゃね？

掲示板も分散の時代だな

561 ：デフォルトの名無しさん：2010/11/23(火) 23:43:40

レスアンカーがひどく長いハッシュ文字列になりそうだな

562 ：デフォルトの名無しさん：2010/11/24(水) 00:18:50

削除人がammendした後にローカルでマージした古い履歴をあげてカオスに

563 ：デフォルトの名無しさん：2010/11/24(水) 00:24:45

git commit --date='2011-01-01 00:00:00' -m 'あけおめ'

564 ：デフォルトの名無しさん：2010/11/24(水) 00:48:26

http://hibari.2ch.net/test/read.cgi/tech/1231570128/

565 ：デフォルトの名無しさん：2010/11/24(水) 01:32:58

>>560
network news の再来ですか。手元に過去のゴミログが全部あると。
2ch みたいのは、分散させなくても、Google App Engine 向きなんじゃないかなぁ、と思ったり。

566 ：デフォルトの名無しさん：2010/11/24(水) 02:19:52

あんまり流行らなかったが、nyのBBSなんかがある種の方向なんじゃないかと

567 ：デフォルトの名無しさん：2010/11/24(水) 20:19:38

コピペ連投もブランチ切ってrebaseで簡単に！

568 ：デフォルトの名無しさん：2010/12/01(水) 14:49:02

個人情報削除せず新規顧客にコピー再販→流出
http://www.chunichi.co.jp/article/gifu/20101123/CK2010112302000115.html

これってやっちゃったってこと？

569 ：デフォルトの名無しさん：2010/12/01(水) 16:19:57

>>568
http://slashdot.jp/security/article.pl?sid=10/09/28/0557220

570 ：デフォルトの名無しさん：2010/12/02(木) 23:04:57

素人かよｗ
>>三菱電機インフォメーションシステムズ

571 ：デフォルトの名無しさん：2010/12/03(金) 00:15:16

素人でももっとまし

572 ：デフォルトの名無しさん：2010/12/04(土) 10:29:31

学生バイトの習作程度

573 ：デフォルトの名無しさん：2010/12/07(火) 09:30:12

結局日本語ファイル名を扱うならBazaar一択ですか？
gitとか日本でも流行ってきてるから解決されてると思ったのに。

574 ：デフォルトの名無しさん：2010/12/07(火) 09:35:51

>>573
あなたが解決すれば？何を解決するか知らないけど

575 ：デフォルトの名無しさん：2010/12/07(火) 09:39:46

みんなドキュメントとか管理してないのかな？

576 ：デフォルトの名無しさん：2010/12/07(火) 09:41:37

>>575
あなたはどうやって管理しているのですか？

577 ：デフォルトの名無しさん：2010/12/07(火) 09:44:04

>>576
あなたはどうやって管理しているのですか？

578 ：デフォルトの名無しさん：2010/12/07(火) 09:46:38

>>577
LaTex

579 ：デフォルトの名無しさん：2010/12/07(火) 10:03:38

LaTexって分散バージョン管理できるんですか？

580 ：デフォルトの名無しさん：2010/12/07(火) 10:39:12

>>579
https://github.com/progit/progit/tree/master/latex

581 ：デフォルトの名無しさん：2010/12/07(火) 23:00:26

CVSのフロントエンド(GUI)をQtで作った。
まあ、フリーソフトが結構あるみたいだから、それでも良かったんだけど。
自分で作った方が自分好みに変更できていいよね。

582 ：デフォルトの名無しさん：2010/12/11(土) 21:04:51

まだCVS使ってるとこって多いのかな？
何のメリットもないと思うんだけど。

583 ：デフォルトの名無しさん：2010/12/11(土) 21:10:48

何使おうが勝手だろ
流行に飛びつくのはみっともない事だという美意識が近年なくなってむなしい
別に飛びつくなとは言ってないつもりだが

584 ：デフォルトの名無しさん：2010/12/11(土) 21:21:31

流行だから飛びつくって考えの人は皆無だろ（＊人柱は除く
不満のあったところが改良されているから乗り換えるんだろ

585 ：デフォルトの名無しさん：2010/12/11(土) 21:23:47

いや、ここでCVSの美点を語ってくれてもいいんだぞ？

586 ：デフォルトの名無しさん：2010/12/11(土) 22:08:14

Subversionのブランチ・タグが特殊過ぎるからCVSを使いつづけている所は多いと思う

587 ：デフォルトの名無しさん：2010/12/12(日) 01:24:32

CVS使っててイライラさせられる点しかなかったけどw

当時、周囲でバージョン管理してないプロジェクトやプログラマーはアホみたいな風潮が流れて、
CVS使ってみてこんな糞みたいなものをよくつかってたと当時ですら思ったわ

そして近年、昔のプロジェクトを弄ろうと久しぶりにWinCVS立ち上げたら気狂いそうになったぞ。
短気でない人間をも短気にさせるツールそれがCVS

もう全部Subversionのリポジトリ変換したからいいが

しかし、数年前から俺にとってのイライラツールがSubversionになろうとしてる、、、

588 ：デフォルトの名無しさん：2010/12/12(日) 01:26:00

いやひょっとしたら、WinCVSが使いにくいだけだったのかもしれんな
それだったらスマソ

今はコマンドラインやシェル使うが当時はあまり使っていなかったからな

589 ：デフォルトの名無しさん：2010/12/12(日) 01:31:11

お前らこの「svnが遭遇してきた問題点とその解決策」を共有したいのでどこに記述あるか教えてください

【bzr】Bazaarでバージョン管理 Rev 2
http://hibari.2ch.net/test/read.cgi/tech/1265951333/491-495

491 ：デフォルトの名無しさん：2010/12/10(金) 18:02:33
bzr初心者です。2.2.2をMac上で使おうとしてますが、扱うファイル名に濁点が含まれていると
うまく動いてくれません。NFCとNFDの問題が絡んでいるということはわかったのですが、
何か回避方法はあるんでしょうか？（何かパッチを当てるとか。）

492 ：デフォルトの名無しさん：2010/12/10(金) 22:45:46
# だれかutf-8-macなcodec作ってくれ

493 ：デフォルトの名無しさん：2010/12/11(土) 08:29:26
なんだBazaarでも日本語使えないのか

494 ：デフォルトの名無しさん：2010/12/11(土) 14:48:30
Subversionでも解決しているに>>1の「多言語に完全対応」というのは嘘だったのですね

495 ：デフォルトの名無しさん：2010/12/11(土) 21:48:19
svnが遭遇してきた問題点とその解決策が
ハッカーの間で共有知になってないことが問題なのかもしれぬ

590 ：デフォルトの名無しさん：2010/12/12(日) 01:32:13

誤爆・・・

591 ：デフォルトの名無しさん：2010/12/12(日) 01:41:23

>>589-590
こっちでいいじゃん
http://d.hatena.ne.jp/hnw/20081024

592 ：デフォルトの名無しさん：2010/12/12(日) 01:42:16

ここも
http://www23.atwiki.jp/selflearn/pages/55.html

593 ：デフォルトの名無しさん：2010/12/12(日) 01:44:57

あとここ
http://hibari.2ch.net/test/read.cgi/tech/1251208950/466-474

594 ：デフォルトの名無しさん：2010/12/12(日) 03:21:11

いまどき昔のCVS(WinCVS含む)使ったらファイル破壊されそうで怖い

595 ：デフォルトの名無しさん：2010/12/12(日) 03:26:44

>>594
Subversionのbdbの方がもっと怖い

596 ：デフォルトの名無しさん：2010/12/12(日) 13:47:47

bdbはとっくの昔にデフォルトでは使われなくなってるぞ

597 ：デフォルトの名無しさん：2010/12/12(日) 13:56:24

>>594, 595 破壊方法教えてくれ
過去のプロジェクトメンテの必要性から、いまだに CVS と bdb 使った SVN が動いているが
一度も壊れたことがない。
壊れる危険性があるのなら、こいつらを新しい VC に移行させる立派な理由になる

598 ：デフォルトの名無しさん：2010/12/12(日) 13:58:36

うろ覚えだけどbdbはLANでリポジトリ共有して同時アクセスするとやばいんだっけ。

599 ：デフォルトの名無しさん：2010/12/12(日) 16:09:42

排他制御がおかしいとかだったような気がする。

600 ：デフォルトの名無しさん：2010/12/12(日) 19:04:32

ちゃんとsvnserve通してれば問題は出ないだろうね。
割と最近までbdbで数十Gあるリポジトリ扱ってたけど、中身が壊れたことは無いな（今はFSFSに移行）。
ロックはよくおかしくなってたが。
svn bdb でググるとBerkeley DBが壊れたって話はいっぱい引っかかるけど、
読んでみるとロックがおかしくなったとかログファイルが壊れたとかで、リカバリできたって話ばっかりだな。

もちろん新規リポジトリで使う理由は全く無い。

601 ：デフォルトの名無しさん：2010/12/12(日) 23:27:07

CVS派の人達は、Subversion初期の頃のイメージで停まってるって感じ？
未だにBDBの話なんかしてるし。

ま、今じゃSubversion自体が老害の域に入ってるんだけどね。

602 ：デフォルトの名無しさん：2010/12/12(日) 23:32:30

> CVS派の人達は、Subversion初期の頃のイメージで停まってるって感じ？

ことの発端は >>597 が言ってる過去のリポジトリが現役で動いてるって話だろ？
複数のVCを一本化したいってのがそもそもの主旨だと思うけどな…

603 ：デフォルトの名無しさん：2010/12/13(月) 08:00:24

>>591-593
誤爆したのにありがと

Subversionスレの方は追い出されてワロタww

604 ：デフォルトの名無しさん：2010/12/13(月) 08:02:00

bdbはバージョンアップの度に使えなくなってリポジトリのアップグレードが必要になったから捨てたわ
今はリポジトリ頻繁に変わらないのかも知れないが

605 ：デフォルトの名無しさん：2010/12/13(月) 08:04:08

>>601
CVSだかSubversionだかいっているうちは大丈夫。
デザイナー界隈はまだバージョン管理の必要性の議論が度々起こる。
思い切ってSubversion導入したとか言ってる。数年遅れてる。

606 ：デフォルトの名無しさん：2010/12/13(月) 09:03:18

>>592
なんだよこれ
散々、言っておいて結局variantsで別途配布じゃねーか
MacユーザーがただSubversion入れただけだと誰しもが使える状況じゃないじゃん
全世界のMacユーザーがSubversion入れるときにvariantsもいれろっていって回るのかよ

607 ：デフォルトの名無しさん：2010/12/13(月) 09:12:13

>>606
糞OSは使うな
以上

608 ：デフォルトの名無しさん：2010/12/13(月) 10:01:29

svnはMacOSXでaddできるけどbzrはそれすらできないってことでは

609 ：デフォルトの名無しさん：2010/12/13(月) 22:27:19

>>594
cvsつかったらファイル破壊されそうとか言ってるガキはなんなんだ？
何年前＆何プロジェクトで使われて実績積んできたか分かってるのか

610 ：デフォルトの名無しさん：2010/12/13(月) 22:34:28

エキサイトするのは具体的な破壊の手順が提示されてからで十分だ

611 ：デフォルトの名無しさん：2010/12/13(月) 22:50:58

>>610
*,vの中身を手でいじる

612 ：デフォルトの名無しさん：2010/12/13(月) 23:10:02

エレクチオンはしているがエキサイトはしていない

613 ：デフォルトの名無しさん：2010/12/14(火) 00:31:56

リポジトリを直接いじって破壊できないVCSなんてないだろうに。
CVSはリポジトリを直接いじらないとならないケースがあるのがダメだって話なら否定はしないけど。

614 ：デフォルトの名無しさん：2010/12/14(火) 01:18:25

find .. | xargs sed -iみたいなことして.svnや.hgや.gitの中身まで変更しちゃうことはたまーにある

615 ：デフォルトの名無しさん：2010/12/14(火) 01:27:27

cvsのリポジトリの中身はテキストファイルで、チェックサムが入っているように見えないから、
ファイルシステムが壊れかけの時、どうなるのか不安

616 ：デフォルトの名無しさん：2010/12/14(火) 04:12:38

>>615
中身はRCSと全く同じなので、一応セパレータはあるから途中までしか読み出せないときはエラーになったはず。
その点、最新リビジョンが先頭に来る仕様だから,vファイルが壊れたときにも手動復元は比較的容易。

617 ：デフォルトの名無しさん：2010/12/14(火) 21:18:53

>>614
よくやるわ…それ。

618 ：デフォルトの名無しさん：2010/12/14(火) 22:30:09

さあ、今月で2010年も終了だ。
そこで現時点でどのバージョン管理システムを使うのがベターなのか考えてみよう！
条件は以下で、

・複数のプラットフォームで同程度の操作性が得られる。
・UIは色々選びたい。
・使用者のスキルによって破壊的な結果を招く事がない。
　※誤操作では破壊されない、但し、破壊しようという試みを防げうる必要はない。
・バイナリ、テキストなどを使用者が気にする必要がない。
・リソースの使用量を殊更気にする必要はないが、コストパフォーマンスは気になる。
・蛇足ながら、日本語で悩むのはなしで。

619 ：デフォルトの名無しさん：2010/12/14(火) 22:31:20

>>614
おい、嫌なことを思い出させるな

620 ：デフォルトの名無しさん：2010/12/14(火) 22:32:18

>>618

　な　い

この流れでわざとやってるだろw

621 ：デフォルトの名無しさん：2010/12/14(火) 22:44:20

>>614のような悲惨な事故にはリポジトリが別に存在するsvnやcvsが強いな

622 ：デフォルトの名無しさん：2010/12/14(火) 23:02:08

>>605
バイナリをメインで扱う仕事だと実際SVNとかかなり使いにくいから反発起こるのも判る。
ロックが必要な関係上、選択肢は事実上SVN・AlienBrain・Perforceしかないし。

623 ：デフォルトの名無しさん：2010/12/15(水) 08:22:00

>>622
VSSもロックできるよ

624 ：デフォルトの名無しさん：2010/12/16(木) 13:20:34

git がsubmoduleでディレクトリ分けしたリポジトリをgit svn dcommit できない
hgはできる？
perforceは？

625 ：デフォルトの名無しさん：2010/12/16(木) 13:47:23

>>624
hgはsubrepoというのがある。
http://mercurial.selenic.com/wiki/Subrepository

hgとsvnの連携だとhgsubversionというのがある
http://mercurial.selenic.com/wiki/HgSubversion

hgのsubrepoはgitとsvnをサブとして持てるみたい。
wikiにはsvnについては書いてあるが、gitは書いていないからどうなんだろう？

626 ：デフォルトの名無しさん：2010/12/20(月) 12:04:06

WinMergeから乗り換えるメリットあるのかね

3ファイルの比較、多数のVCSに対応した比較ソフトウェア「Diffuse」
http://www.moongift.jp/2010/12/20101218-2/#more-24015

627 ：デフォルトの名無しさん：2010/12/20(月) 12:21:31

>>626
gtkなので却下

628 ：デフォルトの名無しさん：2010/12/20(月) 12:58:57

gtk却下ならtortoise*使わないってことか

629 ：デフォルトの名無しさん：2010/12/20(月) 13:01:16

>>628
TortoiseHgはgtkからQtに移行中ですよ

630 ：デフォルトの名無しさん：2010/12/20(月) 13:14:34

TortoiseBZR も Qt
TortoiseSVN は独自？

631 ：デフォルトの名無しさん：2010/12/20(月) 13:20:10

プロジェクト名に普通名詞一語を付けるすべての開発者にイボ痔になる呪いをかけた

632 ：デフォルトの名無しさん：2010/12/20(月) 13:46:31

何のことかわからない俺には効果がない

アッー！

633 ：デフォルトの名無しさん：2010/12/20(月) 14:34:01

そして pwgen で付けたような
よくわからない名前のプロジェクトしか無くなった

634 ：デフォルトの名無しさん：2010/12/20(月) 17:30:57

>>631
gitとかmercurialとかbazaarとかか？

635 ：デフォルトの名無しさん：2010/12/20(月) 17:33:44

>>634
mercurialは形容詞。万歳！

636 ：デフォルトの名無しさん：2010/12/20(月) 17:36:40

水銀製剤という名詞用法もあるのだよ

637 ：デフォルトの名無しさん：2010/12/20(月) 18:29:48

オープンソースプロジェクト冬の時代の到来である

638 ：デフォルトの名無しさん：2010/12/21(火) 17:55:59

イボ痔によってもたらされる初めての大規模な開発の危機

639 ：デフォルトの名無しさん：2010/12/21(火) 17:58:40

でもPenとかRとか本当にググるのめんどいよな

640 ：デフォルトの名無しさん：2010/12/21(火) 18:01:37

そもそもC++とかがすでに

641 ：デフォルトの名無しさん：2010/12/21(火) 20:38:56

Clojureみたいにちょっとヒネった名前が
検索しやすくかつ覚え易くて好きだな

642 ：デフォルトの名無しさん：2010/12/21(火) 23:19:11

gnomeやKDE関連ツールみたいに、頭にgを付けるとかKに変えるとかすると
検索には便利だな

643 ：デフォルトの名無しさん：2010/12/21(火) 23:46:22

そこで例に gnome を出すのはどうかと。

644 ：デフォルトの名無しさん：2010/12/22(水) 12:40:44

racketで検索してもひっかからないけど
pltなら引っかかる

645 ：デフォルトの名無しさん：2010/12/24(金) 14:19:46

何だこの流れ

646 ：デフォルトの名無しさん：2010/12/24(金) 14:22:03

ゲイツはすでにイボ痔だし

>>640
C#がでたときもググりにくいと言われていた気がする。
ググるはすぐに対応した気がするが、他の検索エンジンが対応されていないことがある

647 ：デフォルトの名無しさん：2010/12/24(金) 14:23:18

>>646
TwitterでC#が検索できない。これはアンチWindowsぜいによるなんたらかんたら
http://search.twitter.com/search?q=%22C%23%22&lang=en

648 ：デフォルトの名無しさん：2010/12/25(土) 22:17:30

>>647
ググルつかおーぜ
http://www.google.com/realtime

649 ：デフォルトの名無しさん：2010/12/27(月) 15:28:37

個人でアプリを作るためにバージョン管理システムを使おうかと思うのだけど，お勧めのフリーソフトある？
ググってみてはいるが，個人向けのバージョン管理システムってどれがいいのかよくわからんorz

OSはWindowsで，Eclipseを使って開発する予定．

650 ：デフォルトの名無しさん：2010/12/27(月) 15:34:29

>>649
http://www.eclipse.org/egit/

651 ：デフォルトの名無しさん：2010/12/27(月) 15:34:40

文字コード絡みの面倒を抱えたくなければSubversionでいいんでね？

652 ：デフォルトの名無しさん：2010/12/27(月) 15:57:36

>>650 >>651
早めのレスthx
ちょっと調べてみるわ

653 ：デフォルトの名無しさん：2010/12/28(火) 05:43:33

Subversion関連サービスを提供する米WANDisco、Subversion改革計画を発表 - SourceForge.JP Magazine : オープンソースの話題満載
http://sourceforge.jp/magazine/10/12/27/0651200

654 ：デフォルトの名無しさん：2010/12/28(火) 07:20:58

>>653
Subversionが2011年に分散型としても使えるようになるという事ですね。
Subversionに対するGit/Merculial/Bazaarの利点は分散型である事だと思うのですが、
Subversionが分散型として使えるなら今後もSubversionが主流なのでしょうか？

655 ：デフォルトの名無しさん：2010/12/28(火) 07:47:02

SVNの今のmergeinfoが使い物にならないということか。
git/hgはハッシュとDAGでシンプルに実現しているのに、
SVNのリビジョン番号で直線的なモデルを変えない限り、複雑になるだけで使い物にならないでしょう。

656 ：デフォルトの名無しさん：2010/12/28(火) 07:53:41

確かに。svnが進化して便利になったとしたら、それは最早svnという名前の別のvcsだな。

657 ：デフォルトの名無しさん：2010/12/28(火) 07:58:36

>>654
分散型だけでなく完全なチェンジセット指向であることも利点。
.svnが各ディレクトリにあるのに対して、トップディレクトリに.git/.hgがある。
svnはディレクトリ・ファイル単位でチェックアウト・コミットできることは一見利点に見えるが、
今展開しているディレクトリ全体が整合性取れているかどうか保証ができない。
updateしないで、ブランチを作るためのcpコマンドをローカルでやると悲惨な結果になる。

658 ：デフォルトの名無しさん：2010/12/28(火) 08:08:25

だね。
各ディレクトリに.svnがあることの利点を捨てれば、それはもうSVNではないし、
各ディレクトリに.svnがあることのデメリットはかなり大きい。

単純なディレクトリのコピーにまで要注意な点は、かなり足を引っ張る・・・はず

659 ：デフォルトの名無しさん：2010/12/28(火) 11:50:02

>>653-654
どこにも「分散」とは書いてないが

660 ：デフォルトの名無しさん：2010/12/28(火) 11:52:58

http://www.wandisco.com/php/pr.php?rss=0&prdate=2010-12-20
http://www.wandisco.com/svndisco

661 ：デフォルトの名無しさん：2010/12/28(火) 13:00:14

Subversionの利点は個人的にはファイル名がUnicodeで扱われるということ。
GitかMercurialに移行したいと思ってもその点で躊躇してしまう。

662 ：デフォルトの名無しさん：2010/12/28(火) 13:51:05

ファイル名をASCIIだけでつければノープロブレム。

663 ：デフォルトの名無しさん：2010/12/28(火) 14:11:06

分散にしなかったらSubversionをどう改良するんだ？

664 ：デフォルトの名無しさん：2010/12/28(火) 14:15:34

Subversionの最大の利点は、Tortoise何とかが枯れてる事だと思う。
他人に使わせるなら、これ超重要。

665 ：デフォルトの名無しさん：2010/12/28(火) 14:30:39

>>664
枯れているか？古いWindows切り捨てらしいが。

666 ：デフォルトの名無しさん：2010/12/28(火) 17:13:52

>>661
Bazaarはファイル名をUnicode文字列として扱う

まあUnicodeにもUnicode特有の問題があるが……正規化とか

667 ：デフォルトの名無しさん：2010/12/28(火) 17:34:00

>>666
知ってるよ。だから抜いてるっしょ。でもBazaarは、シェアがちょっと不安。
よくMercurial/Gitと並んで書かれるけど、どうも今一つ垢抜けないというか・・・

Mercurialは色んなオープンソースで採用されてるし
GitはEclipseで入りやすいから、どっちかがファイル名とコミットコメントを
Unicodeにしてくれたら・・・と思う。

668 ：デフォルトの名無しさん：2010/12/28(火) 17:40:07

開発元が同じUbuntuを除けば、EmacsやMySQLがBazaarを採用してる大手かな

669 ：デフォルトの名無しさん：2010/12/28(火) 18:25:17

>>665
お前は何を言っているんだ

670 ：デフォルトの名無しさん：2010/12/28(火) 18:33:20

>>667
同感。gitかhgでのファイル名の扱いが改善されれば…
でもそうはならないでしょうね
そのあたりの重要性が理解されてたら
ここまで普及する前に、初期の段階で改善されてたはずだし…

671 ：デフォルトの名無しさん：2010/12/28(火) 18:37:20

>>670
http://hibari.2ch.net/test/read.cgi/tech/1251208950/439

672 ：デフォルトの名無しさん：2010/12/28(火) 19:33:19

開発のコアメンバーが、「DVCSはソースコードを管理するもんだ。どこの国の人間だろうが
ソースコードのファイル名に英語以外を使う奴はアホ」、とか発言しちゃうぐらいだし。

673 ：デフォルトの名無しさん：2010/12/28(火) 19:42:31

バイト列で扱うのも利点がないわけじゃない

内部コードをUnicode系に固定すれば、Unicodeとロケール毎の文字集合の間で変換が起こる
その分計算量が増えるのは無視するにしても、一対一対応してない文字の扱いが難しい
しかも正規化や合成文字についても考える必要がある
要するにUnicodeも銀の弾丸にはならない

俺は基本的にBazaarを使って、既にGitを使ってる所ではGitを使って
MercurialやSubversionもどうしても使わなければ使うけど

674 ：デフォルトの名無しさん：2010/12/28(火) 19:46:35

Bazaar+Eclipseならどのプラグインがいいかな？

Unicodeが問題解決にならないのは、Macの正規化を見ても分かるんだが
それでも問題を減らせると思うんだ・・・・
SubversionやBazaarが実現している訳で。。。。

675 ：デフォルトの名無しさん：2010/12/28(火) 19:56:50

Javaのクラス名を日本語にするわけ？

676 ：デフォルトの名無しさん：2010/12/28(火) 20:17:54

文書や画像のファイル名をローマ字綴りにする人は
漢字や仮名を使った方がいいんじゃね
あとindexesとかwritedとか書く人とか

>>674
bzr-eclipseって公式プラグインがあるがEclipseを使わないからいいかどうかわからん
利用者少ないからチケット送る羽目になるかもしれん

677 ：デフォルトの名無しさん：2010/12/28(火) 20:23:13

http://d.hatena.ne.jp/odz/20061220/1166648625

678 ：デフォルトの名無しさん：2010/12/28(火) 20:25:49

>あとindexesとかwritedとか書く人とか

わざとやってる人（または自動生成器）ならいくらでもいるぞ

679 ：デフォルトの名無しさん：2010/12/28(火) 20:42:51

じゃあ今度からそれでいいや
ついでに形容詞も全部more/most xxxにしとこう

680 ：デフォルトの名無しさん：2010/12/28(火) 20:46:31

オーウェルのやつ、実際に似たような人工言語なかったっけ？

681 ：デフォルトの名無しさん：2010/12/28(火) 21:00:17

datasも気になるw

682 ：デフォルトの名無しさん：2010/12/28(火) 21:11:13

だからってdatumとは・・・

683 ：デフォルトの名無しさん：2010/12/28(火) 21:12:38

データを扱う場合に一件に限定することってまずないから
dataで問題ないと思う

684 ：デフォルトの名無しさん：2010/12/28(火) 21:22:03

んじゃmediaは?

685 ：デフォルトの名無しさん：2010/12/28(火) 21:27:50

複数系・単数形単体の問題よりもそれに応じた動詞の変化を忘れることが多いから困る

686 ：デフォルトの名無しさん：2010/12/28(火) 21:52:19

>>680
esperanto

687 ：デフォルトの名無しさん：2010/12/28(火) 21:54:11

>>672
酷い話ですね…
ソースコードしかバージョン管理しない
と思い込むヤツのほうがアホだよな…

と思ったが、
このツールはソースコード以外は管理するつもりがない
と明言してるのは、それはそれで意味があることかもしれない
ドキュメント等は別のツール、つまりgitやhg以外で管理しろ、
使い分けろ、なんでもコレでやろうとするな、
ということなんでしょうかね

688 ：デフォルトの名無しさん：2010/12/28(火) 22:27:30

>>687
ソースと資料を同じレポジトリに突っ込んでたら
ドキュメントのサイズが膨れ上がってドキュメント専用のレポジトリが
欲しくなることは多々あるんだけど、
それでもソースや設定ファイル周りとかで日本語ファイル名を使いたいトコもある。
全部英語だとファイル名の見た目にメリハリがなくて見にくいんだな。
何にせよ、エンコードが沢山あるってのが問題で
Unicodeはその問題を解決しようとしたのに正規化とかワケワカラン問題を産んでしまった。

こういうのって、英語圏の連中にとっては問題の理解が難しいわけで
それだけで手を上げたくなる気持ちもわからんでもない。
でも、それでも・・・ちょっと使いにくいんだよな・・・CVS時代に逆行したようで・・・

689 ：デフォルトの名無しさん：2010/12/28(火) 22:59:17

正規化はまあいいんだがUnicodeとJISが並立しているのが面倒くさい

統合漢字/互換漢字/異体字セレクタはJISでも包含基準や改定に伴う追加があるから
どっちにせよ似たようなことを考える必要があるが

690 ：デフォルトの名無しさん：2010/12/28(火) 23:41:20

「＼」問題を日本人でさえ理解していない人間が多いのに欧米人にどうやって理解させる？
欧米人にとっては大文字小文字の方がはるかに重要。

691 ：デフォルトの名無しさん：2010/12/28(火) 23:56:59

>>690
そ、それは日本人自体が招いた問題だから自ら問題解決すべきでは？＞「￥」「＼」問題

692 ：デフォルトの名無しさん：2010/12/29(水) 00:15:57

nkfのオプションの多さを考えたら、ファイル名を「文字」として扱うことが如何にナンセンスか分かると思うが。

693 ：デフォルトの名無しさん：2010/12/29(水) 00:17:07

なぜ日本も韓国もバックスラッシュの位置に通貨記号を割り当てたんだろうな……

694 ：デフォルトの名無しさん：2010/12/29(水) 00:49:42

韓国は日本の真似しただけだろニダ

695 ：デフォルトの名無しさん：2010/12/29(水) 01:01:35

http://ja.wikipedia.org/wiki/ISO/IEC_646
割り当てていいよと言われたからで FA

696 ：デフォルトの名無しさん：2010/12/29(水) 01:04:44

むしろ何で\がパスデリミタ…

697 ：デフォルトの名無しさん：2010/12/29(水) 01:16:00

>>696
マイクロソフトがCP/M向けに出していたソフトでは、コマンドラインのスイッチ
はスラッシュで始まっており（例: M80 =FOO.MAC /R）、PC DOS/MS-DOS 1.xでは
これがOS標準の書式として受け継がれた。そのため、PC DOS/MS-DOS 2.xで階層
ディレクトリを導入する際に、UNIXのようにパス名の区切りにスラッシュを使う
ことができず、バックスラッシュを使うことになった。しかし、ASCIIのバック
スラッシュはISO 646各国版で置き換えが認められており、たとえば日本のJIS X
0201では円記号になっているため、日本のPCではパス名の区切りが円記号で表示
されることになった。

引用元： http://ja.wikipedia.org/wiki/CP/M#MS-DOS.E3.81.A8.E3.81.AE.E6.AF.94.E8.BC.83

698 ：デフォルトの名無しさん：2010/12/29(水) 01:46:13

>>695
だから、割り当てなさい！と言われたんじゃなくて、割り当てていいよ┐(ﾟ～ﾟ)┌
と言われて割り当てたのは日本人自身なんだってば。

699 ：デフォルトの名無しさん：2010/12/29(水) 01:55:43

Unicode vs バイト列よりも、そもそも各ファイルシステムで使える文字使えない文字が一致してなかったり
大文字小文字の区別があったりなかったりするけどそのへんはVCSによってどういう対応してるんだろ。放置かな。
http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E5%90%8D#.E4.BD.BF.E7.94.A8.E3.81.8C.E4.B8.8D.E5.8F.AF.E8.83.BD.E3.81.AA.E8.A8.98.E5.8F.B7

700 ：デフォルトの名無しさん：2010/12/29(水) 02:19:56

ファイル名の命名規則を話しだすと
7bit文字に収めろだの
記号を使うなだの
全部小文字にしろだの
全部大文字にしろだの
ドット区切りサフィックス(つーか拡張子)は3文字以内に汁だの
8+3に収まってないと怒り狂われるだの
プリフィクス+連番(PRG0000)以外は認めないだの

未だにファイル名に日本語が必要な場面が思い浮かばないぜ。

701 ：デフォルトの名無しさん：2010/12/29(水) 03:30:38

>>699
MercurialとTortoiseHgのWindowsインストーラで配布されているものは、
CaseFoldExtensionという拡張がバンドルされているみたい
http://mercurial.selenic.com/wiki/CaseFoldExtension

702 ：デフォルトの名無しさん：2010/12/29(水) 03:40:45

bzrの場合は
http://doc.bazaar.canonical.com/latest/developers/case-insensitive-file-systems.html
大文字小文字の違いだけの同じファイル名のファイルが既にある時は、そのファイル名の方向に正規化する

703 ：デフォルトの名無しさん：2010/12/29(水) 14:51:34

>>687-688
例えソースコードしかバージョン管理しなくてもいくらでもバカが
Windowsのエクスプローラーで「～～ - コピー」「～～ - コピー (2)」「～～ - コピー - コピー」みたいなファイルをリポジトリに入れてくるわけだが…

プログラマー向けだしというのもわかるし、
そういうのではない一般向けのDropboxは考慮されてるしな(Macとのやりとりは知らん)

Windowsならcygwin 1.7のようにWindowsのUNICODEをUTF-8に変換してその手のアプリに渡すのがまだ楽そうだわ
そうやっているとUnixのファイルシステムで作れないファイルを入れたりもできてしまうが、それは文字コードの問題じゃないしな

704 ：デフォルトの名無しさん：2010/12/29(水) 15:00:11

>>703
> 例えソースコードしかバージョン管理しなくてもいくらでもバカが
> Windowsのエクスプローラーで「～～ - コピー」「～～ - コピー (2)」「～～ - コピー - コピー」みたいなファイルをリポジトリに入れてくるわけだが…
githubのpull リクエストみたいにpullしないで放置プレイにする

> Windowsならcygwin 1.7のようにWindowsのUNICODEをUTF-8に変換してその手のアプリに渡すのがまだ楽そうだわ
> そうやっているとUnixのファイルシステムで作れないファイルを入れたりもできてしまうが、それは文字コードの問題じゃないしな
？？？

705 ：デフォルトの名無しさん：2010/12/29(水) 15:17:06

>>704

> >‎ Windowsならcygwin 1.7のようにWindowsのUNICODEをUTF-8に変換してその手のアプリに渡すのがまだ楽そうだわ
> >‎ そうやっているとUnixのファイルシステムで作れないファイルを入れたりもできてしまうが、それは文字コードの問題じゃないしな
> ？？？

>>699のようなことかと思う。下手するとupdateやpullできなくなる。

706 ：デフォルトの名無しさん：2010/12/29(水) 15:31:42

ext2/ext3は'/'と'\0'以外に制約無いし、'/'=0x2FでCP932の２バイト目には出てこないよ

707 ：デフォルトの名無しさん：2010/12/29(水) 21:38:38

496 名前：デフォルトの名無しさん[sage] 投稿日：2010/12/29(水) 10:14:21
SVNからMercurialに移行するべき8つの理由
http://anlyznews.blogspot.com/2010/12/svnmercurial8.html

497 名前：デフォルトの名無しさん[sage] 投稿日：2010/12/29(水) 11:10:26
>496
何でこんな嘘付くの？
>‎ TortoiseSVNの姉妹品TortoiseHgが安定して動く。
>‎ 最近のバージョンはMercurialもセットで配布され、インストールも簡単になっている。
>‎ 今すぐグラフィックス・デザイナー等に利用を推奨できるのは利点だ。

504 名前：デフォルトの名無しさん[] 投稿日：2010/12/29(水) 16:52:02
>>497
その嘘つきが、ノイズを増幅させている・・・
http://anlyznews.blogspot.com/2010/12/gitmercurial8.html

708 ：デフォルトの名無しさん：2010/12/29(水) 23:15:36

やっぱbzrだな。

709 ：デフォルトの名無しさん：2010/12/29(水) 23:50:22

ArchやDarcsのことも時々でいいから思い出してください

710 ：デフォルトの名無しさん：2010/12/30(木) 00:47:49

Bazaarは日本語ファイル名も問題なさそうだし、付属のBazaar Explorerも悪くないが、ブランチが切りづらい。

711 ：デフォルトの名無しさん：2010/12/30(木) 06:55:45

TortoiseHG単体でバージョン管理が出来るようになったら本気出すけど
>>497ってそうなったってこと？

712 ：デフォルトの名無しさん：2010/12/30(木) 07:15:31

>>711
http://hibari.2ch.net/test/read.cgi/tech/1251208950/496-498
コピペ元のMercurialスレで、2番目は正しいと突っ込まれています。
詳しく知りたければMercurialスレで聞いてください。

713 ：デフォルトの名無しさん：2010/12/30(木) 07:59:50

http://hibari.2ch.net/test/read.cgi/tech/1251208950/507-509
MercurialスレでSVNのロック機能不用論がでてますが、
総合スレであるここで突っ込ませてください。
ロック機能は複数の人による同時編集ができない代わりに
マージが不要になる利点があります。

ソフトウェア開発では同時編集禁止は不便なので
ロックせずにマージで頑張るバージョン管理システムが広まりました。
しかしアイコンのようなバイナリファイルはマージするのが困難なので
同時に一人しか修正しない事を保証するロックに頼らざるを得ません。
ロック機能でもある程度は共同作業が楽になります。
ですからバイナリファイルも扱わせるならロック機能は必須でしょう。

714 ：デフォルトの名無しさん：2010/12/30(木) 08:12:52

>>713
ロックは前スレでやった

715 ：デフォルトの名無しさん：2010/12/30(木) 10:47:24

ロック不要論者は馬鹿すぎて扱いに困る
論拠を聞いても結局「俺が使わないから要らない」以上のことは何も言わないし

716 ：デフォルトの名無しさん：2010/12/30(木) 11:35:54

>713
ロック不要論じゃなくて、有った方がいいけど、無くてもまぁ運用で或る程度は何とか
なるじゃないのって話でしょ。人数や求める厳密さによるけど。

Subversionでもロックの不徹底は多そうだし。共有ディレクトリやDropboxだけで
やってるとこも、そのへん、なあなあでしょ？

717 ：デフォルトの名無しさん：2010/12/30(木) 11:55:01

VCSはコミュニケーションツールではない
バイナリでなくてもコンフリクトはおきる
機械的なマージは時として信用できない

718 ：デフォルトの名無しさん：2010/12/30(木) 11:59:22

VCSは最低限のインフラと捉えた方がいいのは確か
チャットやMLやWikiなどを併用していない開発体制ではどうにもならんところはあるさ

719 ：デフォルトの名無しさん：2010/12/30(木) 12:08:09

VCSとは独立して、ネットワーク経由でファイルのアノテーションを共有出来るツールがあると
便利かもなぁ。ロックとかコメントとか。

720 ：デフォルトの名無しさん：2010/12/30(木) 12:36:30

>>719
あーそれ良いね。VCSにロックは要らないと思うけど、
アドバイザリなロック情報を1アクションで共有出来るような
ツールがあったら、何かと便利な気がする。

721 ：デフォルトの名無しさん：2010/12/30(木) 13:55:06

それは興味深いな

722 ：デフォルトの名無しさん：2010/12/30(木) 15:49:34

>>718
上で出た共有ディレクトリやDropboxの運用だって、コミュニケーションなしじゃやってらんないしな

>>719
それこそ、チケット管理のシステム使ったり、コミットログやBTSのログをIRCに流すとかでいいんじゃないのか

あーでも、今メールで流してるけど数多すぎて全然みないなw

723 ：デフォルトの名無しさん：2010/12/30(木) 15:52:25

プログラマー向けにはちゃちだと思っていたDropboxをデザイナが便利に使っているのを見て前にヒアリングしてたんだけど、
そのなかでいいと思ったのは「更新されたり、衝突したらポップアップで通知してくれること」だったわ

Windowsのクライアントの話なので他もそうかはわからんが

724 ：デフォルトの名無しさん：2010/12/30(木) 17:01:25

>>702
ちなみにバグってるけどな。

725 ：デフォルトの名無しさん：2010/12/30(木) 17:35:18

Bazaarの利用テストをしてみた。

・日本語コミット文、日本語ファイル名がOK。
→ GitやMercurialは日本語ファイル名を入れると、Windows - Linuxでリポジトリの共有が不可能になる。

・通しのリビジョン番号で操作できる
→ Mercurialと同じで、ハッシュ値のGitよりは操作が楽。

・commitは自由に取り消せる（uncommit）。
→ Gitのreset --hardと同じで、1回より取り消せないMercurialよりは手軽。ただし、管理上はマイナスかも。

・ブランチの作成時に、ディレクトリ（フォルダ）の指定がいる。
・ブランチを変更するときは、作業ディレクトリの変更がいる。
→ ブランチ名だけでいいGit、自動的に無名ブランチができるMercurialの方が楽。

あまり使い込んでいないので誤解があるかも知れないが、分岐やマージの頻度が低い所だと便利かも知れない。

726 ：デフォルトの名無しさん：2010/12/30(木) 17:41:37

>>725の補足だが、uncommitでコミット取り消しした後に、revertでワーキング・ディレクトリも戻そうとしたときに、以下のエラーが出た。

Unable to obtain lock file:///C:/path/to/directory/ held
by おれさま様 <[email protected]>
at Bill.G.World [process #4812], acquired 81 seconds ago.

.bzr/checkoutを削除したらrevertできるようになったが、Windows版のBazaarは、まだバグが多いのかも知れない。

727 ：デフォルトの名無しさん：2010/12/30(木) 17:56:42

>>725
> ・日本語コミット文、日本語ファイル名がOK。
> → GitやMercurialは日本語ファイル名を入れると、Windows - Linuxでリポジトリの共有が不可能になる。
いつまでも、こんな無知を晒すのやめてくれない？

728 ：デフォルトの名無しさん：2010/12/30(木) 17:59:40

> ・通しのリビジョン番号で操作できる
> → Mercurialと同じで、ハッシュ値のGitよりは操作が楽。
bzrのリビジョン番号あとから変わるらしいじゃん。
あと、commit id、何あれ？本当に分散型なの？

729 ：デフォルトの名無しさん：2010/12/30(木) 18:02:36

>>727
GitとMercurialで、日本語ファイル名を取り扱う方法を教えてくれ。もちろんcygwin無しでね。

730 ：デフォルトの名無しさん：2010/12/30(木) 18:03:39

>>725
> ・commitは自由に取り消せる（uncommit）。
> → Gitのreset --hardと同じで、1回より取り消せないMercurialよりは手軽。ただし、管理上はマイナスかも。
hg backout/hg strip

731 ：デフォルトの名無しさん：2010/12/30(木) 18:10:54

>>729
「リポジトリの共有」なら日本語関係無いよね？

732 ：デフォルトの名無しさん：2010/12/30(木) 18:12:21

>>730
MQのhg-stripで消せばいいのね。hg-backoutは、履歴に残るよね？

733 ：デフォルトの名無しさん：2010/12/30(木) 18:13:20

>>731
GitとMercurialは、文字コードが違う処理系でも共有はできるが、日本語ファイル名は化けると言いたいわけですね。

734 ：デフォルトの名無しさん：2010/12/30(木) 18:17:04

>>733
人間の目から見て特定のロケールで「化ける」だけ。Windowsだとチェックアウトできないかもしれないが。

735 ：デフォルトの名無しさん：2010/12/30(木) 18:19:47

「リポジトリの共有」はgitならbare、hgでもbareもどき。作業ファイルの展開とは関係ない。

736 ：デフォルトの名無しさん：2010/12/30(木) 18:24:09

>>734-735
なるほど。ところで、CP932のMS-WindowsとUTF-8のLinuxの混在環境で、日本語ファイル名をつけたときにGitは実用的に問題はないの？
人の目で見て化けていて、チェックアウトできないかも知れないだけだから問題ない？

737 ：デフォルトの名無しさん：2010/12/30(木) 18:29:43

>>736
CP932/CP950以外では問題なく使われている

738 ：デフォルトの名無しさん：2010/12/30(木) 18:29:50

>>728
>bzrのリビジョン番号あとから変わるらしいじゃん。
>あと、commit id、何あれ？本当に分散型なの？

詳しくよろしく。

739 ：デフォルトの名無しさん：2010/12/30(木) 18:36:13

>>738
http://hibari.2ch.net/test/read.cgi/tech/1284467898/59

740 ：デフォルトの名無しさん：2010/12/30(木) 18:41:48

>>739
それで生じるデメリットって何？

741 ：デフォルトの名無しさん：2010/12/30(木) 18:46:49

>>740
メールアドレス-時刻-ごくみじかいハッシュ
でしょ、メールアドレス、時刻は偽造可能。
ハッシュとして長さが短すぎ。
git/hgはハッシュの最初の数文字入れればリビジョン特定できるが、それもできない

742 ：デフォルトの名無しさん：2010/12/30(木) 18:47:22

>>728
bzrは分散型だと思わないほうがいい。
ローカルコミットできる中央型

743 ：デフォルトの名無しさん：2010/12/30(木) 18:48:51

>742
どのような点で？

744 ：デフォルトの名無しさん：2010/12/30(木) 18:49:25

bzrのリビジョン番号は、 branch.conf で append_revisions_only を有効にすると単調増加になって、
メインラインを変更するようなpushを許さなくなる。
append_revisions_only は今後デフォルトになっていく方向に話が進んでる。

bzrのrevision_idがハッシュ値じゃない事には利点もあって、URLの様にいろいろなスキームで
revision_idを作成できる。例えば、 git から pull したリビジョンには、 git:<gitのリビジョンID>
というスキームでリビジョンIDを付けている。

745 ：デフォルトの名無しさん：2010/12/30(木) 18:53:16

>>741
狙ってリビジョンIDを衝突させることができることを問題にしているの？
なら、リビジョンIDは好きに作れるから、別に偽装とかしなくていいよ。

で、狙ってリビジョンIDを衝突させられることのどこが問題なの？

746 ：デフォルトの名無しさん：2010/12/30(木) 18:58:17

>>741
昨日、嫁に三行半を突きつけられた隣の席の鈴木が、Bazaarだと自棄になってCommit IDを衝突させてくるってこと？

747 ：デフォルトの名無しさん：2010/12/30(木) 19:00:38

それは課長や部長が解決する問題であって、VCSが解決する問題ではない
・・・と思う

748 ：デフォルトの名無しさん：2010/12/30(木) 19:18:40

>744
単調増加の意味するところがいまいちよく分からんが、とにかく、
今までDVCS比較話で聞いた事のない興味深い話であった。

749 ：デフォルトの名無しさん：2010/12/30(木) 19:23:52

append_revisions_only
“True”に設定されていればリビジョンはログにのみ追加され、削除されません。
この設定が有効なブランチは、他のブランチのログがそれ自身のリビジョンより長い場合、別のブランチからのみpullできます。
通常これは bzr init --append-revisions-only によって設定されます。

http://twitter.com/#!/methane/status/11806331434442752
append_revisions_only = True に設定したブランチでは、連番のリビジョン番号が固定され、ID替わりに使えること。
中央リポジトリ上のブランチはこの設定がおすすめ。

750 ：デフォルトの名無しさん：2010/12/30(木) 19:46:31

>749
なるほど、全然分からん。

751 ：デフォルトの名無しさん：2010/12/30(木) 19:46:58

もうちょっと詳しく言うと、bzrはgitやhgと違って、「メインライン」という概念があって、
履歴のウチ並列して存在するラインの片方がメイン、残りがマージされたブランチという扱いになる。

通常はメインラインのウチのリビジョンだけを表示することで、別ブランチで開発中にコミットされた
細かいリビジョンを無視して、それをメインラインにマージしたコミット１つにまとめて表示できる。
なので、ローカルで作業中に作ったゴミみたいなコミットをまとめて綺麗な１つのコミットにするみたいな
作業が要らない。
(もちろん、メインラインを無視して、全ブランチが同等という運用をしても良い)

なんだけど、だれかがローカルのブランチから中央のブランチをマージすると、そのローカルでは
メインラインはローカルブランチに、中央ブランチはサブラインになって、それを push すると
中央ブランチのメインラインが置き換わってしまう。

中央 1:A - 2:B - 3:C - 4:D
ローカル 1:A - 2:B - 3:X - 4:Y -(中央からマージ)- 5:Z
(この状況でローカルから中央に push)
中央 1:A - 2:B - 3:X - 4:Y - 5:Z (中央のサブライン 2:B - 2.1.1:C - 2.1.2:D - 5:Z)
(リビジョン番号3と4に割り当てられているリビジョンが変わってる)

これを許さないのが append_revisions_only

752 ：デフォルトの名無しさん：2010/12/30(木) 20:20:04

bzrはrebase文化でないわけ？

753 ：デフォルトの名無しさん：2010/12/30(木) 20:28:40

>>751
さんくす、何となく分かった。

754 ：デフォルトの名無しさん：2010/12/30(木) 20:43:38

>>752
rebase は拡張としては用意されているけど、bzr-svnとかbzr-gitとかでよく使われているだけで、
bzrで管理されているプロジェクトでは普通にマージを使ってると思う。

755 ：デフォルトの名無しさん：2010/12/30(木) 20:45:00

>>752
単純に言うとBzrにはブランチがない。必ず1列に並ぶ。

756 ：デフォルトの名無しさん：2010/12/30(木) 22:03:39

>>751のおかげで、Mercurialを使いつづける勇気が沸いた。

757 ：デフォルトの名無しさん：2010/12/30(木) 23:18:26

516 名前：デフォルトの名無しさん []： 2010/12/30(木) 23:17:09
GitとMercurialの比較の図が、どうも胡散臭いんだが・・・

504 名前：デフォルトの名無しさん[] 投稿日：2010/12/29(水) 16:52:02
>>497
その嘘つきが、ノイズを増幅させている・・・
http://anlyznews.blogspot.com/2010/12/gitmercurial8.html

758 ：デフォルトの名無しさん：2010/12/30(木) 23:35:25

>>757
ぜひbzrとhgの比較もしてもらいたいものですね！

759 ：デフォルトの名無しさん：2010/12/30(木) 23:47:24

>>758
http://www.atmarkit.co.jp/fjava/rensai4/devtool03/devtool03_5.html

760 ：デフォルトの名無しさん：2010/12/31(金) 00:03:26

>751
おかげで、bzrは候補から外す事にしたよ。
つーか、この件、マジで初耳なんだが。
今までほんとに使ってるbzrユーザは居なかったのか？

761 ：デフォルトの名無しさん：2010/12/31(金) 01:09:51

>>760
bzrユーザーは日本語使えれば何でもいい奴らしかいないｗｗｗ

762 ：デフォルトの名無しさん：2010/12/31(金) 01:12:34

>>760
日本語ファイル名が使えるのと、Bazaar Explorerは悪く無いと思う。
>>751のリビジョン番号の変化は再現できていないけど、>>751に解決方法は書いてあるし問題ない。
しかし、ディレクトリがブランチなので、他の分散バージョン管理システムに比べると、かなりSVNに近いのがどうも気になる。

763 ：デフォルトの名無しさん：2010/12/31(金) 01:47:33

なるほど、pushされるとリビジョン番号が変化する。

764 ：デフォルトの名無しさん：2010/12/31(金) 02:00:11

bzr init --append-revisions-only して以下のエラーが出たときは、どうすればいいんだろうか？

bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "bazaar/trunc/".

765 ：デフォルトの名無しさん：2010/12/31(金) 07:34:28

>>761
そういう奴はSubversionを使う

766 ：デフォルトの名無しさん：2010/12/31(金) 10:32:24

>>760
> 今までほんとに使ってるbzrユーザは居なかったのか？
svnユーザでbzrを検討したユーザはあまりの使えなさに幻滅してsvnに戻る
git・hgユーザはbzrは眼中にない・少し触って重くて止める
cvsからbzrに移ったEmacsは特異な存在

767 ：デフォルトの名無しさん：2010/12/31(金) 16:33:42

Bazaarで--append-revisions-onlyを使ってみた。

1. 共有リポジトリからpull
2. ローカルリポジトリで修正
3. 共有リポジトリが誰かに更新される
4. 共有リポジトリにpushに失敗（bzr: ERROR: Operation denied because it would change the main history, ...）
5. ローカルリポジトリをuncommitする
6. ローカルリポジトリの変更差分をとる
7. 共有リポジトリからpull
8. ローカルリポジトリで変更差分を適用
9. 共有リポジトリが誰かに更新される
10. (4)へ戻る

--append-revisions-onlyは友達の輪に入れないオレには無理なようだ。

768 ：デフォルトの名無しさん：2010/12/31(金) 17:08:51

つまり、こういう事か。

bzr　　リア充向け
git　　 nerd向け
hg　　それ以外のhuman beings向け

769 ：デフォルトの名無しさん：2010/12/31(金) 17:33:33

ああ、俺は半端者だからBazaarとGitは使うけどMercurialは使わないのか

リア充はOS XのTime Machineを使うような気もするが

770 ：デフォルトの名無しさん：2010/12/31(金) 18:30:33

Time Machineはバックアップ以外の用途に使えるのだろうか。
Mercurialはpush時に衝突が発生しないから楽だよ。

771 ：デフォルトの名無しさん：2010/12/31(金) 19:17:39

いや、バックアップ用
Windowsのシステムの復元がデータ領域を対象にした感じ

772 ：デフォルトの名無しさん：2010/12/31(金) 21:36:13

>>764
trunkのチェックアウトを別に作って、trunkに対して自分のブランチをマージする。
Launchpad系では通常、開発者はtrunkへpushせず、自分のブランチを公開してtrunkに
マージする準備ができたらマージリクエストする。
コミッターがそのブランチをレビューし、OKならtrunkへマージする。

社内ユースなどで、みんながどんどんtrunkへコミットするスタイルの場合は、
1) (svn風) trunkをチェックアウトして直接その上でコミットする。trunk以外のブランチは欲しい時だけ作る。
2) (git風) append_revisions_only = False にし、みんな適当に push する。

Launchpad風、svn風、git風、どのワークフローにも対応できるのが利点と言えるけど、
逆にそれで混乱してしまう人もいる。

773 ：デフォルトの名無しさん：2010/12/31(金) 21:47:28

>>772
> 2) (git風) append_revisions_only = False にし、みんな適当に push する。
gitでみんな適当になんかpushしてねーよ

774 ：デフォルトの名無しさん：2010/12/31(金) 21:53:03

>>772
さんくす。共有リポジトリにpushする運用だと、Bazaarはちょっと使いづらいね。

775 ：デフォルトの名無しさん：2010/12/31(金) 22:50:39

>>773
言い方が悪かったな。すまん。
ちゃんとしたプロジェクトではgitでもLaunchpadと同じマージリクエスト＆コードレビュースタイル
なのは判ってる。

身内の少人数内でレビュー必須みたいなしっかりしたフローが無い状況における、
ワークフローとして、svnとgitの典型的なスタイルを挙げたつもり。
そういう状況でgitだとみんなでtrunkにpushしちゃうんだけど、俺の周辺だけ？

776 ：デフォルトの名無しさん：2010/12/31(金) 22:53:24

>>774
どう使いにくそう？
append_revisions_onlyは今のところデフォルトでFalseなのでpush自由だし、
デフォルトTrueになってもちゃんとFalseにするオプションは用意される。
ログを見るときもデフォルトではメインラインだけを表示するけど、サブラインも
表示するオプションが用意されている。

みんなで適当にpushできて、連番のリビジョン番号は恒久的なIDがわりには使えない、
Mercurialと特に違いは無いと思うけど。

777 ：デフォルトの名無しさん：2010/12/31(金) 23:07:24

>>776
> みんなで適当にpushできて、
・push先に新たなheadを作らない
・svn的ブランチは別リポジトリに分ける
・bzrの独自の概念だと言っている「メインライン」は、
　hgではリポジトリの分離と「名前付きブランチ」

> 連番のリビジョン番号は恒久的なIDがわりには使えない、
hgの場合、リビジョン番号はリポジトリで固有というコンセンサスが出来ているけど、
bzrの場合出来ているの？

778 ：デフォルトの名無しさん：2010/12/31(金) 23:07:38

罵倒は2chの風物詩として違いは参考になる。それぞれがみな異色に見えるなw

>>729
おーっとここで将軍様「トラを捕まえろ一休、屏風から出さずにな」と

>>733
どうしてもcygwinが嫌なら仮想マシンでファイル共有してLinuxからWindowsのファイルをバージョン管理すればいいよ
gitはそれでやってるわ。面倒なときはcygwinのgit使う

>>736
UTF-8のファイル名をコミットするのはともかく、CP932は他の環境だとかなり大変だから
CP932でコミットするのは本当におすすめできないな。
今の時代、将来的に他の環境で使うことはないなんていいきれん。

別にファイルの中身の文字コードやコミットログはなんとでもなるんだがな

779 ：デフォルトの名無しさん：2010/12/31(金) 23:15:29

>>776
> みんなで適当にpushできて、連番のリビジョン番号は恒久的なIDがわりには使えない、
> Mercurialと特に違いは無いと思うけど。
「公開リポジトリ」上で"hg strip"、"hg rebase"などの履歴の編集はまずしない。
この場合、公開リポジトリのリビジョン番号は０からの連番で変更されることはない。
だから、hgweb、bitbucketでのリビジョン番号は恒久的なIDとして捉えても良い。
でも、hg logなどでの出力の"123:abcdefg"のようなスタイルの方が望ましい。

780 ：デフォルトの名無しさん：2010/12/31(金) 23:21:22

>>765
うちは面倒なので中央svnにして使うやつはgit-svnなりだなw
こちらの使う範囲内では、UTF-8環境ならgit-svnで日本語ファイル名を扱えることは確認済み

しかしCygwinのgitkはtkのバージョンのせいか設定が悪いのか何故か化けるし不安定

git-svnはcygwinは1.7だし大丈夫だと思うが、Linuxのディストリによってはパッケージのものは古くて不便なので注意

781 ：デフォルトの名無しさん：2010/12/31(金) 23:32:29

bzrは、設計のセンスが悪いなぁ。

782 ：デフォルトの名無しさん：2010/12/31(金) 23:37:35

>>781
Subversionの真似をしているから当たり前

783 ：デフォルトの名無しさん：2011/01/01(土) 00:06:11

>>776
> どう使いにくそう？
1. append_revisions_only = Falseだと、pushしやすいがリビジョン番号が変化する。
2. append_revisions_only = Trueだと、pull requestを送る運用になる。
3. checkoutをすると、SVNと運用が変わらない（？）

共有リポジトリをファイル共有の目的でも使いたい現場だと、(2)は使いづらそうな感じはする。
イメージしている運用スタイルだと、リビジョン番号の変化に慣れるべきなのは分かった。

784 ：デフォルトの名無しさん：2011/01/01(土) 00:10:30

>>778のGitの運用を見ていると、日本語ファイル名は重要な問題な気がしてくる。

785 ：デフォルトの名無しさん：2011/01/01(土) 00:17:31

>>776
Mercurialは、コミットの統合や削除を意識して行わない限り、あるリポジトリの中のリビジョン番号は変化しない。
Bazaarだとオペレーターが気づかない間に、同じリビジョン番号が、他のチェンジセットに入れ替わる気がするんだが。
uncommitとかの狙いが外れて気づかなかったら大惨事。

786 ：デフォルトの名無しさん：2011/01/01(土) 00:45:14

gitとmercurialとbazaarはbranchの概念が3者共全く違うという所から
考え直した方がいいと思う

787 ：デフォルトの名無しさん：2011/01/01(土) 00:49:48

>>786
gitとmercurialはそんなに違わない。bazaarがsubversionを意識し過ぎ

788 ：デフォルトの名無しさん：2011/01/01(土) 01:07:50

>>786
ブランチの概念、かなり違うね。

>>787
Mercurialは全てのチェンジセットが独立したブランチみたいなもんだから、

・gitと異なり、ブランチを作成しなくても、自動で名前無しブランチができる。
・gitと異なり、同一（名前付）ブランチ内で、さらに分岐ができる。
・gitと異なり、pushでconflictは起きない。同じチェンジセットに編集を加えても、独立に分岐したチェンジセットになる。
・gitと異なり、ある（名前付）ブランチのチェンジセットを消すと、子孫にあたる別のブランチも消える（hg-strip）。

789 ：デフォルトの名無しさん：2011/01/01(土) 01:43:34

>>788
ここでも紹介されているけど、Mercurialにはbookmark拡張がある。
http://anlyznews.blogspot.com/2010/12/gitmercurial8.html
hg-gitでbookmark拡張はほぼ必須で、gitのブランチの移植みたいなもの。
前はbookmarkはロカールでしか扱えなかったけど、最近のバージョンでリモートと同期もできるようになった。

790 ：776：2011/01/01(土) 02:22:17

>>777
> ・push先に新たなheadを作らない
> ・svn的ブランチは別リポジトリに分ける
> ・bzrの独自の概念だと言っている「メインライン」は、hgではリポジトリの分離と「名前付きブランチ」

ちょっと言っていることがよく分からないんだけど、3つともbzrに対するhgの違いを挙げているという認識で合ってる？

1つ目は、URLを間違えたときに間違えた場所に新しいブランチが作られること？

2つ目は、bzrの場合はリポジトリとブランチが区別されているものの、ブランチにURLが付けられるから
結局はhgの別リポジトリと同じようなものだよ。

3つ目で言ってるのは、hgでも "trunk" とか "main" という名前の履歴だけを表示すれば、bzrみたいに
マージされたブランチ内の細かな履歴を省略して全体の大まかな履歴を見れるってこと？
今度しらべて使ってみるよ。

> hgの場合、リビジョン番号はリポジトリで固有というコンセンサスが出来ているけど、
> bzrの場合出来ているの？
bzr もブランチで固有っていうコンセンサスが取れてるよ。

>>779
> 「公開リポジトリ」上で"hg strip"、"hg rebase"などの履歴の編集はまずしない。
> この場合、公開リポジトリのリビジョン番号は０からの連番で変更されることはない。
> だから、hgweb、bitbucketでのリビジョン番号は恒久的なIDとして捉えても良い。

つまり、append_revisions_onlyという機能はないけど、そういう運用をしているから不変って事ね。
ただし、bzrのメインラインみたいな概念がないから、マージ＆pushは append_revisions_only
に違反しないと。

791 ：デフォルトの名無しさん：2011/01/01(土) 05:07:28

>>790
>> ・push先に新たなheadを作らない
> 1つ目は、URLを間違えたときに間違えた場所に新しいブランチが作られること？

共有サーバーから二人が同時にpullして変更後、pushしたとする。
GitやBazaarは、衝突の解決等は別として、同じブランチにpushできる。
Mercurialは、自動的に『名前無しブランチ』が分かれる（＝headが増える）。
同じブランチで、最新のチェンジセットが複数と言うこともある。hg-headsで最新版のリストを見て、随時マージは必要。

> 3つ目で言ってるのは、hgでも "trunk" とか "main" という名前の履歴だけを表示すれば、
> bzrみたいにマージされたブランチ内の細かな履歴を省略して全体の大まかな履歴を見れるってこと？

ブランチ名で絞り込みは簡単にできるよ（hg log -b ブランチ名）。
ただし、Mercurialの『名前付ブランチ』は、あくまであるチェンジセットの子孫への『目印』なので、Bazaarのブランチとは異なる。

792 ：デフォルトの名無しさん：2011/01/01(土) 05:48:09

大雑把に特性をまとめてみた。

Mercurial:
・一つのリポジトリで複数のブランチが扱える。
・無名ブランチが自動で切られるため、分岐がしやすい。
・名前付ブランチもつける事ができる。目印なので、つけなくても操作に支障は無い。
・ブランチはツリー構造。あるブランチ内のチェンジセットを消すと、他のブランチに含まれる子孫チェンジセットも消える。

Git:
・一つのリポジトリで複数のブランチが扱える。
・ブランチ名を考える必要がある。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。

Bazaar:
・一つのリポジトリで一つのブランチ（メインライン）。
・マージするときは、他のリポジトリのコミットを傍流として記録。
・ディレクトリ配置を考える必要がある。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。

793 ：デフォルトの名無しさん：2011/01/01(土) 08:47:40

>>790
>> ・push先に新たなheadを作らない
> ちょっと言っていることがよく分からないんだけど、3つともbzrに対するhgの違いを挙げているという認識で合ってる？
> 1つ目は、URLを間違えたときに間違えた場所に新しいブランチが作られること？

Mercurialのリポジトリはお互いに完全に対等。
gitのリモートブランチ・ローカルブランチという概念が無い。（ついでに言うとbareもない）
pull/pushも方向の違いでしかなく、名前付きブランチもあるけど、全リビジョンの同期が大原則。

無関係なリポジトリに対してpull/pushしようとすると、
「無関係なリビジョンだよ」と怒られて失敗する。
でも、-f オプションを付けるとpull/pushできる。
これを利用することで、gitスレのこの質問
http://hibari.2ch.net/test/read.cgi/tech/1284467898/345
「根本が異なるリポジトリ」をMerucrialでは「合体」することができる。

あと、hg incoming/hg outgoingというコマンドがあって、pull/push前にどのリビジョンが同期されるのか
確認するのが、お約束。
gitもpushに --dry-run というオプションがある。

794 ：デフォルトの名無しさん：2011/01/01(土) 08:56:36

>>793の続きと訂正
> 無関係なリポジトリに対してpull/pushしようとすると、
> 「無関係なリビジョンだよ」と怒られて失敗する。
『「無関係なリポジトリだよ」と怒られて失敗する。』に訂正。

>> ・push先に新たなheadを作らない
head=無名ブランチという紹介されているようだけど、
オプション無しでpushすることによって新たなheadが出来る場合、
「新たなheadができるよ」と怒られて失敗する。
これも-fオプションを付けることで強制的にpushできるけど、
あまりやってはいけないこと。
この場合、まず、リモートからpullする。
これでローカルに無名ブランチができる。
この状態をmulti heads状態とも呼ぶ。
これをローカルでマージしてheadを１つにしてからpushする。

795 ：デフォルトの名無しさん：2011/01/01(土) 09:36:05

>>792
Bazaarのリポジトリとブランチは一対一じゃないような気がするんだが

796 ：デフォルトの名無しさん：2011/01/01(土) 09:44:49

>>795
詳しく教えてください。

797 ：デフォルトの名無しさん：2011/01/01(土) 10:45:38

Bazaarはブランチ格納用リポジトリ作ったり
そこは本来は分かれている必要がある、という思想で作られているんだろうと思う。
svnのように見える一旦かも知れないが

798 ：デフォルトの名無しさん：2011/01/01(土) 10:56:52

>>796
bzr init-repo foo; cd foo; bzr init bar
とするとリポジトリfooのブランチbarが作られる

少し前に話されてたリビジョン番号については「Bazaarの哲学」を読めば
Bazaarの奇妙さとその意図が分かるかも

799 ：デフォルトの名無しさん：2011/01/01(土) 11:10:50

bitbucketはなんで無料なの

800 ：デフォルトの名無しさん：2011/01/01(土) 14:25:46

>>791
> ブランチ名で絞り込みは簡単にできるよ（hg log -b ブランチ名）。
TortoiseHg現安定版1.1.xの場合、別の名前付きブランチの親も表示させるのが仕様。
Revision Set の所にbranch("名前付きブランチ名")とすることで、その名前付きブランチだけ表示可。
次期TortoiseHg1.9では今のところリストボックスでどっちも可能。

801 ：デフォルトの名無しさん：2011/01/01(土) 16:27:44

>>798
さんくす。試してみる。

802 ：デフォルトの名無しさん：2011/01/01(土) 16:34:49

Bazaarのリポジトリは、ディスク節約・ブランチ作成高速化用のオプションか。
http://doc.bazaar.canonical.com/latest/en/user-reference/init-repository-help.html

803 ：デフォルトの名無しさん：2011/01/01(土) 17:01:22

>>795
SCMのリポジトリとBzrのリポジトリでは意味がかなり違う。
Bzr厨はなぜかその事を認めない。

804 ：デフォルトの名無しさん：2011/01/01(土) 17:09:00

>>802
それだけじゃなくて、pushやpullの高速化の意味もある。
bzr init-repo foo
cd foo
bzr branch http://example.com/bzr/foo/trunk
bzr branch http://example2.com/bzr/foo/feature-a
別の場所にあるリポジトリ内のブランチからそれぞれ別のブランチをbranchで取ってきても、
同一なリビジョンはpullしてこないので、時間と帯域を節約できる。

gitで言えば、remote add + branch がリモートからの bzr branch になる。
単純な remote add はbzrではリモートからの bzr checkout になる。

805 ：デフォルトの名無しさん：2011/01/01(土) 17:10:28

どうやらbzrは、無邪気にgit、hgと並べるようなもんじゃ
ないらしいな。

806 ：デフォルトの名無しさん：2011/01/01(土) 17:11:25

>>804 は作業ツリーを無視して、リポジトリとブランチとリビジョンだけを考えた場合の話ね。

bzrは作業ツリーとブランチも切り離されていて色々な運用が可能で、gitとbzrを併用している
ユーザーには、bzrのブランチをgitの用に扱えるようになるbzr-coloってプラグインがお勧め。

807 ：デフォルトの名無しさん：2011/01/01(土) 17:16:03

svnからbzrに移行した人はリポジトリとブランチと作業ツリーの区別が付いているから
bzrの概念が判りやすいんだけど、gitやhgから入った人はブランチとリポジトリの区別が
svnよりも曖昧になりがちだから、bzrを使い始めるときに混乱するよね。

bzrは分散型でマージが協力なsvnと思ったほうが良さそう。

808 ：デフォルトの名無しさん：2011/01/01(土) 17:23:55

gitはsvnの全否定から入っているからブランチと言えばcvsのブランチ
少しでもsvnの匂いがするものは、拒否

809 ：デフォルトの名無しさん：2011/01/01(土) 17:33:52

>>808
svnにブランチはない

810 ：デフォルトの名無しさん：2011/01/01(土) 17:39:30

>>809
> svnにブランチはない
あ、そうか、bzrが意味不明なことを言いつづけているのはそのせいか

811 ：デフォルトの名無しさん：2011/01/01(土) 17:45:53

皆様のレスを読んだ上で、再度、大雑把に特性をまとめてみた。

Mercurial:
・一つのリポジトリで複数のブランチが扱える。
・分岐時は、無名ブランチが自動で切られる。名前付ブランチもつくる事ができるが、目印なので必須では無い。
・ブランチ内のチェンジセットは木構造に並ぶ。
・分岐したブランチは、元のブランチに依存する。あるブランチ内のチェンジセットを消すと、別のブランチにある子孫チェンジセットも消える。
・複数のリポジトリで変更を行いpushしても、分岐しているので衝突はしない。ただし、解消が要求されるmulti-head状態になるので、先にpullが望ましい。

Git:
・一つのリポジトリで複数のブランチが扱える。
・分岐時に、ブランチ名を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のリポジトリで変更を行いpushすると、衝突が発生する。先にpullが必要。

Bazaar:
・ブランチだけで運用を行える。リポジトリを作ると、複数ブランチでデータを共有して省スペース、ブランチ作成などの高速化ができる。
・分岐時に、ブランチのディレクトリ配置を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・マージするときは、自分のリポジトリのコミットをメインライン、他のリポジトリのを傍流として記録。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のブランチで変更を行いpush/pullすると、衝突が発生する。先にpullが必要。

812 ：デフォルトの名無しさん：2011/01/01(土) 17:50:34

Better Subversionを求めてるだけならgitらしい運用は大袈裟過ぎるし、gitらしい運用が不要なら、
gitじゃない方がその目的には適してるんじゃないかな

git-svnを使うのはgitらしい運用だ！と主張するなら話は別だけど、それはナイト新字体

813 ：デフォルトの名無しさん：2011/01/01(土) 18:08:49

>>809-810
組み込みの機能か否かの差だけで、svnの運用上一般的な概念としてブランチはあるだろうが。

814 ：デフォルトの名無しさん：2011/01/01(土) 19:43:42

バージョン管理システムの選び方

1. 同時に一人しか編集できないロック機構が必要ですか？
　│
　├(YES)→ Subversionをおすすめします。ただし、オンラインでしか開発できなくなります。
(NO)
　↓
2. 日本語のファイル名が存在し、リポジトリをMS-Windows（CP932）とLinuxやMacintosh OS X（UTF-8）で同期を取りますか？
　│
　├(YES)→ Bazzarをおすすめします。ただし、特殊記号の取扱いが重要な場合は、Subversionを選択してください。
(NO)
　↓
3. 実験的なソースコードを頻繁に作成しますか？
　│
　├(NO)→ Bazzarをおすすめします。Bazzarは他のDVCSに比べると分岐が手間ですが、それ以外は遜色ありません。
(YES)
　↓
4. MS-Windowsでの利用をしますか？
　│
　├(YES)→ Mercurialをおすすめします。日本語コミット文やCP932のファイル名も取り扱えます。
(NO)
　↓

815 ：デフォルトの名無しさん：2011/01/01(土) 19:44:38

5. GUIやEclipseでの利用を重視しますか？
　│
　├(YES)→ Mercurialをおすすめします。TortoiseHgとMercurialEclipseの開発が進んでいます。
(NO)
　↓
6. シンプルな操作がお好みですか？
　│
　├(YES)→ Mercurialをおすすめします。チェンジセットの指定方法や管理方法が簡単です。
(NO)
　↓
Gitをおすすめします。高速で高度な管理機能が充実しています。Linux環境下のCLIでは安定した挙動になっています。

816 ：デフォルトの名無しさん：2011/01/01(土) 19:46:45

>>814
> 　├(YES)→ Bazzarをおすすめします。ただし、特殊記号の取扱いが重要な場合は、Subversionを選択してください。
「が」が特殊記号？

817 ：デフォルトの名無しさん：2011/01/01(土) 19:50:37

>>816
日本語でおk

818 ：デフォルトの名無しさん：2011/01/01(土) 19:54:10

>>817
つ>>589

819 ：デフォルトの名無しさん：2011/01/01(土) 20:55:54

>>817
同じUTF-8でも、NFC形式とNFD形式があって「が」のような平仮名キャラクタでも、異機種互換性が無いケースがある。

820 ：デフォルトの名無しさん：2011/01/01(土) 21:15:08

バージョン管理システムの選び方

1. 同時に一人しか編集できないロック機構が必要ですか？
　│
　├(YES)→ Subversionをおすすめします。ただし、オンラインでしか開発できなくなります。
(NO)
　↓
2. 日本語のファイル名が存在し、リポジトリをMS-Windows（CP932）とLinuxやMacintosh OS X（UTF-8）で同期を取りますか？
　│
　├(YES)→ Subversionを選択してください。WindowsとLinuxでなら、Bazzarで日本語ファイル名の同期も可能かも知れません。
(NO)
　↓
3. 実験的なソースコードを頻繁に作成しますか？
　│
　├(NO)→ Bazzarをおすすめします。Bazzarは他のDVCSに比べると分岐が手間ですが、それ以外は遜色ありません。
(YES)
　↓
4. MS-Windowsでの利用をしますか？
　│
　├(YES)→ Mercurialをおすすめします。設定で、日本語コミット文やCP932のファイル名も取り扱えます。
(NO)
　↓

821 ：デフォルトの名無しさん：2011/01/01(土) 21:15:48

822 ：デフォルトの名無しさん：2011/01/01(土) 21:18:31

Bazzarの日本語ファイル名対応にがっかりきたし
今後期待できるMercurialでいいやｗ

823 ：デフォルトの名無しさん：2011/01/01(土) 21:23:32

何を期待するんだ

824 ：デフォルトの名無しさん：2011/01/01(土) 21:26:38

M$のお金で専業開発が可能になったMatt Mackallが、M$圧力でファイル名の国際化を実現することに期待。

825 ：デフォルトの名無しさん：2011/01/01(土) 21:35:24

そういや、最近、svkの話題が全くないな。

826 ：デフォルトの名無しさん：2011/01/01(土) 21:43:56

RCSよりは話題あるよ>>SVK

827 ：デフォルトの名無しさん：2011/01/01(土) 21:49:10

ls -al
-rw-r--r-- 1 user group 0 1 1 20:47 テスト.txt

これをOS XのGitでコミットすると、エスケープされる。

"\343\203\206\343\202\271\343\203\210.txt"

828 ：デフォルトの名無しさん：2011/01/01(土) 21:52:41

>>827
git config --global core.quotepath false

829 ：デフォルトの名無しさん：2011/01/01(土) 22:01:58

svkは間違った設計のいい例だったな。

830 ：デフォルトの名無しさん：2011/01/01(土) 23:09:11

UTF-8-MAC問題はちゃんと認識されているんだから、あとはMacユーザーが
ちゃんとしたテストつきの修正をLaunchpadに登録してマージリクエストをだしたら
すぐにでも治る。
正規化以前にUnicodeファイル名に対応する気がそもそも無いhgよりはずっと
期待できそうだけど？

831 ：デフォルトの名無しさん：2011/01/02(日) 00:01:10

世の中には方向性が予測できる故に生まれる期待と予測できない故に生まれる期待がある

832 ：デフォルトの名無しさん：2011/01/02(日) 00:25:19

python 3系に移行する時に修正されないのかな？
そもそもは、pythonの文字列の扱いが糞なのが問題の出発点なんでしょ？

833 ：デフォルトの名無しさん：2011/01/02(日) 00:53:10

>>832
過去にM$がまともな仕事をしてればunicodeに関する問題は
ここまで混乱は広がっていなかったと思われる

834 ：デフォルトの名無しさん：2011/01/02(日) 01:34:39

>>799
githubぶっつぶしたいから

>>805
ひと括りに出来ない気がするな

Unicode対応という(目標)のはいいんだが

835 ：デフォルトの名無しさん：2011/01/02(日) 01:40:34

>>811
gitのブランチはチェンジセットへのポインタで、場所を指しているだけと思っていたのだけど
違うのかな

何かブランチのメタ情報みたいなものをチェンジセットに含んでたりする？

836 ：デフォルトの名無しさん：2011/01/02(日) 01:42:40

>>816-819
BazzarはUNICODE正規化してどのプラットフォームで共有させられるようにという
前人未到の領域に挑もうとしているんだぞ

おいそこ笑うな！

837 ：デフォルトの名無しさん：2011/01/02(日) 01:45:58

>>832
対応する気がないというより、ファイル名はバイト列で扱う物という指針なら
Python3でも直されない気がするんだ

>>833
同時にMacもdsiってんじゃねーぞ

838 ：デフォルトの名無しさん：2011/01/02(日) 01:53:06

>>836
>Bazzarは
>おいそこ笑うな！

zが多すぎる・゜。・(ノД`)・゜・。

839 ：デフォルトの名無しさん：2011/01/02(日) 02:05:09

>>835
ブランチ間に依存関係が無いと言いたいのでは？
チェンジセットにブランチの情報が含まれていないから、あるブランチを消しても、他のブランチに影響が無い。

840 ：デフォルトの名無しさん：2011/01/02(日) 02:37:50

>>837
Python3でも変えないって中の人が既に宣言してたと思う。
MSからの圧力でどうにかして欲しいな。

841 ：デフォルトの名無しさん：2011/01/02(日) 02:52:09

BazzarとMercurialってどっちがいいの？
Mercurialで出来てBazzarで出来ない事ってある？

842 ：デフォルトの名無しさん：2011/01/02(日) 02:56:12

>>841
Mercurialの方が、スペルを誤解されることが少ないようだ。

843 ：デフォルトの名無しさん：2011/01/02(日) 02:58:10

Bazaarって濁音または半濁音を付けなければ日本語パスやファイルの扱いは完璧
よってBazaarが一番だな

844 ：デフォルトの名無しさん：2011/01/02(日) 02:59:45

>>842
ハサーはにほんこはかんへき

845 ：デフォルトの名無しさん：2011/01/02(日) 03:06:06

MACでバをハ゛にする変態はそうはいないだろｗ

846 ：デフォルトの名無しさん：2011/01/02(日) 03:50:02

hgとgit
ファイル名以外のコメントとかで非ASCIIを使うのは
問題ないんだっけ？

847 ：デフォルトの名無しさん：2011/01/02(日) 05:04:59

>>846
MercurialもGitも、UTF-8（NFC形式）なら問題ない。
Mercurialなら、WindowsのCP932も%USERPROFILE%\Mercurial.iniに以下を書いておけば、問題ない。

[defaults]
commit = --encoding cp932

Windowsでgit-guiなどのツールは、UTF-8でコミットメッセージを書いてくれるそうだ。

848 ：デフォルトの名無しさん：2011/01/02(日) 05:12:31

Windows版のhg.exe, hgtk.exeは、UTF-8でコミットメッセージを書くよ。

849 ：デフォルトの名無しさん：2011/01/02(日) 10:13:54

Bazzarって綴る人は発声する際もバッザーって呼んでるんだろうか

850 ：デフォルトの名無しさん：2011/01/02(日) 14:21:56

>>837
指針を持つのはいいんだけど、Python自体のJoinメソッドの処遇なんか見比べると
なんか筋が通ってないように感じるなぁ・・・
なるようにしかならんのだろうけど

851 ：デフォルトの名無しさん：2011/01/02(日) 15:00:29

mercurialのbranchは、ちょっと気持ち悪い。
bzrのように複数のcloneによって自然に生じるblanch。
gitの機能を取り込む為の、pointer型のblanch。
それにnamed/anonymous blanchが混在してしまうから。

852 ：デフォルトの名無しさん：2011/01/02(日) 15:17:51

>>832,837
Python2もPython3も、ファイルシステムはUnicodeでもバイト列でも利用可能。

複数のエンコーディングが混じってる等がありえるUnix系で全てのファイル名に対応できる
バイト列のファイル名を使うか、WindowsでネイティブでUnix系でもエンコーディングが正しければ
大丈夫なUnicodeファイル名を使うかは、アプリケーションが選択する問題。
bzrはUnicodeを、Mercurialはバイト列を選んだだけ。

ちなみにPython3.1からは、Unicodeにデコードできないバイト列も扱えるような
サロゲートエスケープという方法が提供されていて、デコードできないファイル名を扱える。

853 ：デフォルトの名無しさん：2011/01/02(日) 15:24:13

>>851
用語の定義の問題で、普通ブランチと言った場合、名前付きブランチのことを言う。
あとはリポジトリ・ヘッドと言えば大抵通じる。
他のVCSから来る人のために名無しブランチとか紹介されているだけ。

854 ：デフォルトの名無しさん：2011/01/02(日) 15:42:10

> のbranchは
> 生じるblanch。
> のblanch。
> blanchが
なんで最初だけ正しいスペル？
何か意図があるのか

855 ：デフォルトの名無しさん：2011/01/02(日) 15:50:27

>>852
ぶっちゃけ、英語の事しか考えてなかったのを
後から問いただされて「い、いや、混在してる場合もあるから」
って正当化しただけでしょ。
ML見れば分かる。

混在なんか滅多にないのに。
全か無かで考えるのは典型的な思考ロジックミス

856 ：デフォルトの名無しさん：2011/01/02(日) 16:05:09

>>855
伝説のなんたらかんたらってやつ？

857 ：デフォルトの名無しさん：2011/01/02(日) 17:37:40

基本バイト列で、オプションorプラグインで他文字コード対応というのがきれ
いに実現できれば受け入れられない訳ないと思うが、なぜかここではそれをあ
きらめてしまってる>>837みたいな書き込み多いよな

858 ：デフォルトの名無しさん：2011/01/02(日) 17:54:17

bitbucketやdocutilsあたりも多言語関係はボロボロで泥縄に直してるから、
Pythonが元凶なんじゃねえの？

859 ：デフォルトの名無しさん：2011/01/02(日) 18:01:16

もう面倒だから文字コードはIPv6アドレス互換に一本化しようぜ

860 ：デフォルトの名無しさん：2011/01/02(日) 18:20:38

今昔文字鏡使おうぜ

861 ：デフォルトの名無しさん：2011/01/02(日) 20:39:49

>>855
Pythonの話？Mercurialの話？
Pythonの話であれば、Python1の頃は確かに英語やlatin1の事しか考えられてなかったろうな。
今のPythonは、いわゆるLLの中ではUnicodeの扱いがマシな方だよ。

混在が滅多にないとは言い切れない。Unixはマルチユーザーシステムで、ロケールはユーザー毎に切り替わる。
あるユーザーは LANG=ja_JP.EUC-JP を使ってて、別のユーザーは LANG=ja_JP.UTF-8 を
使っていると当然各ユーザーのホームディレクトリ内はそれぞれ別のエンコーディングに
なっていて、しかもそれを管理している root は LANG=C で運用している、なんてのはよくある話。

rootが各ユーザーのファイル一覧を舐めるようなスクリプトを、ファイル名をUnicodeで扱うように
書いたら、LANG=Cだと非ASCIIファイル名全部がデコードできなくてUnicodeDecodeErrorが
発生しているのがPython3.0以前のPython。

862 ：デフォルトの名無しさん：2011/01/02(日) 22:11:25

>>861
たぶん論点がちゃってる。
つか、VCS側はbyte列で十分、プラットフォーム側で会わせる問題じゃねぇのか？

863 ：デフォルトの名無しさん：2011/01/02(日) 22:44:07

同じ言語で複数のコード体系があるのが、理解できないんじゃないだろうか。
しかも、コードが異なるとマッピングできない文字もあるし。

864 ：デフォルトの名無しさん：2011/01/02(日) 22:45:57

>>862
どっちかが正解でどっちかが間違いって事はないだろ。
CVSで利用者のミスでSJISとEUCが混じったりして管理に苦労して、svnのUnicode対応を喜んでる
人だって確実にいる。

865 ：デフォルトの名無しさん：2011/01/02(日) 22:49:26

>>863
そのレベルの話はもう時代遅れで、今はUnicodeに統一しても正規化や結合・分解文字の扱いで苦労している。

で、gitやhgって、NFCのUTF-8ファイル名をLinuxでコミットして、Macでチェックアウトしたら、
UTF-8-MAC問題で勝手に分解文字にリネームされたりしないの？
Macの問題はファイル名をバイト列で扱ったら解決できるような簡単な問題じゃないと思うんだけど。

866 ：デフォルトの名無しさん：2011/01/02(日) 22:54:25

>>865
GitやMercurialのファイル名の文字コードは、このレベルの話だから困っているのでは？

867 ：デフォルトの名無しさん：2011/01/02(日) 22:58:10

>>864
> CVSで利用者のミスでSJISとEUCが混じったりして管理に苦労して
ファイルの中身は？
VCSは改行の変換はするけど、文字コードの変換しないよね？
ファイルの中身がUTF-16というものもあるし

868 ：デフォルトの名無しさん：2011/01/02(日) 23:04:20

Linuxをデスクトップとして使っていて、メールで送られてくるSJISファイル名のzipの扱いに苦労していた経験があれば、
git、hgのファイル名はたいした問題じゃない

869 ：デフォルトの名無しさん：2011/01/02(日) 23:25:53

>>868
zipは展開したあとにconvmvするとか、どうにでもなる。
バージョン管理ソフトで継続的に管理するファイルのファイル名だから困るんだろ。

870 ：デフォルトの名無しさん：2011/01/02(日) 23:31:37

というか比較対象にすらなってなくね？ｗ

871 ：デフォルトの名無しさん：2011/01/03(月) 08:09:23

>>869
何が困るの？ファイル名を変換するなら、Makefileなどファイル名が書かれているもの全て変換しないと
辻褄合わないよね？

872 ：デフォルトの名無しさん：2011/01/03(月) 08:27:08

>871
Makefileに書くような種類のファイルには、日本語ファイル名は使われない。
日本語ファイル名多用する現場であっても。

知ってるくせに。何でとぼけるの？

873 ：デフォルトの名無しさん：2011/01/03(月) 08:30:00

>>872
日本語.dat、日本語.yamlを使っているところはあるぞ

874 ：デフォルトの名無しさん：2011/01/03(月) 08:36:25

>>872
Javaのクラス名は日本語使わない？

875 ：デフォルトの名無しさん：2011/01/03(月) 10:34:57

>>874
JavaならantとかMavenとかだろ。Makefileと違って設定ファイルがxmlで、設定ファイルの
エンコーディングとファイルシステムのファイル名のエンコーディングが違ってても大丈夫。

>>873
そういう事をするのは、実行環境が限られている、非ポータブルなMakefileだけだろ。
それならUnicodeでもバイト列でも問題ない。

実際、svnはUnicodeでファイル名を扱っているけど、長年デファクトスタンダードとして
利用されてきた。
今分散型に押されているのはコミット権が無いとブランチが作れなかったり
オンラインじゃないと作業できなかったりマージが弱かったりするからであって、
ファイル名をUnicodeで扱うからじゃない。（ちなみにマージは改善されたし
ローカルコミット・ブランチも開発中らしい）

876 ：デフォルトの名無しさん：2011/01/03(月) 10:53:33

>>875
> >>874
> JavaならantとかMavenとかだろ。Makefileと違って設定ファイルがxmlで、設定ファイルの
> エンコーディングとファイルシステムのファイル名のエンコーディングが違ってても大丈夫。
本当か？
xmlはutf-8と定義してあるのに、ファイル名がEUC-JPで書かれていても問題ないのか？
パセーントエンコードしないと不整合だぞ

877 ：デフォルトの名無しさん：2011/01/03(月) 11:44:42

>>876
>xmlはutf-8と定義してあるのに、ファイル名がEUC-JPで書かれていても問題ないのか？
「ファイル名がEUC-JPで書かれていても」というのは、xmlの中に？それともファイルシステムに？
xmlはもちろんUTF-8で書くよ。

<?xml version="1.0" charset="UTF-8" ?>
<project><target name="test">
<copy file="foo.txt" tofile="あほ.txt" />
</target></project>

と書いて、 touch foo.txt したあと、 LANG=ja_JP.utf8 ant test すると、ファイル名が
UTF-8でエンコードされたあほ.txtができて、 LANG=ja_JP.euc_JP ant test すると、
ファイル名が EUC-JP でエンコードされたあほ.txt ができる。

xml内の情報はJava内で一端全部Unicode文字列に変換されて、さらにそれを実行するときに
環境のエンコーディングが利用されるので、xmlファイル内のエンコーディングと環境のエンコーディングは
独立している。
antの用にUnicode対応したツールの場合は Makefile と逆で、 svn や bzr だとLANGが違う環境でも動いて、
git や hg だと LANG が違う環境で動かなくなる恐れがある。

878 ：デフォルトの名無しさん：2011/01/03(月) 11:49:03

そろそろツールを１つにまとめようか

879 ：デフォルトの名無しさん：2011/01/03(月) 12:08:19

今どき ja-JP.euc_JPなんてゴミ環境無視していいよ。

それよりUnix/LinuxのUTF-8とWindowsでまともに動かすにはどうすればいいか考えようぜ。
NFCなりNFDなりはその次のステップだ。

880 ：デフォルトの名無しさん：2011/01/03(月) 12:13:00

>>879
それはbzrとsvnはデフォで対応しているし、gitやhgはutf-8 cygwin使ってutf-8に統一すればおｋだろ

881 ：デフォルトの名無しさん：2011/01/03(月) 12:16:19

>>879
> 今どき ja-JP.euc_JPなんてゴミ環境無視していいよ。
君はLatin-Nの人に同じことを言えるか？

882 ：デフォルトの名無しさん：2011/01/03(月) 12:48:32

> 君はLatin-Nの人に同じことを言えるか？

えー今でもLatin-1なのｗ
UTF-8で全部包含してるからen_US.UTF-8にしなよｗ
なに？「俺の読めない漢字が入ってるJIS2004ケシカラン」とかいう人？

883 ：デフォルトの名無しさん：2011/01/03(月) 12:49:53

>>882
ということをLatin-1の人と英語で議論できるか？

884 ：デフォルトの名無しさん：2011/01/03(月) 13:25:35

議論はできるが論破できる自信はないなｗ

885 ：デフォルトの名無しさん：2011/01/03(月) 13:41:15

できるというレスなら頑張ってって応援しようと思ったのに。
英米人だけでなく、ヨーロッパ大陸の人でもLatin-1で十分と思っているからね。
そもそも、Latin-1とUTF-8の区別が付いているかどうかも疑問。
日本人は化け方でJISかEUCかSJISか分かっちゃうけど、
Latin-1の人は文字化けの経験があるのだろうか、と思ってしまう。

886 ：デフォルトの名無しさん：2011/01/03(月) 14:02:39

とりあえず日本語が化けなければいいよ

887 ：デフォルトの名無しさん：2011/01/03(月) 15:34:47

Subversionはソースコードに特化した一般ファイルの管理には向かないバージョン管理システム
だったからファイル名がUnicodeに限定されていても問題がなかっただけでしょ

今時のバージョン管理システムは一般ファイルのバージョンを管理するバックエンドとしての用途
も視野に入っているから今更Subversionの時代にまで退化しろと言われてもちと困る

888 ：デフォルトの名無しさん：2011/01/03(月) 15:35:55

・・・は？

889 ：デフォルトの名無しさん：2011/01/03(月) 15:41:11

SVNは個々のディレクトリ・ファイルをチェックアウトできることからも分かる通り、
個々のファイルのリビジョンしか管理しないCVSにちょびっと毛が生えた程度。

890 ：デフォルトの名無しさん：2011/01/03(月) 15:48:50

>>887
> Subversionはソースコードに特化
・・・
何を見てそう思ったの？

891 ：デフォルトの名無しさん：2011/01/03(月) 15:56:48

>>887
gitもhgもファイルのタイムスタンプその物は保存しない。
（svnは論外にしても）一般ファイルのバージョン管理に向いてるとはとても思えない。

892 ：デフォルトの名無しさん：2011/01/03(月) 16:04:59

>>891
ファイルじゃなくてチェンジセットなの
だから個々のファイルのタイムスタンプは意味ないの
タイムスタンプもgitとhgはrebase、hgはMQを使えば時間順には並ばない

893 ：デフォルトの名無しさん：2011/01/03(月) 16:48:19

>>892
個々のファイルのタイムスタンプを保存しないのは、チェンジセットとは関係ない。
VCSに個々のファイルのタイムスタンプを以前の状態に戻されると、makeが混乱するので却って
邪魔になるというのが元々の理由。
世代管理可能なバックアップツールであれば、個々のファイルのタイムスタンプも保存して元に
戻すのが当然だが、VCSであるsvn/git/hgは個々のファイルのタイムスタンプを保存しない。
よって、gitやhgが一般ファイルの管理にも向いているという >>887 の意見には同意できないと
主張しているだけ。

894 ：デフォルトの名無しさん：2011/01/03(月) 16:53:34

>>887
> Subversionはソースコードに特化した一般ファイルの管理には向かないバージョン管理システム
ちょっとわかりづらいな。
一般ファイル以外だとシンボリックリンクとかのイメージなんだが。

895 ：デフォルトの名無しさん：2011/01/03(月) 17:06:46

>>887
分かってて言ってるとは思うけど
Subversionはバイナリを扱うのが得意なのが特徴の1つなのだけど

896 ：デフォルトの名無しさん：2011/01/03(月) 17:25:34

>>891
VCS でファイルのタイムスタンプを保存されてうれしいことでもあるのか？
VCS まともに運用できないおっさんの屑管理者か?

897 ：891：2011/01/03(月) 17:57:39

>>896
>>891 = >>893 ぐらいは察してくれ。

898 ：デフォルトの名無しさん：2011/01/03(月) 19:31:44

>>887
Subversionって、WebDAVで一般ファイルのバージョンを管理するバックエンドとして開発が始まったんじゃなかったっけ。

899 ：デフォルトの名無しさん：2011/01/03(月) 20:27:42

>>887
>Subversionはソースコードに特化した一般ファイルの管理には向かないバージョン管理システム

なにを根拠にいってるのかな？

>>893
>個々のファイルのタイムスタンプを保存しないのは、チェンジセットとは関係ない。

ですよねー

900 ：デフォルトの名無しさん：2011/01/04(火) 01:40:49

>>759
いやそのblogの人に。

901 ：デフォルトの名無しさん：2011/01/04(火) 08:44:03

エクスポートしてアーカイブするときだけだな、タイムスタンプを再現して欲しいと思うのは。

902 ：デフォルトの名無しさん：2011/01/04(火) 13:58:28

このスレにはタイムスタンプに執着してる奴はいないみたいで楽だけど、
ファイルのタイムスタンプを絶対視するヴァカは世の中に一杯いる。
特に窓ユーザには多いようだ。
タイムスタンプ信者に限ってTortoiseSVN使ってたりするし。
Subversionはこういうヴァカも大勢相手にしなきゃいけないから大変だよ。

903 ：デフォルトの名無しさん：2011/01/04(火) 14:17:01

VCSの知識なしにファイルの履歴管理したいと思ったら
タイムスタンプに頼らざるを得ないからな

904 ：デフォルトの名無しさん：2011/01/04(火) 22:40:02

履歴管理なんて簡単。

src_20110104_copy3b_ver12_yamada_c.zip

905 ：デフォルトの名無しさん：2011/01/04(火) 22:46:49

>>901
なんで？
TAG辺りをversion.hだかなんだかに放りこんどけばええんちゃう？
あとはdiffって下さいですまへんか？

906 ：デフォルトの名無しさん：2011/01/04(火) 23:21:53

>>905
配布パッケージをつくるときは、各ソースモジュールのタイムスタンプが
last committed time になってる方がかっこよくないか? という私見。
つか git はどーだったか忘れたが、cvs, svn はそうなってた IIRC

907 ：デフォルトの名無しさん：2011/01/05(水) 00:59:55

>>906 なるほどね
ずっと昔から、個人的に、タイムスタンプなんて信用しないからなぁ
# touch されたらその場でアウト

908 ：デフォルトの名無しさん：2011/01/05(水) 16:23:05

makeやantは時間管理。

909 ：デフォルトの名無しさん：2011/01/05(水) 16:26:56

make clean

910 ：デフォルトの名無しさん：2011/01/05(水) 16:29:32

未来からのメールよこす奴はいっぱいいるぞ

911 ：デフォルトの名無しさん：2011/01/05(水) 16:59:44

>>908
だからこそ VCS から取り出したファイルは、たとえ昔のリビジョンでも
常に最新のタイムスタンプである必要がある。

912 ：デフォルトの名無しさん：2011/01/05(水) 21:57:02

>>902
> タイムスタンプ信者に限ってTortoiseSVN使ってたりするし。
どういうこと？コマンドラインとtortoiseでタイムスタンプの扱いが違うの？

913 ：デフォルトの名無しさん：2011/01/05(水) 22:02:51

変更してコンパイルした。やっぱ思い直してrevertした。
タイムスタンプ戻ったらmakeが困るぞ。

914 ：デフォルトの名無しさん：2011/01/05(水) 22:34:44

そういう時のためにtouchがあるんじゃないか

915 ：デフォルトの名無しさん：2011/01/05(水) 23:26:14

タイムスタンプ変わっていいのかよ。ｗ

916 ：デフォルトの名無しさん：2011/01/06(木) 00:37:35

>>912
そうじゃなくて、タイムスタンプ信者に一定の偏りがあるんじゃないかってこと。
なんつうか...まぁ、誤解を恐れずに言うと
「Windows/GUIマンセー」「CUIクソ!」な奴に多い...みたいな。

917 ：デフォルトの名無しさん：2011/01/06(木) 01:31:59

タイムスタンプを保存して欲しいという要望自体は真っ当だな
Sconsユーザでもないお前はまともな説明能力が無いからタイムスタンプ信者とレッテル貼って逃げてるだけだろ
makeの挙動でも勉強してから出直してこい

918 ：デフォルトの名無しさん：2011/01/06(木) 01:50:35

タイムスタンプ勝手にいじられても気持ち悪いだけだと思うんだが。

919 ：デフォルトの名無しさん：2011/01/06(木) 03:14:00

はい
http://mercurial.selenic.com/wiki/FAQ#FAQ.2BAC8-CommonProblems.Why_is_the_modification_time_of_files_not_restored_on_checkout.3F
https://git.wiki.kernel.org/index.php/GitFaq#Why_isn.27t_Git_preserving_modification_time_on_files.3F

920 ：デフォルトの名無しさん：2011/01/06(木) 09:34:54

それはタイムスタンプを保存しない理由じゃなくてタイムスタンプを勝手に戻さない理由
実際には勝手に戻さなくても保存しようとするだけでいくつかの問題が発生する
自分の頭でほんの少し想像力を働かせれば何が問題になるかはすぐ分かるはずなんだがな

921 ：デフォルトの名無しさん：2011/01/06(木) 09:38:38

パフォーマンスと容量以外の問題があるならぜひ教えて欲しいです

922 ：デフォルトの名無しさん：2011/01/06(木) 09:57:23

このスレでも既出だぞ？
それだけが問題ではないけどな

923 ：デフォルトの名無しさん：2011/01/06(木) 15:29:54

>>920は自分の想像力が不足しているので、他の人に説明して欲しいらしい。

924 ：デフォルトの名無しさん：2011/01/06(木) 18:25:58

ひょっとして未成年だったのかな？　だとしたら申し訳ない
このスレで既出の問題は200番台に書いてあるから見てみるといい
このスレで既出じゃない問題の例としては例えば時刻分解能に起因した問題があるが他にもあるよ
若いうちからバージョン管理システムの使い方を勉強してるなんて偉いなあ
後からきっと役にたつから頑張れ

925 ：デフォルトの名無しさん：2011/01/06(木) 19:36:55

タイムスタンプ信者の>>920がキモい

926 ：デフォルトの名無しさん：2011/01/06(木) 21:43:02

若いうちからバージョン管理システムなんか使うと駄目になる。

927 ：デフォルトの名無しさん：2011/01/06(木) 21:49:34

若いうちから日本語ファイル名なんか使うと駄目になる。

928 ：デフォルトの名無しさん：2011/01/07(金) 06:14:19

若いうちから2chなんか見ると駄目になる。

929 ：デフォルトの名無しさん：2011/01/08(土) 15:35:30

更新時刻も重要なファイルのメタデータのひとつだろうに。バージョン管理といえばmakeしか思い浮かばないヤツはどんだけ視野が狭いんだ。
PC内の全ファイルの更新時刻がOS起動時刻に変わっても文句言わないのかね。

Perforceはmtimeも保存するらしいけど、本当かな

930 ：デフォルトの名無しさん：2011/01/08(土) 16:05:05

>>929
時間が全く合っていないマシンのネットワークドライブはどうする？

931 ：デフォルトの名無しさん：2011/01/08(土) 16:15:59

確かにコミット時刻は重要な情報だ。

932 ：デフォルトの名無しさん：2011/01/08(土) 16:28:44

git commit --date='2000-01-01'

933 ：デフォルトの名無しさん：2011/01/08(土) 17:08:11

これだからgitってやつは

934 ：デフォルトの名無しさん：2011/01/08(土) 18:25:44

>>929はどのバージョン管理システムを使っているの？

935 ：デフォルトの名無しさん：2011/01/09(日) 04:36:11

>>930
うるせえ時刻合わせろチンカス

936 ：デフォルトの名無しさん：2011/01/09(日) 11:00:03

バージョン管理といえばmakeを思い出す人なんていたっけか

937 ：デフォルトの名無しさん：2011/01/09(日) 11:24:55

いつから make がバージョン管理ツールになったか教えてほしいもんだ

938 ：デフォルトの名無しさん：2011/01/09(日) 12:09:44

>>932 のコマンドはMercurialでも使えるね。知らなかったがこりゃ便利。

939 ：デフォルトの名無しさん：2011/01/09(日) 13:08:38

>>937
make dist

940 ：デフォルトの名無しさん：2011/01/09(日) 13:55:24

>>937
そもそも dist って make の組み込みターゲットだったけか？
通常、配布パッケージつくるのが dist のお仕事ではなかったかと？
で、中で SCCS とか RCS とか…

941 ：デフォルトの名無しさん：2011/01/09(日) 15:55:07

hoge-x-y-z.tar.gzのx-y-zはバージョンだからバージョン管理

942 ：デフォルトの名無しさん：2011/01/09(日) 18:09:31

日本で最も普及してるバージョン管理ツールは、LHA

943 ：デフォルトの名無しさん：2011/01/10(月) 15:09:21

Makefileのdistターゲットが一般化したのってautotools以降だよ。
autotools使わない人もdistターゲットを作るべきなんてルールもない。
まあ便利だけど。

944 ：デフォルトの名無しさん：2011/01/13(木) 20:45:58

SourceForge.JP、個人向けGitリポジトリ/ストレージサービス「PersonalForge」をリリース
http://sourceforge.jp/magazine/11/01/13/0234231

945 ：デフォルトの名無しさん：2011/01/14(金) 19:52:18

>>758
http://anlyznews.blogspot.com/2011/01/bazaarsvn.html

946 ：デフォルトの名無しさん：2011/01/18(火) 03:58:44

>>944
Git採用ということは、Windowsで開発するな、ってことですかね…

947 ：デフォルトの名無しさん：2011/01/18(火) 04:06:24

>>946
はぁ？

948 ：デフォルトの名無しさん：2011/01/18(火) 04:41:08

あーそうか
ファイル名に日本語使わなければ問題は起きないのか
どうせソースを管理するだけだからこの場合問題は無いのですね
この手の開発する人が日本語ファイル名を使うわけもないし
失敬失敬

949 ：デフォルトの名無しさん：2011/01/18(火) 04:49:53

あーそうか
ファイル名に「が」を使わなければ問題は起きないのか
どうせソースは管理しないからBazaarでも問題は無いのですね
ファイルに日本語ファイル名を使う人は英語を読めないし
失敬失敬

950 ：デフォルトの名無しさん：2011/01/18(火) 05:07:07

大事なことなので(ry

951 ：デフォルトの名無しさん：2011/01/18(火) 07:09:46

MercurialとEclipseが楽。

952 ：デフォルトの名無しさん：2011/01/18(火) 07:28:06

あーそうか
ファイル名に「か゛」を使わなければ問題は起きないのか
と゛うせソースは管理しないからBazaarて゛も問題は無いのて゛すね
ファイルに日本語ファイル名を使う人は英語を読めないし
失敬失敬

953 ：デフォルトの名無しさん：2011/01/18(火) 08:30:01

>>952 「ば」

954 ：デフォルトの名無しさん：2011/01/18(火) 09:07:13

残念すぎる出来

955 ：デフォルトの名無しさん：2011/01/18(火) 09:22:01

>>944
githubの個人主体のパクリなんだろうけど、容量制限があるのかが分からない。
BTS・wikiのあるgithubからわざわざ移ってくる人はまずいないだろう

956 ：デフォルトの名無しさん：2011/01/18(火) 09:55:09

>>944
同じ終わコン同士Bazaarやれば良かったのに

957 ：デフォルトの名無しさん：2011/01/18(火) 10:29:34

>>949 >>952
OS X使うなよ。

958 ：デフォルトの名無しさん：2011/01/18(火) 12:30:09

>>957
BazaarはMacOSX以外ではNFDを扱えるのか？

959 ：デフォルトの名無しさん：2011/01/18(火) 13:36:28

>>958
LinuxとWindowsだけ使っておけよ。

960 ：デフォルトの名無しさん：2011/01/18(火) 16:10:43

>>952はNFDを勘違いしてるな。
独立した濁点と合成用の濁点は別のコードポイントが割り振られてるぞ。
問題になるのは合成用の濁点で、独立した濁点については何の問題もない。

961 ：デフォルトの名無しさん：2011/01/18(火) 16:39:31

あーそうか
ファイル名に「かU+3099」を使わなけれはU+3099問題は起きないのか
とU+3099うせソースは管理しないからBazaarてU+3099も問題は無いのてU+3099すね
ファイルに日本語ファイル名を使う人は英語を読めないし
失敬失敬

962 ：デフォルトの名無しさん：2011/01/18(火) 17:17:52

>>960は>>952を勘違いしてるな。
問題を起こさない為に日本語はこう書きましょうと言ってるんだろ。

963 ：デフォルトの名無しさん：2011/01/18(火) 19:10:09

>>857
諦めてはないよ。自分からパッチ書く気がないだけで。

> 基本バイト列で、オプションorプラグインで他文字コード対応というのがきれ
> いに実現できれば受け入れられない訳ないと思うが、

現状で問題になっているWindowsでもcygwinを使えば、かなり綺麗に文字コード対応が実現できているんだが
ここでは受け入れられているようには見えないんだよな
cygwinを入れるのは簡単なのにな

Macにもcygmacがあれば解決できるなｗ

964 ：デフォルトの名無しさん：2011/01/18(火) 19:16:10

正確には書く気がないじゃなくて、書けないだった。思わせぶりな書き方はよくない、反省

965 ：デフォルトの名無しさん：2011/01/18(火) 19:28:02

お前らマルチプラットフォームのそれこそiPhoneだろうがAndroidだろうがMac OS Xだろうが
ちゃんと日本語対応できているDropboxも参考にしろや

素人向けのバージョン管理もできるツールが対応度が高いのもどんだけ

966 ：デフォルトの名無しさん：2011/01/18(火) 19:46:45

素人向けの方がクオリティが高いのは当たり前じゃん

967 ：デフォルトの名無しさん：2011/01/18(火) 19:51:13

Dropboxにその日の成果を"日付.zip"で上げてバージョン管理

968 ：デフォルトの名無しさん：2011/01/18(火) 20:56:28

去年くらいにDropboxで一部のデータが消えたという事件があったばかりだろ

969 ：デフォルトの名無しさん：2011/01/18(火) 21:46:58

>>968
無いだろ？

970 ：デフォルトの名無しさん：2011/01/18(火) 23:43:09

>>963
パッチ書けなくても英語で議論すればいいだろ
Cygwinで困ってないなら別にいいけど

971 ：デフォルトの名無しさん：2011/01/18(火) 23:59:22

msysgitのパッチなら進展しているんですけど
http://code.google.com/p/msysgit/issues/detail?id=80

972 ：デフォルトの名無しさん：2011/01/19(水) 00:43:34

>>963
> 現状で問題になっているWindowsでもcygwinを使えば、かなり綺麗に文字コード対応が実現できているんだが
> ここでは受け入れられているようには見えないんだよな
> cygwinを入れるのは簡単なのにな

cygwinでutf-8が使えることを受け入れるとBazaarの存在意義が無くなるから

973 ：デフォルトの名無しさん：2011/01/19(水) 03:46:20

夜分遅く失礼します
MercurialのMQについて調べているのですが、この拡張の意義というのはどこにあるのでしょうか？

Mercurial MQ について - daily dayflower
http://d.hatena.ne.jp/dayflower/20090520/1242794877

上記のページを見てブランチを切ったり、コミットするまでもないような小規模な変更をするため、
というようにも受け取れたのですが、hgはsvnなどとも違って、
ブランチを切ったり切り替えたりするコストは格段に低いですよね？
何故ちょっとしたブランチを切って、そのパッチを当てたり、マージしたりといった既存の操作をすててまで、
わざわざ新しい概念や操作を持ち出してMQを使うのでしょうか？

pbranchもMQと似たような用途のようなのに、長期開発向けだったりますます意味がわかりません。

974 ：デフォルトの名無しさん：2011/01/19(水) 03:51:26

いま眠いので朝返事する

975 ：デフォルトの名無しさん：2011/01/19(水) 07:28:46

>>973
昔はrebaseとtransplant(gitのcherry-pickに相当)拡張が無かったけど、MQがあれば何でもできた。
逆に今でも、MQを使えばrebase・transplantを使わなくても同様のことはできる。

976 ：デフォルトの名無しさん：2011/01/19(水) 07:33:00

>>973
> ブランチを切ったり切り替えたりするコストは格段に低いですよね？
> 何故ちょっとしたブランチを切って、そのパッチを当てたり、マージしたりといった既存の操作をすててまで、
> わざわざ新しい概念や操作を持ち出してMQを使うのでしょうか？

gitがrebase主義の所とそうで無い所があるように、hgでもなるべく履歴をきれいにしたい、という所は多いと思う。
名前付きブランチが昔はclose出来なかったので、コストが高かった。
bookmark拡張のpull/push出来る機能も今ひとつ使い勝手が悪い。

977 ：デフォルトの名無しさん：2011/01/19(水) 07:37:53

>>973
Mercurial本体やTortoiseHgのログを眺めていると時間順に並んでいないのがあるのに気付くと思う。
これは大抵MQを使っている。

978 ：デフォルトの名無しさん：2011/01/19(水) 07:56:37

>>973
gitとの比較で、hgはローカルブランチが無いというのがある。
リビジョン・名前付きブランチ名を指定してpushすればgitのローカルブランチみたいなこともできる。
この目的にもbookmark拡張が使えるけど、普通のチェンジセットにしちゃうと、
どれが実験的・デバッグ的なチェンジセットなのか見分けがつきづらくなる。
でもMQを使っておけば、pushして良いものと、まだダメなものの見分けがつきやすい。

979 ：デフォルトの名無しさん：2011/01/19(水) 08:08:38

>>973
選択肢の問題で、

・不要なブランチを消したい
・チェンジセットをまとめたい
・別ブランチの一部のチェンジセットだけマージしたい
・ローカルではパッチをあてて作業したい（共有リポジトリ版と設定部分を変えたい）

と言うような要望が無い人には、拡張機能MQは要らない。

980 ：デフォルトの名無しさん：2011/01/19(水) 08:12:53

>>973
職場で毎日コミットするルールがあるとして、ある機能の実装に5日間かかるとする。
5回コミットされるが、5つのチェンジセットを同時にマージしないと原子性が満たされない。
また4日間分のコミット・メッセージは「#12345機能の実装途中」であり、情報としては意味が無い。
こういう時に、チェンジセットをまとめたいという要望があるのは自然だ。

981 ：デフォルトの名無しさん：2011/01/19(水) 08:13:34

>>973
　　　　　　　　　＼　　　∩─ｰ､　　　====
　　　　　　　　　　＼／　●　､_ ｀ヽ　　======
　　　　　　　　　　　/ ＼(　●　 ● |つ
　　　　　　　　　　　|　　 X_入__ノ　ミ　　　そんな餌で俺様が釣られクマ――
　　　　　　　　　　　､　(＿／　　　ノ　/⌒l
　　　　　　　　　　　 /＼＿＿＿ノﾞ＿/　 /　　=====
　　　　　　　　　　〈　　　　　　　　＿_ノ　　====
　　　　　　　　　　　＼　＼＿　　　　＼
　　　　　　　　　　　　　＼＿__）　　　　　＼　　　======　　　(´⌒
　　　　　　　　　　　　　　　　＼　　＿＿_ ＼＿＿　　(´⌒;;(´⌒;;
　　　　　　　　　　　　　　　　　＼＿＿＿）＿＿＿）(´;;⌒　 (´⌒;;　　ズザザザ

982 ：973：2011/01/19(水) 15:06:07

ありがとうございます。
歴史的な経緯があるみたいですね

まとめました

・gitでいうrebaseのような扱い >>976
・Mercurialには以前までrebaseとtransplant(gitのcherry-pickに相当)拡張が無く、MQで同様のことができた(今でもできる) >>975
・その昔、名前付きブランチはcloseできなかったのです >>976
・チェンジセットへのポインタであるgitのブランチを実現するbookmark拡張はいまいち >>976
・そもそもローカルブランチがないので、MQを使うと使い分けられる >>978
・チェンジセットをまとめるためにも使う >>980
・クマ >>981

> ブランチを切ったり切り替えたりするコストは格段に低いですよね？

というのをgitを使っていたときの感覚で言ってしまったのですが、
hgとは状況が全く違っていたようですね・・・

983 ：デフォルトの名無しさん：2011/01/19(水) 15:14:39

>> ブランチを切ったり切り替えたりするコストは格段に低いですよね？
>というのをgitを使っていたときの感覚で言ってしまったのですが、

ブランチを切る手間が問題なのではない。
Gitにもgit-resetや、git-cherry-pick、git-merge --squash、guiltがある。

984 ：デフォルトの名無しさん：2011/01/20(木) 03:53:27

>>980 職場で毎日コミットするルールがあるとして、ある機能の実装に5日間かかるとする。

これって、未完成でもコミットしなきゃいけないってことなの？
時間切れでビルドできない状態でも「毎日コミットする」ルールなんて、有害だよ？

ある機能の実装が完了してからコミットすれば良いんでは？

985 ：デフォルトの名無しさん：2011/01/20(木) 04:21:22

>>984
Subversionについて言っている？
デスクトップPCが５日目で壊れたらどうする？
いざコミットしようとしたらコンフリクトしたらどうする？
gitならmerge --squash、hgでもMQのqfoldやらいろんな手段の方が安全では無いか？

986 ：デフォルトの名無しさん：2011/01/20(木) 04:59:31

>>984
> 時間切れでビルドできない状態でも「毎日コミットする」ルールなんて、有害だよ？

Mercurialだと、ビルド不可能なチェンジセットの存在は開発の阻害にならない。つまり、
・他の人はビルドできるバージョンに戻って、コミットするだけで無名ブランチが切れる。
・SVNの2-waysマージとは違い、3-waysマージが賢いので無名ブランチのマージは怖くない。

また、編集者がローカル・リポジトリに無闇にコミットをしても、共有リポジトリへpush前に拡張機能MQでコミットの統合ができる。
つまり、コミット必須は有害なルールとも言えなくなる。

SVNでは、管理者がブランチを切りマージ性能も低いため、ビルド可能や、テスト完了済みバージョンのコミットが必須になっているだけ。

987 ：デフォルトの名無しさん：2011/01/20(木) 05:20:47

>>984
ビルドに１日かかるとしてコミットするのに１日待たないといけないの？
make clean しないでmakeだけでビルドが通るって言っているの？
Subversionの作業フォルダでmakeが通っても、他の所でmakeが通らなかったら、
コミッタが血祭りにあげられるの？

988 ：デフォルトの名無しさん：2011/01/20(木) 06:59:19

すらっと流しているけど
>他の人はビルドできるバージョンに戻って、

どうやってビルド可能なバージョンを「知る」の？
まさかいろんなバージョンをとっかえひっかえ？

管理システムの外に、もう一つ管理システムがないと実質対応できないじゃないか？

989 ：デフォルトの名無しさん：2011/01/20(木) 08:01:09

>>984
Team Foundation Serverだと、そういう場合はシェルブ機能が使えるね。
コミットはしたくないけどサーバーには上げておきたい時にシェルブを使う。

Subversionでも1.8あたりで実装予定じゃなかったっけ？

990 ：デフォルトの名無しさん：2011/01/20(木) 08:25:52

ついに、Team Foundation Serverを使った事のある奴が現れた！

991 ：デフォルトの名無しさん：2011/01/20(木) 08:44:10

>>988
フックでビルド叩くツールかませばいい
それが成功したら、Bazaarでいうメインなんたらってのにpushすればいい

992 ：デフォルトの名無しさん：2011/01/20(木) 09:50:19

機能が未完成≠コンパイルできない