トップページ⇒tech
1001コメント332KB

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

レス数が1000を超えています。これ以上書き込みはできません。
0001前スレ858=8792010/09/06(月) 22:48:42
バージョン管理システムについて再び語りましょう

●過去スレ
バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/
バージョン管理システムについて語るスレ2
http://pc11.2ch.net/test/read.cgi/tech/1215520728/
バージョン管理システムについて語るスレ3
http://pc12.2ch.net/test/read.cgi/tech/1228366972/
バージョン管理システムについて語るスレ4
http://pc12.2ch.net/test/read.cgi/tech/1242918130/
バージョン管理システムについて語るスレ5
http://pc12.2ch.net/test/read.cgi/tech/1255241922/
バージョン管理システムについて語るスレ6
http://hibari.2ch.net/test/read.cgi/tech/1270640436/

●関連スレ
CVS 1.3 [UNIX板]
http://pc12.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ～ Rev.3 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1154701996/
Subversion r12 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1254838551/
git スレッド [Linux板]
http://hibari.2ch.net/test/read.cgi/linux/1197798039/
【分散型バージョン管理】 Mercurial 【hg】
http://hibari.2ch.net/test/read.cgi/tech/1251208950/
【bzr】Bazaarでバージョン管理 Rev 2
http://hibari.2ch.net/test/read.cgi/tech/1265951333/
0002デフォルトの名無しさん2010/09/06(月) 22:49:10
●関連サイト
CVS
ttp://ximbiot.com/cvs/wiki/
Subversion
ttp://subversion.tigris.org/
Git
ttp://git-scm.com/
Bazaar
ttp://bazaar.canonical.com/en/
Mercurial
ttp://mercurial.selenic.com/wiki/
Darcs
ttp://www.darcs.net/
GNU arch
ttp://www.gnu.org/software/gnu-arch/index.html
monotone
ttp://www.monotone.ca/
Visual SourceSafe
ttp://www.microsoft.com/japan/msdn/vstudio/products/ssafe/default.aspx

●チュートリアル
Subversionによるバージョン管理(日本語訳)
ttp://subversion.bluegate.org/ (アクセスできない場合は↓)
ttp://www.caldron.jp/~nabetaro/hiki.cgi?SubversionWork
Git入門
ttp://www8.atwiki.jp/git_jp/
Bazaar Documentation Overview
ttp://wiki.bazaar.canonical.com/Documentation
Mercurial の使い方のチュートリアル
ttp://mercurial.selenic.com/wiki/JapaneseTutorial
0003デフォルトの名無しさん2010/09/06(月) 22:51:49
立てました。
関連スレに関してはサーバ移行に伴い、落ちてしまったスレが多いようなのですが
一応過去スレとして残しておきました。
新サーバに移行しているものに関しては、一応URLを新サーバに変更しました。
0004デフォルトの名無しさん2010/09/06(月) 23:06:31
乙
0005デフォルトの名無しさん2010/09/06(月) 23:08:14
>>3
落ちてねーぞ、こら
0006デフォルトの名無しさん2010/09/06(月) 23:09:37
>>1の独断による、本スレ認定したものだけだろ。
0007デフォルトの名無しさん2010/09/06(月) 23:17:58
>>5
チェックミスった所があったかもしれません。
落ちてないのってどのスレですか？

>>6
一応全部確認したつもりなんですが・・・
0008デフォルトの名無しさん2010/09/06(月) 23:30:25
なるほど、確かに私間違ますね。
私の2chブラウザだと旧アドレスでの他板へのジャンプで過去ログへと
繋がってしまったため落ちたと判断してしまっていました。
失礼しました
0009デフォルトの名無しさん2010/09/06(月) 23:32:51
>>1 ※修正版
●過去スレ
バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/
バージョン管理システムについて語るスレ2
http://pc11.2ch.net/test/read.cgi/tech/1215520728/
バージョン管理システムについて語るスレ3
http://pc12.2ch.net/test/read.cgi/tech/1228366972/
バージョン管理システムについて語るスレ4
http://pc12.2ch.net/test/read.cgi/tech/1242918130/
バージョン管理システムについて語るスレ5
http://pc12.2ch.net/test/read.cgi/tech/1255241922/
バージョン管理システムについて語るスレ6
http://hibari.2ch.net/test/read.cgi/tech/1270640436/

●関連スレ
CVS 1.3 [UNIX板]
http://hibari.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ～ Rev.3 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://hibari.2ch.net/test/read.cgi/linux/1154701996/
Subversion r12 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1254838551/
git スレッド [Linux板]
http://hibari.2ch.net/test/read.cgi/linux/1197798039/
【分散型バージョン管理】 Mercurial 【hg】
http://hibari.2ch.net/test/read.cgi/tech/1251208950/
【bzr】Bazaarでバージョン管理 Rev 2
http://hibari.2ch.net/test/read.cgi/tech/1265951333/
0010デフォルトの名無しさん2010/09/07(火) 00:32:22
即死なんて俺がさせない
0011デフォルトの名無しさん2010/09/07(火) 07:57:45
LaTeX憶えられなくて劣等感抱いてるのが約一名いることが判明した
0012デフォルトの名無しさん2010/09/07(火) 08:48:47
そもそも文章なんていくら書いても金になんねーつの
挙句らてっくす笑なんかじゃ何所にも納品できねーし
あんな生産性の無いもん厨煮から抜け出せない学生ちゃんしか使わん
ビジネスユースでてっくす笑が使われてるケースがあるなら提示してみろよ
0013デフォルトの名無しさん2010/09/07(火) 08:51:51
こいつの脳内にはアスキーという会社は存在しないらしい。
まぁ確かにメディアワークスと合併しちゃって存在しないけどさw
0014デフォルトの名無しさん2010/09/07(火) 09:17:09
馬鹿な事やってる会社は潰れると言う事例をありがとう
はい次の方どうぞ
0015デフォルトの名無しさん2010/09/07(火) 09:24:53
おや、ビジネスコースのエリート様はTex2Pdfをご存じないらしい。
きっとDoxygenもご存じなくて、下々のものに手書きさせているに違いない。
プログラムでできることを態々仕事として下々に与えてくださるとはなんと有り難い。
0016デフォルトの名無しさん2010/09/07(火) 09:42:28
何言ってんだこいつと思ったらビジネスコースってお前・・・・

言ってる内容も全部が相当の自爆もんだし
それで真面目に煽ってるつもりなら、マジもんの馬鹿だよお前
0017デフォルトの名無しさん2010/09/07(火) 09:54:02
あらら、自分の知らない単語は全部「自爆もん」ですかw
0018デフォルトの名無しさん2010/09/07(火) 10:13:03
マジもんの馬鹿確定
お気の毒様
0019デフォルトの名無しさん2010/09/07(火) 10:23:08
ビジネスコースｗｗｗｗｗｗｗｗ
朝から笑わせんなｗｗｗｗｗ
0020デフォルトの名無しさん2010/09/07(火) 10:33:26
おまいらその調子で即死回避よろｗ
0021デフォルトの名無しさん2010/09/07(火) 10:35:18
>>12
> そもそも文章なんていくら書いても金になんねーつの
> 挙句らてっくす笑なんかじゃ何所にも納品できねーし
現場ってものすごい狭いんですね
0022デフォルトの名無しさん2010/09/07(火) 10:50:57
だって、そいつの想像力ってゼロなんだもん。
自分の体験だけが全てwwwwwww
0023デフォルトの名無しさん2010/09/07(火) 10:51:47
> 馬鹿な事やってる会社は潰れると言う事例をありがとう

合併した会社のことを「潰れた」とは言いません。
バカの事例をありがとうwwwwwww
0024デフォルトの名無しさん2010/09/07(火) 14:46:58
てっくす（笑）
0025デフォルトの名無しさん2010/09/07(火) 15:05:37
確かにてっくすじゃあ納品できないな
0026デフォルトの名無しさん2010/09/07(火) 15:33:41
>>24
>>25
その拾い方は痛い
0027デフォルトの名無しさん2010/09/07(火) 21:29:15
TeX って文章構造じゃなく出力を記述する言語だぞあれ。
ドキュメントだったら Wiki の方がなんぼかマシ
0028デフォルトの名無しさん2010/09/07(火) 23:56:16
いい加減スレ違いだボケ。
0029デフォルトの名無しさん2010/09/08(水) 00:13:41
実際、テキスト形式のソースコード（プログラミング言語とかマークアップとか）
ならいくらでも差分取れるから、分散型でもマージすりゃいいじゃん、
って考えられるけど、差分取れないとか、人が差分見ても意味不明とか、
そういうファイルフォーマットメインでやらなきゃいけない場合、
どうすりゃいいんだろうね。

つかまあ、そういうフォーマット使う限りはどうにもならないかね…
0030デフォルトの名無しさん2010/09/08(水) 06:57:28
そういう時は目で差分取るしかないんじゃないかなぁ。
diff とってマージと意味はかわらないよね。

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

というわけで文章はいいんだけどさ、画像とかどうしょもないよね。
0031デフォルトの名無しさん2010/09/08(水) 09:22:02
TortoiseSVN の TortoiseIDiff が出たばっかりの頃は面白がって使っていたけど
最近はさっぱり使わなくなったな。
画像を重ねて透かして見るのが楽しかったｗ
0032デフォルトの名無しさん2010/09/08(水) 13:09:26
>>24
せっくす(笑)
0033デフォルトの名無しさん2010/09/09(木) 02:14:02
人種差別と排外主義を許さない人たちが見せた本性
人種差別と排外主義を許さない人たちが見せた本性
http://www.youtube.com/watch?v=B4iM0b8mSQ8&feature=related
http://www.youtube.com/watch?v=B4iM0b8mSQ8&feature=related
人種差別と排外主義を許さない人たちが見せた本性
人種差別と排外主義を許さない人たちが見せた本性
0034デフォルトの名無しさん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を捨てる覚悟ができたか。
0035デフォルトの名無しさん2010/09/10(金) 00:22:18
>>34
たった200万円くらいじゃねえか。
0036デフォルトの名無しさん2010/09/10(金) 00:22:26
TFSとMercurialじゃ方向性が全然違うだろう。

それはともかく、せっかく支援するならWindowsの日本語ファイル名をなんとかして…くれないよなぁ。
0037デフォルトの名無しさん2010/09/10(金) 02:43:39
200万つったらTFSの1ライセンス分くらいか？
0038デフォルトの名無しさん2010/09/10(金) 03:00:03
>>36
おい、UTF-16対応フラグだろ、それはｗ Python3の内部はUTF-16だっけ？
UTF-8そっちのけになってマルチプラットフォームでやりとり不可の可能性すらあるだろがｗｗｗ
0039デフォルトの名無しさん2010/09/10(金) 09:55:43
MSにとってapache傘下になったsvnよりhgの方が都合が良いってことか？
0040デフォルトの名無しさん2010/09/10(金) 14:30:43
消去法だったり…


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

みたいな
0041デフォルトの名無しさん2010/09/10(金) 14:58:04
hgはOpenJDK,OpenOfficeでSUNってイメージがあったのだが、そのSUNが・・・
0042デフォルトの名無しさん2010/09/10(金) 15:06:15
使ってる人達じゃなくて、作った人の話でしょ。
0043デフォルトの名無しさん2010/09/10(金) 15:19:42
>>42
コミットのログにアットマークsun.comならいるけど
0044デフォルトの名無しさん2010/09/10(金) 17:12:37
>>42
作った人ならmercurialはLinuxのイメージじゃないか？
0045デフォルトの名無しさん2010/09/11(土) 00:59:54
tortoisesvnにまったく不満ないんだけどなにかある？
0046デフォルトの名無しさん2010/09/11(土) 01:01:48
>>45 CPU 負荷 HDD アクセス負荷が高すぎる気がする。
0047デフォルトの名無しさん2010/09/11(土) 03:21:23
mercurial で、git ci --amend 相当のことってできますか。
直前のコミットコメントを修正するのに、git ci --amend がすごく便利なので、
同じような機能がmercurialにあれば教えてください。
0048デフォルトの名無しさん2010/09/11(土) 04:24:20
>>47
http://stackoverflow.com/questions/623052/how-to-edit-incorrect-commit-message-in-mercurial
0049デフォルトの名無しさん2010/09/11(土) 06:45:23
>>45
エクスプローラにフック入れてくるからSVN使う作業時以外でもモッサリにされた。
0050デフォルトの名無しさん2010/09/11(土) 07:23:58
>>45
Subversionに対する不満ならたくさんあるが、そういうことではなく？
0051デフォルトの名無しさん2010/09/11(土) 07:26:16
>>45
vistaからexplorerでリビジョン番号とか表示できなくなって使う意味が減った。
0052デフォルトの名無しさん2010/09/11(土) 07:39:57
>>45
Windowsでしか使えないこと
0053デフォルトの名無しさん2010/09/11(土) 07:48:12
>>47
直前だったらrollback
0054デフォルトの名無しさん2010/09/11(土) 08:07:30
>>45
バージョンアップ時にアンインストールが必要だったりして
複数回の再起動が必要だったりすること
業務中にはちょっと切ない。特に、他人にバージョンアップさせるときに
0055デフォルトの名無しさん2010/09/11(土) 14:23:24
TortoiseSVN、TortoiseGitが再起動要求する場面は
ログアウト→ログインで事足りるはずだよ
0056デフォルトの名無しさん2010/09/11(土) 18:05:35
再起動後にファイルの削除やリネームがスケジューリングされてることがあるから
それだけじゃ済まないだろ。
0057デフォルトの名無しさん2010/09/11(土) 19:52:56
強制的にexplorer落とすDropboxよりはナンボかマシｗ
0058デフォルトの名無しさん2010/09/14(火) 17:03:58
Subversion r12スレより誘導されてまいりました。

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

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

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

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

開発にはsubversionがあたりまえ、というようなことを耳にしましたが、このような開発環境でsubversionを導入するメリットというのはどんなものがあるのでしょうか？
0059デフォルトの名無しさん2010/09/14(火) 17:16:14
それはバージョン管理システムのメリットとは何かと問うているに等しいよ。
その言語と環境に特化していうべきことはない。
どっかの入門記事読んで試験的に導入してみた方が早い。
バックアップとは別にバージョン管理をするメリットは十分にあるとだけ言っておこう。

# 屋根裏尾はあえて使ってないみたいだけど
0060デフォルトの名無しさん2010/09/14(火) 17:19:09
>日毎にバックアップサーバーに保存

履歴がはっきりしてるならこれでいいよ
0061デフォルトの名無しさん2010/09/14(火) 17:30:54
>>58
何も困ってないのならそのままでもいいかも知れないけど、
導入すれば一般的なバージョン管理システムの恩恵が得られる
・変更内容を追うことができる（ログメッセージが役立つ）
・複数人体制になった時に行き違いを防止することができる（ファイル上書きなど）
・リリースバージョンと開発バージョンをフォークしたり（これは分散型のほうが得意）
・テスト＆バグ報告などを行う場合に、対象バージョンを特定しやすい
0062582010/09/14(火) 17:34:56
>>59
やはり差分が管理できるというのが一番の利点でしょうか？
環境は準備し、少し触ってみたのですが、いじったらコミットして、サーバーにもFTPで上げないといけないので面倒だなぁと感じております。

>>60
日毎でとってるので2週間程度はさかのぼれますが、1日に複数回、大幅な変更などをしたとき戻りにくい。
1年前とかのファイルは残ってない、というのが問題でしょうか？
0063デフォルトの名無しさん2010/09/14(火) 17:36:58
＞サーバーにもFTPで
いやサーバにリポジトリ作る、、というかサーバにシステム入れて使うのが普通
0064デフォルトの名無しさん2010/09/14(火) 17:43:23
>>63
そのサーバーって開発サーバーのことですよね
0065デフォルトの名無しさん2010/09/14(火) 17:44:57
>>62
大幅な変更があるならそのときだけ日ごとじゃなくて作業ごととかにすりゃいいんじゃね？
0066デフォルトの名無しさん2010/09/14(火) 17:45:48
>>58
FTPで接続とあるから、おそらくPHPコードのマスタはクライアントPC上に
あるのだと思うけど、Subversionによるバージョン管理というのは、
(テスト環境や運用環境ではなく)マスタとなる(PC上にある)PHPコードの変更履歴を
管理することを目的に導入するもの。バックアップの世代管理とは区別して考えなさい。

Subversionの遠い祖先にあたるSCCSというバージョン管理システムのSCCSという単語は、
Source Code Control System(ソースコード制御システム)の略語。
ソース(PHPコード)の管理が基本的な導入の目的だよ。
0067デフォルトの名無しさん2010/09/14(火) 17:49:58
作業コピーごとサーバに置いてソースコード流出
0068デフォルトの名無しさん2010/09/14(火) 17:54:40
>>67
> 作業コピーごとサーバに置いてソースコード流出
svnが各ディレクトリにできるから分散型の方が良いと思うけどどうなんだろう？
0069デフォルトの名無しさん2010/09/14(火) 17:56:10
>>68
> >>67
> > 作業コピーごとサーバに置いてソースコード流出
> svnが各ディレクトリにできるから分散型の方が良いと思うけどどうなんだろう？
ドット入れたつもりが抜けちゃった。
".svn"が各ディレクトリにできるから分散型の方が良いと思うけどどうなんだろう？
0070デフォルトの名無しさん2010/09/14(火) 17:58:37
>>69
できればリリース作業はVCSとは別にスクリプト作っておいたほうが良いと思う
0071デフォルトの名無しさん2010/09/14(火) 18:15:01
>>62
1ヶ月かかる新機能追加(既存ファイル変更しまくり)やってる後半に、現行版の緊急の修正が3個くらい舞い込んできたらどうしてんの？
0072582010/09/14(火) 18:35:22
後だしですみませんが、開発環境に追加で、Windowsのテキストエディタでコードを記述、FTPでファイルをアップロードしてます。
tortoisesvnの使用です。

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

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

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

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

>>71
本番サーバーから直接ファイルをダウンロードして、修正し本番サーバーにアップロード、修正した部分を変更中のものにも適用、というようなことをしています。
直接本番サーバーで作業するため、稀にエラーやらバグが発生しますが、事後修正で対応でいるようなサイトなので…
こんな考えだからsubversionの利点を見出せないのでしょうか…
0073デフォルトの名無しさん2010/09/14(火) 18:46:23
>>72
> 直接本番サーバーで作業するため
> こんな考えだからsubversionの利点を見出せないのでしょうか…
うんそう
そこで仕事が貰えてるなら、もうそのままで良いんじゃない？
君が不可能と考えてる事は簡単に可能だし、懸念してる手間など初めからないし
開発者のあり方として、素人の遊びレベルのクオリティだけど、まぁ、そのままで良いんじゃない？
0074662010/09/14(火) 18:59:28
>>72
>マスターのファイルは開発サーバー上にあります。
それなら、単純だ。開発サーバにSubversionを導入してコード管理すればいい。

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

>バージョン管理するために、ひと手間かけるという認識でよいのでしょうか？
開発サーバ上のSubversionリポジトリに最新コードをチェックインしたら、
その後のテスト環境へのチェックアウトは、手作業ではなくスクリプトで自動化させる。
make/Makefileあるいは類似の自動化ツールを勉強すること。慣れれば手間はかからない。
0075デフォルトの名無しさん2010/09/14(火) 19:07:48
>>72
> 後だしですみませんが、開発環境に追加で、Windowsのテキストエディタでコードを記述、FTPでファイルをアップロードしてます。
> tortoisesvnの使用です。
>
これはWindowsのローカルにリポジトリを置いているってこと？
BDB、FSFSどっち？
0076デフォルトの名無しさん2010/09/14(火) 19:40:15
> 開発にはsubversionがあたりまえ、というようなことを耳にしましたが、このような開発環境でsubversionを導入するメリットというのはどんなものがあるのでしょうか？

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

svnは使っているの？それとも、これから導入を考えているの？試し程度に少し触った程度なの？
「導入を考えて試しに少し触ったけど、メリットが見出せなかった。」だと思っていたんだけど、
どうも「TortoiseSVN使っているけど、メリットが見出せない」なのかな。
branchもtrunkも作らずにやっているのかしら？
0077デフォルトの名無しさん2010/09/14(火) 19:50:04
> 手元でファイルを修正→コミット＝アップロード
> というのは不可能ですよね。
subversionのpost-commit-hookでアップロードすればいい。
0078デフォルトの名無しさん2010/09/14(火) 19:53:04
こんなことなら元スレでやればよかったなｗ
0079デフォルトの名無しさん2010/09/14(火) 20:08:27
バグがあっても事後修正で対応してゴメンナサイすれば済むサイト(>>72)で、
そのくらいのソフトウェア品質管理水準を許容できる開発体制なのだから、
バージョン管理(SCM: ソフトウェア構成管理)導入の意味(目的/価値)が分からない。

>>73が言ってるように、それで仕事が貰えてるなら、そのままでいいんじゃないかと思う。
0080デフォルトの名無しさん2010/09/14(火) 20:25:53
ftp・rsyncってファイル上書きする可能性のあるので良くやっているなと感心する
0081デフォルトの名無しさん2010/09/14(火) 20:48:03
>>78
そうだなｗ
0082デフォルトの名無しさん2010/09/14(火) 22:33:13
引っ越してきました
末永くよろしくです

Git 2
http://hibari.2ch.net/test/read.cgi/tech/1284467898/
0083デフォルトの名無しさん2010/09/14(火) 23:28:11
>>72
> >>71
> 本番サーバーから直接ファイルをダウンロードして、修正し本番サーバーにアップロード、修正した部分を変更中のものにも適用、というようなことをしています。
> 直接本番サーバーで作業するため、稀にエラーやらバグが発生しますが、事後修正で対応でいるようなサイトなので…
> こんな考えだからsubversionの利点を見出せないのでしょうか…

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

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


今のままで廻っているなら別にいいと思うけどね。
将来的に困ると思うなら、自分の趣味ででもしばらく使ってみた方がいいよ
なれるまでちょっとした手間が増えるので面倒なのと、自分なりに便利さや効率的なやり方を実感していないと
他人に勧めにくい。
0084デフォルトの名無しさん2010/09/14(火) 23:30:18
他人に「素人の遊び」と言われようが、馬鹿だと言われようが
飯食えてるんだったら気にする必要ないと思うけどな

効率的な開発手法ばかり追っててまともに飯食えてない俺だからそう感じるんだろうけど
0085デフォルトの名無しさん2010/09/14(火) 23:35:16
ところで>>58は飯を食えているのだろうかw
0086デフォルトの名無しさん2010/09/14(火) 23:43:21
> 本番サーバーから直接ファイルをダウンロードして、修正し本番サーバーにアップロード、修正した部分を変更中のものにも適用、というようなことをしています。
> 直接本番サーバーで作業するため、稀にエラーやらバグが発生しますが、事後修正で対応でいるようなサイトなので…
> こんな考えだからsubversionの利点を見出せないのでしょうか…

何のために開発サーバー用意してんだ？
0087デフォルトの名無しさん2010/09/15(水) 00:04:38
まずはsambaを使って開発サーバ上のファイルを直接変更する環境にしてからだろう
そもそもこの程度の使い方ならsubversionはオーバースペック
cvsでも充分
0088デフォルトの名無しさん2010/09/15(水) 00:15:46
サーバがLinuxとは書いてないし、sambaのポートが開いていないリモートかもしれない
0089デフォルトの名無しさん2010/09/15(水) 00:34:02
cvsはないわーｗ
どう考えたら、svnはやめてcvsということになるんだ

Windowsを除けば、分散バージョン管理でいいんじゃんという時代になってきてるのに
0090デフォルトの名無しさん2010/09/15(水) 00:41:44
CVSはファイル名の変更や移動、それにディレクトリを管理できないという欠点があるからね。
SVN等の後継システムが登場したのだから、すみやかに引退してもらうのが正解。
RCSは単体テキストファイルの管理に限定すれば便利なツールだから、この先生き残るだろうけど。
0091デフォルトの名無しさん2010/09/15(水) 06:33:37
>>90
> RCSは単体テキストファイルの管理に限定すれば便利なツールだから、この先生き残るだろうけど。

これも、gitやbzrが入っていればそれでいいって話で。
0092デフォルトの名無しさん2010/09/15(水) 06:55:45
最後に残るのはsvnだけどね
他のお遊びscmとは意識レベルが全然違う
0093デフォルトの名無しさん2010/09/15(水) 07:18:54
最後に残るのはlatexだけどね
他のお遊び(ry
0094デフォルトの名無しさん2010/09/15(水) 07:58:40
>>91
確かに、ソースコード管理については(svnやgitがあるから)rcsの出る幕は無いだろね。
ただ、rcsはちょっとしたテキストファイルの来歴管理(たとえばhttpd,confや.bashrc)には
十分だし、ほぼすべてのUNIXマシンでインストールされているし、Windowsにも移植されてる。
だからrcsというプログラムそのものが消え去ることは無いだろう、ってことを言いたかった。
0095デフォルトの名無しさん2010/09/15(水) 08:03:41
ただ残ってるだけで誰も使ってないコマンドってあるよね
そんな生き残りに価値はあるんだろうか
0096デフォルトの名無しさん2010/09/15(水) 08:08:39
cvsの*,vってrcsとの互換ってまだあるんだっけ？
0097デフォルトの名無しさん2010/09/15(水) 10:17:28
>>94
* python とかがない状態でも動く
* リポジトリフォーマットがテキストなので、復旧だけなら他のコマンドを使ってもできる
ってあたりが、システムファイルいじる時には安心できるよね。
0098デフォルトの名無しさん2010/09/15(水) 13:16:00
>>99-91
ちょっとスレ違いかもしれないけど、 homeにあるdotfile管理するときってどうしてる？
.bashrcとかあのへんのUnix系の設定ファイル郡のこと。
別ディレクトリに置いてそっちをバージョン管理して、homeにsymlink貼るって形がいいのかな。

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

しかしWindowsだとsymlink貼るのに管理者権限必要なの面倒なのなんとかしろ
0099デフォルトの名無しさん2010/09/15(水) 13:18:13
悪い安価ミスった >>98は >>90-91についてのはなし
0100デフォルトの名無しさん2010/09/15(水) 13:29:16
おいらはホストごとに別ディレクトリでバージョン管理して symlink だなあ。

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

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

もちろんこれは個人の開発マシンに限定すべき事柄。もし本番サーバ等でやるなら、事前に承認を受ける。
0102デフォルトの名無しさん2010/09/16(木) 19:41:39
Mercurial使いたいのだが、日本語でコミットログ書くならBazaar一択？
Mercurialならdeps extensionでsvn:externalsっぽいことできるし、資料も豊富で楽なんだけど…
0103デフォルトの名無しさん2010/09/16(木) 19:44:56
>>102
ログは問題ありません。
HGENCODINGでぐぐって下さい。
0104デフォルトの名無しさん2010/09/16(木) 19:47:22
>>103
即レスサンクス！
これでMercurial安心して使えます
0105デフォルトの名無しさん2010/09/16(木) 22:41:58
>>101
素朴なギモンなんだけど、
RCSディレクトリを作るならRCS使い意味は何があるの？
ディレクトリ作るなら、git/とか作ってgit initしてそこにファイル於けばいいわけだし
0106デフォルトの名無しさん2010/09/16(木) 23:45:24
>>105
目的は、単体の設定ファイルやスクリプトを来歴管理したいという、ごく単純なもの。
gitがインストールされたマシン上でgitに慣れた人が同じ事をするのなら、(rcsではなく)gitを
使えばいいのではないかと。ただ、rcsは大半の環境で使える基本ツールだよ、って事を言いたかった。

git(あるいはsvn等の新しいツール)とrcsとは機能差が歴然としているから、単純な優劣での比較は無意味。
csh/tclsh/zshなど高機能なシェルが考案されてきたけど、未だにshが生き残っているのはナゼか考えてみよう。
0107デフォルトの名無しさん2010/09/16(木) 23:46:59
それは、あれだ
もう枯れきってバージョンアップもないだろうから、
10年経っても大丈夫、みたいなもんじゃなかろうか

違うか。ごめん。
0108デフォルトの名無しさん2010/09/17(金) 00:04:42
いや、まったくそのとおりだよ。
sh/awk/make/cc/yaccと同様に、UNIXが消え去らない限りrcsの知識は無駄にはならない、という意味で。
gitやsvnは(cvsがそうであったように)、さらに新しいツールが登場することで引退の道を歩むかもしれないけど。
0109デフォルトの名無しさん2010/09/17(金) 00:21:31
vssは？
0110デフォルトの名無しさん2010/09/17(金) 00:54:27
>>98
ぶっぱなす。ｗ

最近は、/etc/httpdとかも直にsvn管理
しちゃってる。
別に問題ないだろ。
0111デフォルトの名無しさん2010/09/17(金) 01:12:58
bashやzshの次がでたらそのうちとってかわられるかもしれないけど、shはそういう気がしないな
変わらないことが利点か

LinuxはシステムでPythonの利用が増えてきたけどそういう意味では不安だなｗ
0112デフォルトの名無しさん2010/09/17(金) 02:56:23
shはシェルスクリプトインタプリタとして必要だからね。

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

…とはいっても、Python3の利用が進んできたらいろいろ面倒はありそうだなw
0113デフォルトの名無しさん2010/09/17(金) 06:03:37
ああ、そっか。PythonはPerlの代わりか納得。
別バージョンの同居が考慮されてるのはいいね！

PerlやRubyはどうだっけか

Rubyは1.8と1.9の切り替えにRVMとか別途必要だった気もする
0114デフォルトの名無しさん2010/09/17(金) 06:32:25
perl早く無くなってくれないかな
0115デフォルトの名無しさん2010/09/17(金) 07:08:24
インデントきもいとか言って python 勉強してなかったつけがまわってきたぜ。

etc は .svn とかあると気持ちわるいんだよなぁ・・・
別の場所で編集して export でいいんだろうけど。
0116デフォルトの名無しさん2010/09/17(金) 08:05:43
PythonとPerlはLinux Standard Baseに入って殆どのLinuxでデフォルトでインストールされてるからな。
0117デフォルトの名無しさん2010/09/17(金) 08:23:25
annacondaがpythonだからpythonが無いとインストールができない
0118デフォルトの名無しさん2010/09/18(土) 00:48:45
トータル40GBのバイナリデータをストレスなく扱えるものはありますか？
PERFORCEなら問題ないんだけど、結構高いので。
0119デフォルトの名無しさん2010/09/18(土) 07:30:41
>>118
トータルサイズより、個別のファイルがどのくらいのサイズなのかのほうが重要に思う。
勝手な推論だけど、gitは向かないと思う。なぜならgitはファイルが更新(コミット)されるたびに、内部的に別ファイルとして保存するので、
たとえば1GBのデータをちょこっとだけ変更して保存すると、新しく1GBのファイルを作成して保存するから。
（packすればいいかもしれないけど、どのくらい効果があるか知らない）
0120デフォルトの名無しさん2010/09/18(土) 08:21:30
>>119
え？
git はパッチ、つーか、diffを保存するんじゃないの？
0121デフォルトの名無しさん2010/09/18(土) 08:32:24
バイナリでそれをやるのはsvnだけじゃね？
gitはとりあえず富豪的ってイメージ
0122デフォルトの名無しさん2010/09/18(土) 08:58:49
あ、そか。
バイナリの話か…。
って、svnってそれやるの？w
…だから、あんなクソ重いのかw
0123デフォルトの名無しさん2010/09/18(土) 10:21:36
>>120
gitは丸コピーって聞いたよ
0124デフォルトの名無しさん2010/09/18(土) 10:23:21
>>122
遅いのはリポジトリ圧縮するからじゃないのかな？
0125デフォルトの名無しさん2010/09/18(土) 17:37:20
http://hibari.2ch.net/test/read.cgi/prog/1284212440/149
0126デフォルトの名無しさん2010/09/19(日) 03:30:56
>>119
動画みたいなファイルでも、repackすればかなり小さくなるよ
（もちろん、差分的な更新履歴であることが条件だけど）
ヘタすると元のファイルより小さくなる場合もあるけど、あんまり大きなファイルだと
repackの時にメモリが足りなくなってしまう場合があった。

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

まあ１ファイル数ギガもあったりしたらそんなもんでしょ、という気もするんだけど
PERFORCEがそういうのでもサクサク分散できるんだとしたら、すごいなと思う。
0127デフォルトの名無しさん2010/09/20(月) 00:23:14
つか、gitになれたら、cvsとかsvnは使えない…
0128デフォルトの名無しさん2010/09/21(火) 19:44:37
gitは使いこなせてるとは言えんが、ファイル名をリネームしまくっても
何事もなく追随してくれるのが便利すぎる
0129デフォルトの名無しさん2010/09/21(火) 23:19:32
gitはリネームできてもコピーが出来なかった気が
0130デフォルトの名無しさん2010/09/21(火) 23:45:41
gitはかゆいところに手が届く感じの機能がいいな。
git add -p　とか、 git rebase -i とか
0131デフォルトの名無しさん2010/09/21(火) 23:54:45
gitはファイル名の変更を追跡しない。検出してるだけ。
だから遅いし、変更とファイル名の変更を同時に実行すると検出に失敗する。
hgはファイル名の変更をメタデータとして残すので、やはりannotateとかするのが遅いけど、
コピーにも同じ方式で対応できる。
bzrはファイルにIDを振っているので、annotateとかは速いし、ファイル名変更後に行った修正だけを
cherrypickとかできるけど、copyはまだ実装されていない。
0132デフォルトの名無しさん2010/09/22(水) 00:09:13
gitはリネーム用のコマンドは実質、削除と追加をしてるだけだけど、
ログ見るときに追跡ができるというところがミソだな。
コピーも追跡してくれればいいのにね
0133デフォルトの名無しさん2010/09/22(水) 00:10:23
>>131
> だから遅いし、変更とファイル名の変更を同時に実行すると検出に失敗する。

メタデータがないとこの問題あるのか
0134デフォルトの名無しさん2010/09/22(水) 07:47:08
>>131
とても役に立つことを聞いた。
0135デフォルトの名無しさん2010/09/22(水) 08:32:31
ファイル名とディレクトリ構成の変更をしょっちゅうやるからsvnから離れられない
0136デフォルトの名無しさん2010/09/22(水) 13:48:06
ファイル名を変えたらファイルの中身も1行ぐらいは書き換えないといけないことがほとんどと思うんだが、
実用上大丈夫なのかな……
0137デフォルトの名無しさん2010/09/22(水) 13:55:31
>>136
そういう場合は、2回に分けてコミットすると良い。
例えば、javaでパッケージ構成を変更したときなんかは、先にディレクトリ構成を変更してコミットし、次にpackage宣言を
修正してコミットする。
0138デフォルトの名無しさん2010/09/22(水) 14:18:14
ディレクトリ構成を変更したタイミングで
チェックアウトしたらビルドできないのかあ
0139デフォルトの名無しさん2010/09/22(水) 14:38:42
>>137
その場合、変更要因は１つだけどコミットは２度発生するよね。
変更要因とコミット操作の関係を管理したかったら、タグとか使うしか無いのかな。
0140デフォルトの名無しさん2010/09/22(水) 15:46:34
>>137
ディリクトリ、ファイル名の変更と#includeの変更はまとめて一回のコミットでやってるけど、分けてやる理由ってなんだろう。
0141デフォルトの名無しさん2010/09/22(水) 17:38:41
>>140
つ>>133
0142デフォルトの名無しさん2010/09/22(水) 17:45:28
分けてやると、ビルド通らないリビジョンができるじゃん？それはいいの？
0143デフォルトの名無しさん2010/09/22(水) 18:14:54
git固有の話みたいだけど、分散型の場合、まとめてpull/pushするからコミットの粒度も絡んだ運用の話なんじゃない？
0144デフォルトの名無しさん2010/09/22(水) 18:42:54
>>131
ここまでリネーム・コピーの扱いが違うと
git/hg/bzrをsvnクライアントとして使った時に何かと厄介になりそう
0145デフォルトの名無しさん2010/09/22(水) 18:47:00
話についていけない漏れは、svnを使い続けることに決めたw
0146デフォルトの名無しさん2010/09/22(水) 21:58:53
>>131
変更とファイル名の変更を同時に実行すると検出に失敗するって言っても
そりゃ原形を留めてないほど変更したときの話じゃね？

かなり書き換えてかつリネームしたとき、create になるかと思ったら
rename foo/{bar.js => baz.js} (70%)
みたいに表示されてるし
0147デフォルトの名無しさん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
0148デフォルトの名無しさん2010/09/22(水) 22:35:58
なんかここ最近になって一気に有用な話になってる気がするのは俺だけ？
0149デフォルトの名無しさん2010/09/22(水) 22:36:25
>>145
食わず嫌いしないで、試してみなよ。
gitはベターsvnでもあるんだぜ？
0150デフォルトの名無しさん2010/09/22(水) 22:48:22
βsvnなんぞイラン
0151デフォルトの名無しさん2010/09/22(水) 23:26:40
ベターsvnはTeam Foundation Serverなんじゃない？

http://sourceforge.jp/magazine/10/09/09/0717220
>Subversionと互換性のある独自のバージョン管理システム「Team Foundation Server」を提供している。
0152デフォルトの名無しさん2010/09/22(水) 23:31:20
わかった、言い方が悪かったよw

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

で、いいか？w
0153デフォルトの名無しさん2010/09/22(水) 23:35:14
>>146
原形を留めてないほど変更した場合のことを考えると、ファイルの移動って何？
みたいになるよね。Gitのやり方は利にかなってると思う。
0154デフォルトの名無しさん2010/09/22(水) 23:44:17
>>152
TortoiseGitがTortoiseSVNと同じくらいにならないと説得力が無いと思うがな
0155デフォルトの名無しさん2010/09/23(木) 05:30:46
>154
Subversion 使いがみんな TortoiseSVN 使ってるわけでもなし、コマンドラインなら
git-svn は普通に便利だよ。
0156デフォルトの名無しさん2010/09/23(木) 09:18:28
じゃあこうだな

少なくともCUIでの利用に限定すれば、gitはベターなSubversionクライアントでもある。
0157デフォルトの名無しさん2010/09/23(木) 09:29:24
だが、いまだ濁点付き日本語ファイル名に対応してないという
(Macだけ？)
0158デフォルトの名無しさん2010/09/23(木) 10:00:16
>>157
kwsk
0159デフォルトの名無しさん2010/09/23(木) 10:08:33
MacはNFDだから濁点の扱いがWinやLinuxと異なるってだけじゃなくて？
0160デフォルトの名無しさん2010/09/23(木) 14:32:30
gitはLinuxのことしか考えてないから仕方ないよ。
ファイル名=バイト列なんてのは、ファイルシステムによっては成立しないダメダメな前提なんだけど
そもそも環境変数LANGでファイル名の解釈が変わったりするLinuxでは必要な前提だしね。

だがMercurial、てめーは駄目だ。
0161デフォルトの名無しさん2010/09/23(木) 14:58:44
>>160
> そもそも環境変数LANGでファイル名の解釈が変わったりするLinuxでは必要な前提だしね。
kwsk
0162デフォルトの名無しさん2010/09/23(木) 15:14:21
>>161
いや、NTFSやHFS+ならファイル名が格納されるときの文字コードは決まってるけどさ、
extとかのファイル名はメタデータも何も無い単なるバイト列じゃん。
それを文字コードとして解釈するかはLANG次第で、ja_JP.UTF-8からja_JP.EUCに変えたりすると化けるじゃん。
0163デフォルトの名無しさん2010/09/23(木) 15:20:40
>>162
http://hibari.2ch.net/test/read.cgi/tech/1093251312/239-
0164デフォルトの名無しさん2010/09/23(木) 15:35:39
>>163
読んだが、いくつかの流派が不毛な言い合いをしてるだけだろ。
どの流儀でも統一さえ取れていればある意味問題ないとも言えるんだし
163が何派なのかも書いてくれんと、そもそも何を言いたいのかもわからんよ。
0165デフォルトの名無しさん2010/09/23(木) 15:45:00
WindowsのBazaar入れてみたら、Bazaarエクスプローラーは結構いいな。
ウィザード風に次何やるのってのを教えてくれる。
すでにわかっている人にはいらないんだろうけど、ドキュメント読んで使い始めようという時に敷居下がる

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

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



ほぼ作り直してるんだろうけど、TortoiseSVN以降使いにくい部分もあれば
使いやすくなっている部分もあるよ。
0166デフォルトの名無しさん2010/09/23(木) 15:47:31
>>159
Macユーザーの書き込みは濁点が離れてるからすぐわかるってやつか

が → か゛

になるようなやつ
0167デフォルトの名無しさん2010/09/23(木) 16:29:01
>>166
それはデマだ。Unicode上でNFDだろうがNFCだろうが、2chはSHIFT-JISだから区別のしようがない。
あと合成文字と「単独の文字として存在している濁点」には何の関係もない。
0168デフォルトの名無しさん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の人にはそれがわからんのですよ。
0169デフォルトの名無しさん2010/09/23(木) 18:41:26
Macユーザーの書き込みは、
「ば~か」
などを見るとすぐに分かる。
0170デフォルトの名無しさん2010/09/23(木) 18:57:39
どれ。ちょっと書いてみるか。>>169のば～か
0171デフォルトの名無しさん2010/09/23(木) 19:02:36
>>169
ば~か
0172デフォルトの名無しさん2010/09/23(木) 19:06:38
>>169のば～か

バックスラッシュがyenマークになるってのならよくあるが
0173デフォルトの名無しさん2010/09/23(木) 19:09:21
>>169
ば～か
0174デフォルトの名無しさん2010/09/23(木) 19:10:09
よし、漏れも便乗w

>>169
ば～か
0175デフォルトの名無しさん2010/09/23(木) 19:12:46
>>169
%E3%81%B0%EF%BD%9E%E3%81%8B
0176デフォルトの名無しさん2010/09/23(木) 19:59:13
>>169
ば〜か
0177デフォルトの名無しさん2010/09/23(木) 21:25:39
なんだこの大人気
0178デフォルトの名無しさん2010/09/23(木) 21:49:26
暴釣りだね。でも、漏れはそこまで自虐的になれないw
0179デフォルトの名無しさん2010/09/23(木) 21:52:47
ぼうつり
0180デフォルトの名無しさん2010/09/23(木) 22:17:06
>>178
ば～か
0181デフォルトの名無しさん2010/09/24(金) 00:13:53
Macから書き込み。

がぎぐげご。

そうならんぞ。
0182デフォルトの名無しさん2010/09/24(金) 01:47:25
>>181
ば〜か
ば～か
0183デフォルトの名無しさん2010/09/24(金) 01:51:57
>>177
「おとなげ」って読みたくなってきた
0184デフォルトの名無しさん2010/09/24(金) 02:02:42
>>169のせいでスレの空気が一気に低レベルに....
0185デフォルトの名無しさん2010/09/24(金) 02:17:22
>>184
スレのレベルは初めから低かった
01861662010/09/24(金) 02:18:32
むしろ俺のせいな気がしてならない・・・
0187デフォルトの名無しさん2010/09/24(金) 02:22:55
>>186
若干自意識過剰だな
0188デフォルトの名無しさん2010/09/24(金) 03:01:15
何子のスレ
0189デフォルトの名無しさん2010/09/24(金) 03:39:00
>>167
クライアントによっては「が→か゛」になるよ。
Shift_JIS に変換するのはクライアントなわけだから、NFD への対応が甘ければ化ける。
0190デフォルトの名無しさん2010/09/24(金) 03:45:32
数%にも満たない糞マカーのお陰で、確実に無駄な工数が増えてIT産業の粗利が減ってるわけだ
0191デフォルトの名無しさん2010/09/24(金) 07:33:07
>>189
クライアントソフトの性ならmacに限った話にならないだろ
0192デフォルトの名無しさん2010/09/24(金) 07:44:47
>>191
ば〜か
ば～か
0193デフォルトの名無しさん2010/09/24(金) 07:51:40
>>190
それは、最初に世界中の文字が2バイトに収まると思った馬鹿に言えよ……
0194デフォルトの名無しさん2010/09/24(金) 08:00:35
>>193
UTF-16が馬鹿だと認めたのですね
0195デフォルトの名無しさん2010/09/24(金) 08:21:56
Unicodeの、誰もが無視すべき最悪の馬鹿仕様部分を愚直に実装した愚mac
0196デフォルトの名無しさん2010/09/24(金) 08:28:11
いやほんとにば～かだと思うよ。
ただ現在進行形でNFDにしかない文字にNFCが追加されている部分もあるので、無視すべきとは思わんな。

UTF-16のためにサロゲートペア領域もぽっかり穴が開いてしまってるわけだし、
最初から4バイト使うつもりでいれば合成文字もサロゲートも無かったはずなのに……
0197デフォルトの名無しさん2010/09/24(金) 08:35:41
突っ込んだ文字コードの話はよそでやってください
0198デフォルトの名無しさん2010/09/24(金) 08:45:48
>>197
つ>>160
0199デフォルトの名無しさん2010/09/24(金) 10:51:45
>>160の流れだと言いたいんだろうが、>>196は単にUnicodeの話でしかない。
0200デフォルトの名無しさん2010/09/24(金) 12:10:24
>>199
このスレの管理人を気取るのはいいが、それなら>>196ではなく、
文字コードの話にかこつけて「煽り」をカキコした>>169と
それに釣られた>>170以降のカキコを責めるべきだろ。
今さらノコノコ出勤して、どれだけ無駄な時間が過ぎたと思ってんだ。
管理人なら管理人らしく、仕事をサボってんじゃねえよ。
0201デフォルトの名無しさん2010/09/24(金) 12:36:01
○○くんもやってるからぼくはわるくないもん！
0202デフォルトの名無しさん2010/09/24(金) 12:41:07
UTF-16信者が>>160のような無知・誤解を広めるのはいい迷惑
0203デフォルトの名無しさん2010/09/24(金) 12:45:33
ユニコードって完璧だもんね☆
0204デフォルトの名無しさん2010/09/24(金) 13:01:02
>>169の7Ehの話一切なし
0205デフォルトの名無しさん2010/09/24(金) 15:44:13
>>202
なんでUTF-16信者だと思うんだ？
0206デフォルトの名無しさん2010/09/24(金) 17:29:29
TortoiseSVNを半年ぶりに最新版にしたら、インストールしてもTortoiseのメニューが出てこねー。
でも、スタートメニューからは起動する。
古いの探す旅に出るか。
0207デフォルトの名無しさん2010/09/24(金) 17:51:54
Windows再起動しろ
0208デフォルトの名無しさん2010/09/24(金) 17:54:12
修復インストールしろ
0209デフォルトの名無しさん2010/09/24(金) 18:02:35
ちゃんと64bit版svn入れろや
0210デフォルトの名無しさん2010/09/24(金) 18:06:30
>>208が正解
他はゴミレスなんでスルーで
0211デフォルトの名無しさん2010/09/24(金) 18:20:46
うまく入った。
最終的に、アンインストール→ccleanでレジストリ掃除。
再起動後にインストール→失敗。

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

お騒がせしました。
0212デフォルトの名無しさん2010/09/28(火) 09:44:09
コンパイルしてできたバイナリってバージョン管理するものなの？
0213デフォルトの名無しさん2010/09/28(火) 09:47:08
前スレでやってLaTeXはその延長
0214デフォルトの名無しさん2010/09/28(火) 12:20:40
>>212
ソースがあればバイナリできるんだからバージョン管理の必要は無い。
だけど、リリースとかの区切りでコミットしておくとビルドしなくてもバイナリを取り出したり比較できたりして便利。
0215デフォルトの名無しさん2010/09/28(火) 18:36:39
>>214
毎回コミットしてたぜ。TortoiseSVN使ってるとオーバーレイアイコンが気になって気になって…
0216デフォルトの名無しさん2010/09/28(火) 18:49:31
タイムスタンプだけ違う内容の同じファイルが大量にできるのが嫌だなぁ。
0217デフォルトの名無しさん2010/09/28(火) 20:53:58
>>215
svnignore 設定するんじゃ駄目？
0218デフォルトの名無しさん2010/09/28(火) 22:48:05
オーバーレイアイコンが気になるだけの話ならば、無視ファイルに突っ込めばいいと思うよ
0219デフォルトの名無しさん2010/09/29(水) 06:46:46
タイムスタンプだけ違う内容の同じファイルはできないだろ？
0220デフォルトの名無しさん2010/09/29(水) 07:09:46
できる
0221デフォルトの名無しさん2010/09/29(水) 12:26:36
>>215
tortoiseSVNなら、変更リストがある。

コミットダイアログで変更されたファイル右クリック→変更リストへ移動→ignore-on-commitとすると、変更リストができる。
変更リストのファイルは変更されていてもコミットのチェックが自動ではつかなくなる。これでコミットを抑制できる。
変更リストはリポジトリには影響しないからローカルで指定できる。
0222デフォルトの名無しさん2010/09/29(水) 12:35:21
>>220
タイムスタンプが違っただけでコミットされたら困るだろう。
0223デフォルトの名無しさん2010/09/30(木) 23:05:27
実行モジュールは納品とかバージョンの単位でコミットする運用だった。
今は Redmine 上に乗せる運用にかわったけど。
0224デフォルトの名無しさん2010/10/03(日) 16:14:56
うちもお客さんの所に納めるものはコミットしてる。

ソースがあればバイナリできると言うけど、バイナリにコンパイルした
日時を埋め込んだりされるのでソースは同じでもバイナリは完全に一致
しないことがあるから。
0225デフォルトの名無しさん2010/10/03(日) 21:30:46
そこらへんはHudsonにまかせる運用にしたな。
0226デフォルトの名無しさん2010/10/04(月) 01:01:08
あぁ、ハチのマークの
0227デフォルトの名無しさん2010/10/04(月) 05:29:39
何でバージョン管理システムってユニコードに憎悪を持ってるの？
0228デフォルトの名無しさん2010/10/04(月) 06:37:10
>>227
なんか妄想激しくないか？
0229デフォルトの名無しさん2010/10/04(月) 08:03:59
>>227
このスレに話を理解できない・ついていけない人が大勢いるのは事実
0230デフォルトの名無しさん2010/10/08(金) 11:25:19
diff Europe USA
http://pds.exblog.jp/pds/1/200710/20/99/b0117999_5491615.jpg
0231デフォルトの名無しさん2010/10/09(土) 00:53:30
>>230
全く1byte文字圏の連中はセクシーがなんたるかを分かってないな。
2byte文字に対応した画像を貼ってください
0232デフォルトの名無しさん2010/10/09(土) 01:14:47
>>231
2bytes圏に美人が多いのは認める。
しかし3bytesを無視するのは許さん。
0233デフォルトの名無しさん2010/10/20(水) 06:01:56
SubversionからGitへ乗り換えを検討してみたけど
導入の手間（特に利用者への負担）と管理の煩雑さを考えると
現状維持がいいのかなと思ってしまった
0234デフォルトの名無しさん2010/10/20(水) 07:28:24
管理ウゼェ勝手にしろがgitだから、管理したいならgitなんて考慮に値しない選択肢だよ
0235デフォルトの名無しさん2010/10/20(水) 07:38:27
利用者がrebaseとかresetとか覚え始めて
ログが破綻するのがsvn->gitの本当の最初の試練
0236デフォルトの名無しさん2010/10/20(水) 08:34:17
>>233
乗り換えらくちんちん
0237デフォルトの名無しさん2010/10/20(水) 08:55:50
>>234
バックアップ取っていたつもりが取れていなくて全てパーになるのですね。わかります。
0238デフォルトの名無しさん2010/10/20(水) 09:13:09
某るｂｙみたくsvn鯖まるごとクラックされたりとか
0239デフォルトの名無しさん2010/10/20(水) 10:32:51
>>233
導入の手間はサーバが無いと何もできないSubversionの方がはるかに手間がかかる
0240デフォルトの名無しさん2010/10/20(水) 13:59:00
Subversion って sshd だけ動いてれば大丈夫っしょ
0241デフォルトの名無しさん2010/10/20(水) 14:27:30
導入の手間（特に利用者への負担）ってのが読めないのかこの馬鹿は
一体どれだけ狭い世界に生きてんだよ
0242デフォルトの名無しさん2010/10/20(水) 14:51:25
乗り換えつってんだから、現状Subversionはインストール済みだろうし
手間はゼロだなｗ
0243デフォルトの名無しさん2010/10/20(水) 15:38:11
>導入の手間（特に利用者への負担）
・git svn clone のミラーを立てる
・svnしか使えないお馬鹿さんはsvnを使い続ける
・gitが使える普通の人はgitを使う
0244デフォルトの名無しさん2010/10/20(水) 17:16:54
・かしこいgitユーザーはsvnユーザーに不都合が出ないように注意する
・svnユーザーに不都合が出た時にはかしこいgitユーザーが何とかする

こうなることが予見される訳だが
0245デフォルトの名無しさん2010/10/20(水) 18:15:38
・かしこいgitユーザーを見よう見まねのかしこくないgitユーザーが出現
こうなることが予見される訳だが
0246デフォルトの名無しさん2010/10/20(水) 18:25:22
・かしこくないgitユーザにはpush権をやらない
・練習用のリポジトリを使わせる
・かしこいgitユーザがログを綺麗にしてからpushする
0247デフォルトの名無しさん2010/10/20(水) 18:52:59
Bazaar導入でスッキリ解決
0248デフォルトの名無しさん2010/10/20(水) 18:54:38
VSS導入でスッキリ解決
0249デフォルトの名無しさん2010/10/20(水) 19:31:53
ClearCase導入でスッキリ解決

そして誰もいなくなった
0250デフォルトの名無しさん2010/10/20(水) 20:25:18
>>246
ログを綺麗にする方法について
具体的に教えて頂けませんか？
0251デフォルトの名無しさん2010/10/20(水) 22:32:19
>>250
git push :master
0252デフォルトの名無しさん2010/10/20(水) 22:47:22
>>251
それがあんまり洒落になってないところがgitの扱いづらさ
0253デフォルトの名無しさん2010/10/20(水) 23:13:28
おまいら svn しか使えない馬鹿ものっていうけどな
svn も使えない馬鹿ものも多いんだぞ
0254デフォルトの名無しさん2010/10/21(木) 00:19:16
>>233 >>239
以前、散々開発してた途中でバージョン管理してないプログラマ一人のプロジェクトが見つかって、
何でリポジトリ作ってないんだよって問いただしたら、
管理者じゃないからリポジトリ作れなかったって話を思い出した

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

ま、これは、コミュニケーション不足が主な原因だったわけだが
0255デフォルトの名無しさん2010/10/21(木) 00:23:58
そもそも、自由に履歴をいじれるバージョン管理ソフトって、
やり過ぎ感が否めない
便利なのはわかるけど、結局何がしたいんだろうって
0256デフォルトの名無しさん2010/10/21(木) 01:12:39
・過去の履歴にパスワードなど個人情報が入ってしまっている
・コミットログを間違えたが、管理者かサーバー側でログ修正を許可しないと修正できないので、
　ソースに改行を挿入してもう一度コミットした

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

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

0257デフォルトの名無しさん2010/10/21(木) 03:20:57
リポジトリにパスワードなんて突っ込むような大馬鹿野郎がgitをありがたがるという事ね
なるほど
0258デフォルトの名無しさん2010/10/21(木) 06:00:28
脳に蛆が湧いた奴がいるな
0259デフォルトの名無しさん2010/10/21(木) 08:34:18
>>253
cvsを使っていてsvnを選ばなかったのなら勝ち組
バージョン管理をしていないのなら分散型で始めれば良い
0260デフォルトの名無しさん2010/10/21(木) 09:05:44
>>254
コミュ不足というよりは、マニュアルくらい
読めよ、て思った。
そいつ自身の自業自得じゃね？
0261デフォルトの名無しさん2010/10/21(木) 09:08:00
とにかく分散すればありがたい、とハードワイアで結合されたニューロンたち。
0262デフォルトの名無しさん2010/10/21(木) 09:16:47
さぁ、早くsvnでcherry-pickとrebaseをする仕事に戻るんだ
0263デフォルトの名無しさん2010/10/21(木) 09:19:09
>>259
じゃあ俺は勝ち組だな。
cvs → hg & bzr
svn は、cvs を徹底的にこき下ろすコミュニティの態度が気に入らなかった。
別に cvs の悪口言うなってんじゃないけど、ほかを叩くことで自分を持ち上げるような
性根は嫌いだ。
0264デフォルトの名無しさん2010/10/21(木) 09:24:00
ruby は、perl/C++ を徹底的にこき下ろすコミュニティの態度が気に入らなかった。
別に perl/C++ の悪口言うなってんじゃないけど、ほかを叩くことで自分を持ち上げるような
性根は嫌いだ。
0265デフォルトの名無しさん2010/10/21(木) 09:27:52
git は、svn を徹底的にこき下ろすコミュニティの態度が気に入らなかった。
別に svn の悪口言うなってんじゃないけど、ほかを叩くことで自分を持ち上げるような
性根は嫌いだ。
0266デフォルトの名無しさん2010/10/21(木) 09:32:39
敗者の被害妄想
0267デフォルトの名無しさん2010/10/21(木) 10:16:25
たしかに勝者は被害妄想しないな。
0268デフォルトの名無しさん2010/10/21(木) 10:26:32
つうか cvs はねえよ
慣れの問題はあるけどさ
0269デフォルトの名無しさん2010/10/21(木) 10:32:18
>>256
svnにしがみつくことに必死な馬鹿にまともにレスしても無駄だから
0270デフォルトの名無しさん2010/10/21(木) 10:33:17
ここ数年で急に分散型が台頭してきたよな。
どれが淘汰されて、どれが生き残るのか、
まだ分からんので必要に迫られない限り様子見してる。
あと数年は分散型が乱立した状況が続くんでないかと思う。

新しいものに飛びついたからって、勝った事にはならん。
むしろ、飛びついた先の船が沈没しないことを祈りなされ。
0271デフォルトの名無しさん2010/10/21(木) 10:38:09
gitは沈没しなさそう
0272デフォルトの名無しさん2010/10/21(木) 11:05:12
cvs -> svn -> svk -> git ときた俺だけど、理想過ぎてもうGit無しでは生きていけない
0273デフォルトの名無しさん2010/10/21(木) 11:06:16
沈没してもfast-exportで別のVCSに移行できる
svnにしがみついているのは、ブランチが複雑だったり、copyでブランチを作っていなかったりして、
移行もままならないプロジェクト
0274デフォルトの名無しさん2010/10/21(木) 12:07:21
git → linuxが捨てなければ大丈夫
bzr → GNUが捨てなければ大丈夫
hg → microsoftが捨てなければ大丈夫
0275デフォルトの名無しさん2010/10/21(木) 12:19:59
一番怪しいのはhgか
0276デフォルトの名無しさん2010/10/21(木) 12:57:35
Oracleもいるよ? いる…よ？
0277デフォルトの名無しさん2010/10/21(木) 13:44:05
Microsoftはhgラブだったのか
0278デフォルトの名無しさん2010/10/21(木) 13:45:58
svnラブでしょ >>151
0279デフォルトの名無しさん2010/10/21(木) 13:54:52
>>151の記事って表題が
＞米Microsoft、バージョン管理システムMercurial開発プロジェクトに25,000ドル寄贈
0280デフォルトの名無しさん2010/10/21(木) 14:42:47
Mercurialが一番、どこの陣営の色も付いてないから？
0281デフォルトの名無しさん2010/10/21(木) 15:44:00
>>280
実装が一番楽だからじゃないか
0282デフォルトの名無しさん2010/10/21(木) 16:56:58
たった250万円かよ・・・。
0283デフォルトの名無しさん2010/10/21(木) 16:59:51
その頃1ドル85円ぐらいじゃなかったっけ
0284デフォルトの名無しさん2010/10/21(木) 17:06:06
一番必死で一番性格が悪いのがGit陣営だと良く分かった
0285デフォルトの名無しさん2010/10/21(木) 20:56:24
>>280
mercurialはsun色じゃなかったんだ？
0286デフォルトの名無しさん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
0287デフォルトの名無しさん2010/10/21(木) 23:23:18
gitでもhgでもbzrでもいいけど分散型に慣れたあとsvnを触るとコミットするのがすごく怖く感じる

0288デフォルトの名無しさん2010/10/22(金) 00:40:41
brancheにCommitする習慣が必要あるね
0289デフォルトの名無しさん2010/10/22(金) 05:49:57
>>274
Googleもhgじゃね？
0290デフォルトの名無しさん2010/10/22(金) 06:35:58
>>289
http://hibari.2ch.net/test/read.cgi/tech/1284467898/84
0291デフォルトの名無しさん2010/10/22(金) 06:41:21
ﾊｹﾞﾊｹﾞうるせー
0292デフォルトの名無しさん2010/10/22(金) 07:34:56
散々、gitの開発者は日本人だ日本人だと煽っておいて、gitの日本人コミッタって在米かよ。
米国でノーベル賞とった日本人研究者を喜んでる日本人みたいじゃねーか。

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

むろんコミッタには罪はないんだが。
0293デフォルトの名無しさん2010/10/22(金) 07:35:45
bzr は、hg や git の日本語対応を徹底的にこき下ろす2chコミュニティの態度が気に入らなかった。
別に hg や git の悪口言うなってんじゃないけど、ほかを叩くことでbzrを持ち上げるような
性根は嫌いだ。
0294デフォルトの名無しさん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は変更不可のオブジェクトが蓄積していくだけ。
0295デフォルトの名無しさん2010/10/22(金) 09:57:07
>>294
その二つは同じことを言ってるだけだよな
gitでgcをoffにしたら解決する話のような
0296デフォルトの名無しさん2010/10/22(金) 10:36:09
>>292-293
そんなことでバージョン管理システム決めるなよｗｗ

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

今から個人のバージョン管理するなら、プライベートリポジトリの制限なくなった
BitBucketが使えるhgが良いんじゃないかな。CodePlexもGoogle Codeでも使えるし。
0297デフォルトの名無しさん2010/10/22(金) 10:42:17
>>296
UTF-16が安心？
0298デフォルトの名無しさん2010/10/22(金) 10:51:07
gitはコミッタが日本人だから安心とか言ってるBlogあったけど
彼って多言語対応に一切興味を示さないよね
0299デフォルトの名無しさん2010/10/22(金) 11:22:23
自分が必要してないのに泥沼確定してる多言語対応に手を出したくない
気持ちはわからなくもない
0300デフォルトの名無しさん2010/10/22(金) 12:21:04
元々Gitにかかわろうと思った動機も　コード1200行しかなくて簡単そうだったから　だもんな
面倒な問題の解決については一切期待できない人物
0301デフォルトの名無しさん2010/10/22(金) 13:18:30
>>296
>チームで、みんなにcygwinやmsysをインストールさせるのがいやだったらgitが
>選択肢から外れる。

それは誤解
0302デフォルトの名無しさん2010/10/22(金) 13:40:05
ファイル名にUTF-8が使えるのが多言語対応じゃないのですか？
0303デフォルトの名無しさん2010/10/22(金) 13:50:53
ファイル名にUTF-8が使えるのは多言語化の現実的な実装法の一つだがイコールではない
0304デフォルトの名無しさん2010/10/22(金) 13:55:03
ファイル名をUCSにするのは多言語化の現実的な実装法の一つだがイコールではない
0305デフォルトの名無しさん2010/10/22(金) 13:58:08
svnかhgのどちらでもいいのですが（あれば両方とも）
指定した２つのリビジョン間の差分ファイルのみを
ローカルにコピーする機能ってありませんか？
0306デフォルトの名無しさん2010/10/22(金) 13:59:29
差分ファイルってのは断片ではなく、ソースファイル丸ごとという意味です。
0307デフォルトの名無しさん2010/10/22(金) 14:45:15
>>301
msysやcygwinに依存しないWindows用gitってあるの？
0308デフォルトの名無しさん2010/10/22(金) 15:08:01
っていうか、依存しちゃうとマズイことあるの？
push/pollなどのプロトコルさえ通じれば、実装はなんでもいいのでは？
（おれはどのくらいmsys/cygwinがソレに依存しているか詳しくないのだけど）
0309デフォルトの名無しさん2010/10/22(金) 15:26:12
微妙に名前の違う同じ名前のexeがいくつもあると容易に嫌なことが起きやすいのは
想像できるな
0310デフォルトの名無しさん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.
0311デフォルトの名無しさん2010/10/22(金) 16:04:48
>>308
ファイル沢山入って重い
既存のコマンドと同名で別のコマンドがインストールされる恐れがある。
(Windowsのfindとか)
もともとCygwin/mingw使っている人に新しくmingwかなにかをインストールさせた
場合、環境の切り替えが大変。

>>310
おぉ、gitが入ったmingw環境をインストールさせるのかと思ってた。
0312デフォルトの名無しさん2010/10/22(金) 16:26:02
gitそのものがシェルスクリプトとか使ってるのにどうやってるの？
0313デフォルトの名無しさん2010/10/22(金) 16:35:44
portableGIT使えばいいじゃない
0314デフォルトの名無しさん2010/10/22(金) 16:43:04
>>311
pathが違うから大丈夫
っていうか Git のみインストールすれば
Git 専用の Bash が出来てその中だけで完結出来て
他に悪影響出ないよ
0315デフォルトの名無しさん2010/10/22(金) 16:57:57
>>314
元々msysやcygwin使ってた人からすると、msysやcygwinのbashからgitを呼べないと使い物にならねえ
って言う人がほとんどじゃね？
0316デフォルトの名無しさん2010/10/22(金) 17:04:53
PATH通せばいいだろ
0317デフォルトの名無しさん2010/10/22(金) 17:07:03
msysにしろcygwinにしろ、POSIX APIを.dllで提供してるから
共通のものを使ってくれないとだめだろ
WindowsのPATHだけ通しても、/usr/みたいなPOSIX PATHが別のところになっちゃうぞ
0318デフォルトの名無しさん2010/10/22(金) 17:21:06
gitってまだ外部コマンドに依存しているのが残っているの？
0319デフォルトの名無しさん2010/10/22(金) 17:21:44
WindowsのPATHは通さない
0320デフォルトの名無しさん2010/10/22(金) 19:05:16
GITってlinux（POSIX）依存が抜けないんだよね。
そういう部分で苦労させられると、ハードゲイの方がよく思えてくる。
0321デフォルトの名無しさん2010/10/22(金) 19:11:27
cygwinしかなかった時に比べると進化している。
でも、TortoiseGitは進化するのだろうか？
0322デフォルトの名無しさん2010/10/22(金) 19:28:22
フォーー！
0323デフォルトの名無しさん2010/10/22(金) 22:58:54
>>296
>>263 >>264 >>293
0324デフォルトの名無しさん2010/10/22(金) 23:07:35
>>311
msysGitだとmsys環境だけにパス通したコマンドプロンプト立ち上げる機能ついてきたはず。

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

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

TortoiseGitもコマンンドライン版を要求してコマンンドライン版の実装に激しく依存する
文字コードの問題もそう。
0325デフォルトの名無しさん2010/10/22(金) 23:11:56
>>321
TortoiseGitはgitは日本語ファイル名の問題ある、TortoiseGit側にも文字コードの問題ある
二重苦
0326デフォルトの名無しさん2010/10/22(金) 23:17:46
そうなんだ。
GITはファイル名じゃなくて、inodeみたいなidで持ってるんだから、
ファイル名の問題は解決済みなのかと思ってたよ。
そもそも、日本語ファイル名なんか使わないけど。
0327デフォルトの名無しさん2010/10/23(土) 11:57:29
>>300
なにその「濱野は楽したいだけのクソ野郎」みたいな言い草
0328デフォルトの名無しさん2010/10/23(土) 12:25:54
なにもクソも本人談そのままだし
お前がそう感じたならそう言う事なんだろう
0329デフォルトの名無しさん2010/10/23(土) 12:28:33
「面倒な問題」って何ですか？
0330デフォルトの名無しさん2010/10/23(土) 13:40:29
中身見たことないけど1200行とかCのソースとしてはものすごい短いものだから
本気で取り組んだらわからない部分なんてないんじゃないの
0331デフォルトの名無しさん2010/10/23(土) 14:00:33
>>330ほどの馬鹿発言する奴が何故バージョン管理スレに居るのだろう
0332デフォルトの名無しさん2010/10/23(土) 14:09:35
と、1200行のCのソースも理解できない馬鹿が言っています
0333デフォルトの名無しさん2010/10/23(土) 21:38:11
>>330
>>332
こいつは今のGitが1200行で動いてると思ってんのかｗｗｗ
0334デフォルトの名無しさん2010/10/23(土) 21:41:16
何言ってんの。
短い行数でこれだけの機能を実現しているということは
作者にしかわからないトリッキーなコードに決まってるじゃん。
0335デフォルトの名無しさん2010/10/23(土) 21:43:51
1200行で動いてるんなら、マルチバイト対応も、むしろ逆に簡単なんだろうけどな
そういうことではなく、面倒くさいものには触りたくないっていう思想だと思う
非常に正しい思想だとは思う
0336デフォルトの名無しさん2010/10/23(土) 22:10:03
数メガのバイナリファイルが二万くらいあるんだけど、どのバージョン管理システムがお勧めですか？
0337デフォルトの名無しさん2010/10/23(土) 22:24:27
JASRACに管理してもらえ
0338デフォルトの名無しさん2010/10/23(土) 22:36:11
>>334
お前馬鹿すぎ
1200行だかはLinusが一晩ででっち上げたプロト
0339デフォルトの名無しさん2010/10/23(土) 22:59:33
>1200行とかCのソースとしてはものすごい短いものだから
>本気で取り組んだらわからない部分なんてないんじゃないの
>と、1200行のCのソースも理解できない馬鹿が言っています
>短い行数でこれだけの機能を実現しているということは
>作者にしかわからないトリッキーなコードに決まってるじゃん。

恥ずかしい部分抜き出したらほぼ全行だった。
ド素人とかいうレベルの話ではなく、頭の根っこの部分がものすごいお気の毒様な事になっているんだと思う。
0340デフォルトの名無しさん2010/10/24(日) 02:14:49
>>337
ネタじゃなく、真面目な話なんだが…
やっぱりPerforceしかないのか
0341デフォルトの名無しさん2010/10/24(日) 05:10:09
>>335
> 1200行で動いてるんなら、マルチバイト対応も、むしろ逆に簡単なんだろうけどな
マルチバイトって何ですか？
0342デフォルトの名無しさん2010/10/24(日) 05:46:56
>>336
git
0343デフォルトの名無しさん2010/10/24(日) 05:47:56
>>342
酷い奴だな……w

バイナリも差分で保存してくれるのは、svnとbzrだけ、だったっけ？
0344デフォルトの名無しさん2010/10/24(日) 05:58:21
数メガのバイナリを差分で取るの？
0345デフォルトの名無しさん2010/10/24(日) 05:59:20
gitもpackすれば差分になるよ
0346デフォルトの名無しさん2010/10/24(日) 06:06:09
それじゃpackしなければ良いんじゃない？
0347デフォルトの名無しさん2010/10/24(日) 07:05:08
packしなければ速いけどストレージは食うね
バイナリでも差分取れないような更新ばっかりならpackしないようにしたほうが良いかも
0348デフォルトの名無しさん2010/10/24(日) 08:47:20
Mercurialしかない。
0349デフォルトの名無しさん2010/10/24(日) 11:27:56
>>345
ほんとだｗ リポジトリ数GB縮んでびっくりしたわｗｗ
03503402010/10/24(日) 17:00:30
色々情報ありがとうございます！
bzrやgitもバイナリの差分に対応してるんですね。
その為だけにsvn使ってたみたいなもんなんで、ありがたい情報です。
0351デフォルトの名無しさん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
0352デフォルトの名無しさん2010/10/24(日) 21:42:45
>>118, >>340
定期的に Perforce を取り上げるのは営業活動の一環なのか？
0353デフォルトの名無しさん2010/10/24(日) 23:26:55
イントラ内に建てたfreebsd8.1サーバーにsubversionインストールして
ブラウザでhttp://サーバーアドレス/dav/ってするとdav - Revision 0: / って表示される。

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


0354デフォルトの名無しさん2010/10/24(日) 23:38:16
>>353
プロジェクトのディレクトリをエクスプローラーで開いてコンテキストメニューからコミットやアップデートできる。
Visual Studio Professionalならankhsvnとかのプラグイン使った方が楽。
0355デフォルトの名無しさん2010/10/24(日) 23:59:21
個別スレに行け
用語も分からないということは、trunk/branches/tagsも作らずに始めるつもりか？
0356デフォルトの名無しさん2010/10/25(月) 06:03:55
>>355
別にそれで始めたっていいだろが
03573532010/10/25(月) 07:29:02
用語もわからなくて質問してすいません。

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

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

どうしたら変更できますか？
0358デフォルトの名無しさん2010/10/25(月) 07:33:56
>>357
ここに行け
http://hibari.2ch.net/test/read.cgi/linux/1154701996/
0359デフォルトの名無しさん2010/10/25(月) 13:59:49
バージン管理システムに見えた
0360デフォルトの名無しさん2010/10/27(水) 20:10:38
Gitを統合した「KDevelop 4.1」がリリース
http://sourceforge.jp/magazine/10/10/27/0315212
0361デフォルトの名無しさん2010/10/27(水) 21:41:00
>>359
最近は過去の改竄しまくりで、けしからんな
0362デフォルトの名無しさん2010/10/28(木) 00:43:16
>>361
前彼女の履歴から俺のコミットがロールバックされていた件
0363デフォルトの名無しさん2010/10/28(木) 00:50:29
revertならまだ望みはある
0364デフォルトの名無しさん2010/10/28(木) 12:48:35
別の誰かの記憶にマージされていた
0365デフォルトの名無しさん2010/10/28(木) 14:19:02
お前ら二人とも愛してやる！
fast-forwardだ！
0366デフォルトの名無しさん2010/10/28(木) 15:19:20
VS2010で扱いやすいバー管おしえてください
0367デフォルトの名無しさん2010/10/28(木) 15:47:27
>>366
Mercurial Source Control Plugin for MS Visual Studio
http://visualhg.codeplex.com/
0368デフォルトの名無しさん2010/10/28(木) 15:57:16
>>366
VS2010で扱いやすいのはVSSじゃないかな
使ってる人間が扱いやすいかは別にして
0369デフォルトの名無しさん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よりもこっちの方が良いかも
0370デフォルトの名無しさん2010/10/28(木) 16:50:33
なんで何でもかんでも合体せにゃならんのか。
0371デフォルトの名無しさん2010/10/28(木) 18:36:29
>>367
俺はVisualHGよりは、hgsccの方が好きだな。
でも、両者をチェックしたのは1年以上前だから、今は状況が変わってるかもしれないが。
当時はVisualHGは低機能すぎてイマイチだった。
0372デフォルトの名無しさん2010/10/28(木) 23:56:34
お手軽で普通に使えるので俺はVisualHGのほうがオススメ。
0373デフォルトの名無しさん2010/10/29(金) 01:19:21
>>370
>>366じゃないがIDEやエディタに統合すると便利よ
リアルタイムに変更箇所表示してくれたり、TortoiseXXXみたいにアイコンファイルビューで状態を表示してくれたり
0374デフォルトの名無しさん2010/10/29(金) 01:31:03
>>370が言ってるのは、コマンドをパイプで繋げてお手軽にオレスゲーが出来なくなるのが問題だって事じゃないの
0375デフォルトの名無しさん2010/10/29(金) 03:19:39
>>368
MSはTFSに乗り換えて欲しいようだが
0376デフォルトの名無しさん2010/10/29(金) 08:49:39
>>374
Emacsはデスクトップ環境だそうだが、
GNU EmacsがBazaar、XEmacsがMercurialなんだね。
0377デフォルトの名無しさん2010/11/04(木) 20:10:45
Subversionスレから誘導されて来ました。

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

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

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

というような運用になるわけですが、このような運用を行う上で良い
構成法などの例は無いでしょうか。
0378デフォルトの名無しさん2010/11/04(木) 20:21:14
>>377
・Subversionのフォルダ単位の分散型のミラーを立てる
・Subversionにpush時に一本道になるように履歴を整える
0379デフォルトの名無しさん2010/11/04(木) 23:03:52
>>377
Mercurialではじめる分散構成管理
第5回　分散による「多段連携」 ～ 大規模開発への応用
http://gihyo.jp/dev/feature/01/mercurial/0005?page=1

ここでのマスタリポジトリをSubversionにすれば良い
0380デフォルトの名無しさん2010/11/06(土) 00:31:12
相談なんですが、
現在プログラマーはコードをSubversionで管理してます。
プログラマ以外の共同作業員との間ではバージョン管理ソフトを使っておらず、
最近、

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

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

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

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

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

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

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


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





0382デフォルトの名無しさん2010/11/06(土) 00:45:02
> 導入や利用時の手間がかかるデメリットが上回っている状況です。

・ならば入れる必要は無いでしょう。
・Trac/Redmineなどでのタスク管理を検討しましょう。
0383デフォルトの名無しさん2010/11/06(土) 00:48:38
Dropbox を入れるデメリットは無視ですかそうですか
0384デフォルトの名無しさん2010/11/06(土) 00:55:11
>>380-381
そのような状況なら、自分のブランチと共同作業員のブランチを用意して
共同作業員のブランチも貴方(もしくはプログラマ)が管理すればいい
0385デフォルトの名無しさん2010/11/06(土) 00:59:18
>>380-381
Trac、Redmineを立てなくても、
５人まで無料で無制限でプライベートリポジトリが持てて、wikiとBTSが付いているbitbucketが良いんじゃね
0386デフォルトの名無しさん2010/11/06(土) 01:39:06
コンフリクトする度にぶち切れて暴れてみせれば、デザイナの方から
バージョン管理システム導入しようって言ってくると思うよ。
0387デフォルトの名無しさん2010/11/06(土) 01:43:31
>>386
それいいなｗ　って思ったけど、デザイナの人ってそういうの気にしなーいんだよね…
0388デフォルトの名無しさん2010/11/06(土) 04:04:37
そんなの人の問題
ブチ切れ方が足りない
「俺のファイルを上書きするんじゃねぇ」とキーボードぶん投げてやれば
バージョン管理の導入に同意してくれるだろ
0389デフォルトの名無しさん2010/11/06(土) 05:44:58
>>386-387
ぶちきれても無駄
そんなことするより
こっちからコンフリクト上書きして
デザイン壊してやればいい

0390デフォルトの名無しさん2010/11/06(土) 05:59:24
>>380
デザイナーを変えればいいんじゃね？
0391デフォルトの名無しさん2010/11/06(土) 06:56:49
社内リポジトリを公開せずに、社外のコントリビューター（ヘルプ、ドキュメント、アイコン、その他、主に非プログラム関連）の
ファイルをバージョン管理するのなら、一番簡単なのは社内の人間を一人貼り付ける。代行チェックイン/アウト。

対象範囲が他とは独立していてファイルが一つくらい古くても大勢には影響でないのであれば、きらくにやってみたら？
0392デフォルトの名無しさん2010/11/06(土) 12:30:41
バージョン管理面倒くさいとか言ったら、次の仕事は頼まないからってなことを匂わす
0393デフォルトの名無しさん2010/11/06(土) 14:05:14
あー同僚のデザイナーにもおるわ、意地でもsvn使わん奴。もう死ねよ
0394デフォルトの名無しさん2010/11/06(土) 14:13:03
そんな屑クビにしろよw
0395デフォルトの名無しさん2010/11/06(土) 14:41:42
バージョン管理のノウハウ的な所についての入門とか手引きは見当たらないけど、
皆どうやって覚えてるんだ？
誰もが習うより慣れろで問題ないというわけでなし。
0396デフォルトの名無しさん2010/11/06(土) 14:47:47
いろいろ書籍出てるけど？
0397デフォルトの名無しさん2010/11/06(土) 14:56:08
書籍「Dropboxで楽々バージョン管理」
・コミットなどの専門用語とは、おさらば
・ブランチ、マージは必要無し
0398デフォルトの名無しさん2010/11/06(土) 18:23:36
近所にいくら勧めてもバージョン管理使わないチームがいてな
いつも、上書きしたとか機能を変更したとか勝手に変えるなとかチーム内でけんかばっかりしている連中がいる。
0399デフォルトの名無しさん2010/11/06(土) 18:53:41
>>397
ブランチはともかく、マージ必要無しって・・・
上書き上等ってことか？

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

見えなそうなちっちゃいところ（コピーライト表記とか、すこーしだけ色味を変えるとか）で、
すごく微妙だけど許されなさそうな上書きしちゃってみればいいんではないか？
0400デフォルトの名無しさん2010/11/06(土) 19:49:48
ぶっちゃけオンラインストレージよりはグローバルアドレスがひとつ欲しいんだよなあ
0401デフォルトの名無しさん2010/11/06(土) 20:27:10
うちのプロバイダだと固定IPとるのに月5000円かかるからなぁ…
0402デフォルトの名無しさん2010/11/06(土) 20:39:31
月500円ぐらいのVPS契約すれば、グローバルのIP1個貰えるじゃん。
0403デフォルトの名無しさん2010/11/06(土) 21:39:25
固定IPなんか必要ないだろ
0404デフォルトの名無しさん2010/11/06(土) 21:43:59
電気代とか、サーバーの構築費用考えたら、
クラウドでも借りた方が安いんじゃね？
0405デフォルトの名無しさん2010/11/06(土) 22:01:46
このスレ的には、bitbucketかgithubで決まりだろ？
04063802010/11/06(土) 22:42:00
レスサンクス。参考になりました。俺デザイナ？っていいましたっけ・・・なんでバレてるんでしょ

BTSはすでに使っています。Redmineです。
まだ詳しく見ていないのですが、デザイナさんはチケットの切り方がちょっと大きいかなと感じました。
もうちょっと細かく切ってもらうようにしてみます。
# 意外なことにRedmineはすぐに使ってもらえたんですよね。タスクの共有はかなり困ってたので。

相手が目の前にいるので、こえかけたほうが早いというような状況もあります。
ただそれでも上書きが起こってて、件のプログラマがシステムで解決したがったみたいです。

>>383
Dropboxはメリットがデメリットを上回っている状態で、許可されてます。Gmail使っているような職場ですので・・・。

>>386
この件を提案したプログラマが切れ気味だったのかもしれないです。
プログラマは運用でなんとかするタイプだったので、むしろ相談されてちょっと驚きました。
(早いと判断すると運用でなんとかしてしまう。実際早い)
ただ工数、というか相手の作業員の面倒さや導入時間が増えるのは極力避ける方法でやっているのと、
けっこうデザイナ含め、作業以外の(ちょっと面倒くさい)効率化の話を嫌うので、気を使います。

今は話題は収まっているのですが、盛り返さない程度にもうちょっと話聞いてみます。

>>390
人員変えられたら苦労しないし、むしろ俺が変わって欲しいｗ
04073802010/11/06(土) 22:47:05
>>397
ワロタｗｗ
実際そんな感じでいい、という流れになってるｗ
プログラマがリソース受け取って手動マージｗ

Dropboxもテキストぐらいマージするモードがほしいくらいです

>>399
> 多少の上書きには動じないってのはあるな

いや、実際そうですよ。
プログラマならテキストにしておけば、
バージョン管理に入れて差分とってマージすればいいくらいが当たり前に染み付いている人も多いと思います。

ですが、扱うデータがグラフィックデータやバイナリほとんどだと
最初から差分やマージの恩恵がうけにくいので、諦めている感じがします。
システムで解決しようとする人たちが少ないのわからないですが、
この辺もう少しプログラマ界隈のようにツールが整っていてもいいのにとは思います。
04083802010/11/06(土) 23:05:12
ちょっと閃いたのですが、サーバー側にもDropboxクライアントを入れておいて、
作業員がDropboxの共有にファイルを入れたら、サーバー側で取得、
リポジトリの(デザイナは知らない)デザイナ用ブランチに自動コミットというのはありかも。


実際、そこまで手間かけてやる必要あるのか？という問題はありますが、
(こちらに支障でない程度に)なんとかカバーしてあげたいですよね。
0409デフォルトの名無しさん2010/11/07(日) 04:27:31
今のご時勢バージョン管理使えるデザイナっつーのはどこに行っても重宝されるよ。現にここでもニーズがあったろう？って言えば
ぜひ使い方を教えてくれってなるんじゃねーの
0410デフォルトの名無しさん2010/11/07(日) 04:42:27
>>380の人に助言できるとしたら、VCSは、何も差分だけを管理してる訳じゃないよと
履歴すなわち、誰がいつ何をしたか、ってのも残ってるんだよってことかな
DropBoxでも、それはわかるんだろうか

最終的に一つの成果物を作るわけだから、作業中の差分どうこうは結果さえよければ
どうでもいいんだが、いざ問題が出たときに「自分が」それをやって(いない|いた)ことが
保証されるっていうのは、実はものすごく大きい（主に精神安定上）

あと、コミットログがあるので、「なぜ」その変更をしたのか、が一応残っている。
これもDropBoxで再現できているっていうならまあもう言うことはないけれど。
0411デフォルトの名無しさん2010/11/07(日) 09:23:42
Redmineを入れているそうだから、「誰がいつ何をしたか」の記録は残るでしょ。
VCSの機能として欠かせないのにblameがあるけど、バイナリじゃ意味ないし。
Redmineのwikiはblameもできるし。
となると、VCSを使うメリットが見出せないというのも分からないでもない。
0412デフォルトの名無しさん2010/11/07(日) 11:34:14
Redmine の Wiki は微妙に使い辛いんだよなぁ。
Google Docs あたりと上手く連携出来たらいいのにってよく思う。
0413デフォルトの名無しさん2010/11/07(日) 12:10:50
昔の職場、CVS使えってどんだけ言っても面倒くさがって使わない奴らばっかだったんだけど
その理由として「価値を見出せない」というのもあるけど「何もかもオープンになる」のが嫌
ってのもあったような気がするな。
特にデザイナの人ってプログラマと違ってキチキチやらないから単純な間違いも凄く多くて、
それが全部見え見え（メール飛ぶ設定になってたり）になるのが嫌なのかも。

どっかで読んだブログで、新しく来た中国人ブログラマとのコミュニケーションに
ちょっと不安があったんだけど、コミットログを見てると最近の調子が手に取るように分かる、
ってのがあって、なるほどなぁ、と思った。
0414デフォルトの名無しさん2010/11/07(日) 12:20:14
業務でやってるんだから、作業内容にプライバシーなんか無いだろ。
個人の作業用ブランチに毎日コミットさせると良いぞ。
0415デフォルトの名無しさん2010/11/07(日) 13:03:39
いちいち他人のログを見るってどんな暇人だよとおもう。
自分のログだって、デグレートの問題が起きなきゃ見ないよ。
0416デフォルトの名無しさん2010/11/07(日) 13:07:03
え？ログ見ないの？
一行目に目的を書くの常識でしょ？
0417デフォルトの名無しさん2010/11/07(日) 13:18:06
締め切り間際になって出来ていませんでしたと言われたくなかったら、進捗具合とかチェックするだろ。
0418デフォルトの名無しさん2010/11/07(日) 14:12:18
普段は最低でも1日1回、多い時は4～5回コミットしているのに、
あるとき一週間コミットせずにいたら、部長に喫茶店に連れ出されて
面談になったｗ
お客さんの依頼で他の作業をしていただけで、リーダーの指示なんだから
上にも伝わっているものだと思っていたのに。
俺から部長に事情を説明したんだが、その後リーダーの機嫌は悪かった。
まあ知ったことじゃないけどね。
0419デフォルトの名無しさん2010/11/07(日) 14:14:54
うちのところはフックして自動的にコミット内容メールで流してるから、
全員の進捗具合や、何をどう修正・実装したかまでだいたいわかる
つーか、普通こうやっとくもんでしょ
0420デフォルトの名無しさん2010/11/07(日) 14:15:59
コミット内容がメールで流れると、コミットの粒度が無駄に大きくなりそうだ。
0421デフォルトの名無しさん2010/11/07(日) 14:18:47
そういう隠蔽体質を作らないのが管理の本当の仕事だと最近思う
0422デフォルトの名無しさん2010/11/07(日) 14:59:44
上司が隠蔽してのし上がった組織は隠したがるから理解されない
0423デフォルトの名無しさん2010/11/07(日) 15:02:32
徹夜すればなんとかなる気質の人とかはコミットトレースされたがらないんだろうなって気はするなぁ。
0424デフォルトの名無しさん2010/11/07(日) 15:05:25
そんなあなたにgit、Mercurialの--dateオプション
0425デフォルトの名無しさん2010/11/07(日) 15:15:26
>>423
別にトレースされたからってその人の作業結果の価値が下がるわけじゃないと思うんだけどな
評価するやつ次第なところっていう
0426デフォルトの名無しさん2010/11/07(日) 15:18:00
水面下のバタバタを隠せるって点で git は痛し痒し
0427デフォルトの名無しさん2010/11/07(日) 19:12:29
>>420
チーム内の仲のいい奴や意識の高い奴と示し合わせて、
「頻繁にコミットするのが当たり前、コミットを渋る奴はバカ」みたいな空気を
作っちゃうんだよ。
意識の低い奴は周りの雰囲気に合わせて何となく動くから、雰囲気に合わせるだけで
正しい行動が取れるような環境を作ってあげるのがリーダーの仕事だよね。

まあ、俺にはとても無理だけどね。
0428デフォルトの名無しさん2010/11/07(日) 19:53:37
BTS も SCM も俺ひとりしか真面目につかってない
辞めたい
0429デフォルトの名無しさん2010/11/07(日) 21:09:11
>428
俺も昔はその状態だった。半年後ぐらいに改善されたが。
0430デフォルトの名無しさん2010/11/07(日) 21:50:03
ttp://sourceforge.jp/magazine/10/11/01/0937206
俺も、参戦するぜ！
0431デフォルトの名無しさん2010/11/07(日) 21:52:13
>430
＞リポジトリデータはSQLiteで管理する。

キモの部分が他人任せかよ。
0432デフォルトの名無しさん2010/11/07(日) 22:09:21
キモかどうかは判断が分かれるな
バックエンドの処理については実装部分の話で速度に影響する
もしmonotoneが速かったらGITもMercurialも産まれてなかったかもしれない
0433デフォルトの名無しさん2010/11/07(日) 22:14:39
http://po3a.blogspot.com/2007/12/subversion.html
> もし C++ で書かれた VCS が欲しいのなら、Monotone を見てみるといい。
> ほんとに。連中は「本物のデータベース」を使っているよ。
> 「素敵なオブジェクト指向ライブラリ」も使ってる。「ナイスな C++ の抽象化」も
> 使ってる。そして率直なことろ、一部の情報系の人間が喜びそうな
> これらすべての設計上の決定のために、できてきた結果はゲロゲロで
> 保守不可能なカオスだ。
0434デフォルトの名無しさん2010/11/07(日) 22:29:00
ｹﾁｮﾝｹﾁｮﾝだなｗ
Cが至高なのは同意だが
0435デフォルトの名無しさん2010/11/07(日) 22:42:13
Linus は最初 BitKeeper に変る SCM でMonotone を最有力に挙げていたが、
動作速度が遅いから Linus版 Monotone としてGitを作ったんだよな。
0436デフォルトの名無しさん2010/11/07(日) 22:42:59
そこは別にいいんじゃね？
0437デフォルトの名無しさん2010/11/07(日) 22:44:07
しょっちゅう使うツールは速いが正義なんだよなぁ。
0438デフォルトの名無しさん2010/11/07(日) 22:48:02
で、Monotoneは、user-visibleなとこでは、どの辺に新規性があるわけ？
公開鍵がどうこうのあたり？
0439デフォルトの名無しさん2010/11/07(日) 23:00:55
Monotone はファイル名をUTF-8に変換して管理してる。
これは Git に持ち込まなかった概念で、速度を犠牲にしたバカげた設計だと
Linus は思ったのだろう。
0440デフォルトの名無しさん2010/11/07(日) 23:01:40
>>428
同じく。一回提案したら便利そうだから使ってみようって流れになったんだけど、いざ導入したらよくわからんとか難しいとか言って使ってくれなくなった…。ちなみに相手はみんなプログラマ。
0441デフォルトの名無しさん2010/11/07(日) 23:18:04
Mercuの利点ってなに？
0442デフォルトの名無しさん2010/11/07(日) 23:34:18
>>439
Linux上のファイル名をLANGで変換するのであるならば、それはバカげた設計
0443デフォルトの名無しさん2010/11/08(月) 02:52:27
義務教育でバージョン管理のし方は教えておけよ、と思う
0444デフォルトの名無しさん2010/11/08(月) 03:03:40
日記＝コミットログ
0445デフォルトの名無しさん2010/11/08(月) 03:24:26
20年前のcommitにrevertするにはどうすれば
0446デフォルトの名無しさん2010/11/08(月) 03:48:35
種付け＝フォーク
0447デフォルトの名無しさん2010/11/08(月) 04:21:22
結婚＝マージ
0448デフォルトの名無しさん2010/11/08(月) 04:27:37
浮気＝ブランチ
0449デフォルトの名無しさん2010/11/08(月) 09:38:56
子供っていう派生プロジェクトを亡き者には出来ないだろ。。。
0450デフォルトの名無しさん2010/11/08(月) 15:31:29
子供は分散システム
0451デフォルトの名無しさん2010/11/08(月) 16:46:26
性格の不一致＝コンフリクト
0452デフォルトの名無しさん2010/11/08(月) 17:20:20
commit = sex
0453デフォルトの名無しさん2010/11/08(月) 18:02:38
再婚＝リベース
0454デフォルトの名無しさん2010/11/08(月) 21:47:04
一つのリポジトリで複数(というか全て)のプロジェクトを管理できないかと考えています(無料のプライベートリポジトリサービスの多くは作れるリポジトリ数に制限があるようなので)。
個人でバージョン管理システムを使う場合、このような運用をする上で何か問題はありますか？
また、問題は無くともプロジェクト毎にリポジトリを分けた方がいい積極的な理由はありますか？
0455デフォルトの名無しさん2010/11/08(月) 21:54:17
プロジェクトで共有しているライブラリとかたくさん作ってるなら一つにしたほうがいいんじゃないの
完全に別物ならバージョンアップのとき別々の方がいいだろうし
0456デフォルトの名無しさん2010/11/08(月) 21:54:22
関連スレ

プログラマー的"女の口説き方"
http://hibari.2ch.net/test/read.cgi/tech/1142089873/
彼女にポートスキャンの形跡が！！！
http://hibari.2ch.net/test/read.cgi/unix/1014614044/
彼女がUNIX始めました。
http://hibari.2ch.net/test/read.cgi/unix/1018731587/
彼女にloginできません
http://hibari.2ch.net/test/read.cgi/unix/1007136614/
彼女がオープンソース化されそうです
http://hibari.2ch.net/test/read.cgi/unix/1000484092/
彼女をCVSで管理したい
http://hibari.2ch.net/test/read.cgi/unix/999837578/
彼女をmountできません
http://hibari.2ch.net/test/read.cgi/unix/1059971117/
彼女をGNU Screenで
http://pc8.2ch.net/test/read.cgi/unix/1073793361/
女子高生のカーネル領域における言語的等価性
http://hibari.2ch.net/test/read.cgi/unix/1010917395/
女性を UNIX に招くための HOWTO
http://hibari.2ch.net/test/read.cgi/unix/1042963649/
0457デフォルトの名無しさん2010/11/08(月) 22:31:57
>>455
ありがとうございます。
やっぱりそんなに問題ないのかな。
共有ライブラリ的なものも色々作るつもりなので、単一リポジトリの方向で検討してみます。
0458デフォルトの名無しさん2010/11/08(月) 22:41:00
いや、分けるべきだ

Pro Git - Pro Git 6.6 Git のさまざまなツール サブモジュール
http://progit.org/book/ja/ch6-6.html
> 「ふたつのプロジェクトはそれぞれ別のものとして管理したい。だけど、一方を他方の一部としても使いたい」
0459デフォルトの名無しさん2010/11/08(月) 22:47:18
>>458
Gitのサブモジュールは正直あまり使い勝手が良いとは言えないな…

Subversionでやるならディレクトリ単位で好きにチェックアウト出来るから
手軽さではこっちのほうが良いと思う。中央集権型になっちゃうけどね。
0460デフォルトの名無しさん2010/11/08(月) 22:50:07
>>456
> 彼女をGNU Screenで

これ分からんw　で、どうするんだ？
0461デフォルトの名無しさん2010/11/08(月) 22:52:52
Gitのsubmoduleが使い安いとはいえんがSubversionの方が良いとは思えないな。
0462デフォルトの名無しさん2010/11/08(月) 22:56:23
プライベートリポジトリ作り放題のbitbucketでのMercurialのsubrepo
0463デフォルトの名無しさん2010/11/09(火) 02:28:28
質問があります。
TortoiseSVNやTortoiseGitやTortoiseBzrでエクスプローラーへの組み込みをなすことはできないでしょうか？
アンインストールするしかないでしょうか？

Tortoise系のツールをシェル拡張で組み込んでおくと、
Windowsでいうシェルを利用したその他ソフトの動作が遅くなるような気がしていて検証したいためです。
0464デフォルトの名無しさん2010/11/09(火) 03:09:31
検証するまでもなく遅くなるよ
右クリックするたびにフォルダー内検索するわけだから
0465methane2010/11/09(火) 03:24:19
TortoiseBZRでは、シェル拡張そのものを一時的に無くすことはできないものの、
バックグラウンドプロセスがディレクトリ内をチェックすること無しに応答するスリープ
機能を実装しています。
タスクトレイアイコンを右クリックでスリープをチェックするとスリープします。
0466デフォルトの名無しさん2010/11/09(火) 04:04:45
Gitのsubmoduleって初めて知った

submoduleはそこのディレクトリ以下が親repo内で「何処そこのrepoのハッシュ某」とされるだけで
親repo内では内部に一切関知しない仕組みってことかな
0467デフォルトの名無しさん2010/11/09(火) 05:07:50
TortoiseXXXはキャッシュあるだろ
0468デフォルトの名無しさん2010/11/09(火) 07:39:41
TortoiseHgはGNOMEのシェル拡張もあります。
TortoiseHgはWindows・GNOMEともキャッシュはありません。
リポジトリ単位でアイコンを表示するしないの選択ができます。
Windowsでは、シェル拡張を入れる入れないの選択も出来た気がします。
シェル拡張を経由せず、コマンドラインから起動できます。
次期バージョンではデスクトップアイコンかスタートメニューで起動できるようになるかもしれません。
0469デフォルトの名無しさん2010/11/09(火) 09:48:13
>>463
特定のディレクトリ以下だけに反応させる設定があったような。
0470デフォルトの名無しさん2010/11/09(火) 09:53:02
結局Tortoiseで使い物になるのってSVNだけ？
0471デフォルトの名無しさん2010/11/09(火) 10:02:44
TortoiseHgはGNOMEのシェル拡張はMercurialのPythonのライブラリを直接呼んでいます。
つまり、hg statusと同様のことをしています。
ですので、キャッシュも必要無く、高速です。

TortoiseHgのWindowsのシェル拡張も以前は同様の処理を行っていました。
しかし、Pythonでやるのは無理があったのか、C++に置き換えられました。
hg statusを叩くと、.hg/dirstateが更新されます。
これのタイムスタンプを確認しています。
これで高速化しています。
0472デフォルトの名無しさん2010/11/09(火) 10:17:10
TortoiseHgをWindowsに入れるとタスクバーのシステムトレイにMercurialのアイコンがあるのが分かると思います。
これはPythonで書かれています。
ファイルを更新すると、システムトレイのアイコンが光ると思います。
この時に.hg/dirstateが更新されます。
0473デフォルトの名無しさん2010/11/09(火) 12:02:30
TortoiseHgって、インスコ済のマシンからバイナリをコピーしてきて、
コマンドラインから個々のツールを起動できるの？
何か、出来そうな雰囲気にも見えるけど。
0474デフォルトの名無しさん2010/11/09(火) 12:20:41
PATHを通せばいけそうな気もしないでもない
0475デフォルトの名無しさん2010/11/09(火) 12:27:19
>>473
> TortoiseHgって、インスコ済のマシンからバイナリをコピーしてきて、
これはやったことが無いので分かりません。

> コマンドラインから個々のツールを起動できるの？
TortoiseHgのインストールしたところにhgtk.exe（現安定バージョン）があると思います。
Linuxのパッケージ配布ですと、/usr/bin/hgtk になっていると思います。

hgtk help と叩いて見てください。
usageが出てきます。
これらのサブコマンドをシェル拡張が起動しています。
0476デフォルトの名無しさん2010/11/09(火) 23:46:25
そうだねぇ、TortoiseでマトモなのはSVNだけな気がする。
他はまだ「急いで作った」感が激しい。

TortoiseSVNがもっと特定のバージョン管理システムに依存してない作りならよかったのにね。
それこそ、TortoiseALLみたいな、設定次第で複数のバージョン管理システムようにできればよかった。
0477デフォルトの名無しさん2010/11/10(水) 07:27:44
>>476
> それこそ、TortoiseALLみたいな、設定次第で複数のバージョン管理システムようにできればよかった。
TortoiseHgは、hgsubversionを使うことでSubversionを、hg-gitを使うことでGitを直接操作することが可能です。
04784632010/11/10(水) 09:07:03
右クリックのメニューが5～10秒)くらいかかっていたのがTortoise系全部外したら2秒くらいになった。
すごく快適。

最新版では違うかも知れないけど、TortoiseGit、TortoiseBzr、TortoiseSVNともどれもアンインストーラーでシェル拡張だけ外すことができなかったので、
TortoiseHgは重いから前にすでに外してた。
TortoiseHgが重いのじゃなくてGUIだと以前のバージョンでは重いリポジトリで固まってただけなので誤解しないで

シェル拡張外していざというときに使えたらいいと思う。
コマンドラインで使えるけど、履歴やブランチをグラフィカルに見たいことあるからね。
gitはコマンドライン版でもgitkみたいなのあるからいらないかもしれない。

アイコン表示はとても便利なんだけど重いのは仕方がない・・・
IDEに拡張入れてつかうとか回避策はあるし
04794632010/11/10(水) 09:09:28
TortoiseGitアンインスコしてもまだメニューに残っているんだけどこれはmsysgitのかな

>>475 訂正

> 最新版では違うかも知れないけど、TortoiseGit、TortoiseBzr、TortoiseSVNともどれもアンインストーラーでシェル拡張だけ外すことができなかったので、

最新版では違うかも知れないけど、TortoiseGit、TortoiseBzr、TortoiseSVNともどれもアンインストーラーでシェル拡張だけ外すことができなかったので、
シェル拡張外していざというときに使えたらいいと思う。

>>471-473
TortoiseHgは単体で使えますか。

そもそも外部ツールを呼び出しているだけだろうし、切り離して使えるとすごく助かります。
0480methane2010/11/10(水) 09:22:16
TortoiseBZRはスリープ機能持ってるけど、そもそもシェル拡張外したいっていう話ですね。
アンインストーラーの拡張は面倒だけど、スタートメニューにメニューを追加するのはできそう。
中では regsvr32 呼んでるだけだし。
ただ、per user install と全員のインストールの切り替えとか考え出すと面倒だ。

ちなみに、bzrはインストーラーでTortoiseBZRを外して Bazaar Explorer だけインストールすると、
統合型GUIだけで使えます。
0481デフォルトの名無しさん2010/11/10(水) 09:24:24
トータス（陸亀）なのかタートス（海亀）なのか、そこが問題だ。
0482methane2010/11/10(水) 09:26:31
>>481
オフラインが陸、オンラインが海
シェル拡張はオフラインなのでTortoise
Web上ののリポジトリブラウザはオンラインなので海亀のLoggerhead
0483デフォルトの名無しさん2010/11/10(水) 09:29:34
>>482
アカウミガメって種族の海亀なのか。ちょっと感動。
0484デフォルトの名無しさん2010/11/10(水) 09:35:44
tortoiseBZR使ってるけど、
管理対象フォルダを見に行くと
マシン起動後初回は必ず時間かかって、間違ったアイコンが表示される。

なんか、あわてふためいたあげく間違えるとかかわいくて萌える///
0485デフォルトの名無しさん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と書かれたバッチファイルをデスクトップなどに用意すると、ワークベンチ画面が立ち上がります。
0486デフォルトの名無しさん2010/11/10(水) 10:21:43
>>478
> TortoiseHgが重いのじゃなくてGUIだと以前のバージョンでは重いリポジトリで固まってただけなので誤解しないで

ログ画面でかなりの数のリビジョンを読み込むので、重いかと思います。
初期設定では500のようです。

mercurial.iniか.hg/hgrcに以下のものを書くと速くなると思います。

[tortoisehg]
graphlimit = 50

またTortoiseHgの画面の「リポジトリ設定」→「ログの表示」→「ログ読み込み件数」で設定できます。
0487methane2010/11/10(水) 10:36:03
>>484
間違ったというか、ステータス取得中は ? を表示して、ステータス取得後に正しいアイコンに
アップデートする仕様になっています。アイコンオーバーレイの仕様上、すぐにステータス返さないと
エクスプローラー自体を待たせてしまうので。
0488デフォルトの名無しさん2010/11/10(水) 12:29:33
WinCvs みたいな独立したツールが好きだったんだがなあ。
なんで Tortoise が普及してしまったのか。
0489デフォルトの名無しさん2010/11/10(水) 12:34:58
WinCvs みたいな独立したツールが好きじゃないから。
0490デフォルトの名無しさん2010/11/10(水) 12:46:08
bzr explorer とか git extentions とかは単体ツールとして良くできてると思うけどなぁ
04914632010/11/11(木) 06:39:47
シェル拡張外しまくったらエクスプローラーさくさくうごいてワロタｗ
コンテキストメニューの表示が早くなっただけでも大分違いますね

ただ重いところは重いままだったので、問題が切り分けできて助かりました。

>>479
> TortoiseGitアンインスコしてもまだメニューに残っているんだけどこれはmsysgitのかな

msysgitでエクスプローラーのメニュー拡張されていたので一旦アンインストールしました。
0492デフォルトの名無しさん2010/11/11(木) 08:29:01
>>488
やっぱりシェル統合は便利だよ。
エディタやランチャからコンテキストメニュー表示するだけでバージョン管理できるから。
各ツールから個々のsvnのコマンドを呼び出せるようにしようとすると結構手間かかるし。

バージョン管理は主ではなくあくまで従なんだと思う。
0493デフォルトの名無しさん2010/11/11(木) 08:38:02
シェル拡張といってもいろいろあるけどな。ちょっと右クリックメニューを拡張するだけならまだしも、
SVNクライアントの機能をまるごとエクスプローラのプロセス内にロードすりゃ重くもなるか。
0494デフォルトの名無しさん2010/11/11(木) 15:59:02
どんなのが便利と感じるかも人それぞれか
バージョン管理しないときまでバージョン管理に関するものが見えるのは俺は不便だと思うが
0495デフォルトの名無しさん2010/11/11(木) 16:08:54
バージョン管理なんか、シェルに組み込むほど、たいそうなもんじゃないよな。
シェルはOSの基盤だよ。
0496デフォルトの名無しさん2010/11/11(木) 16:15:46
自作のしょうもないシェル拡張入れちゃってるな
0497デフォルトの名無しさん2010/11/11(木) 16:26:37
ファイルシステムにバージョンの概念があったVMSに喧嘩売ってる？
0498デフォルトの名無しさん2010/11/11(木) 17:20:40
あれってシェルがやってくれてるのかと思ってた
0499デフォルトの名無しさん2010/11/11(木) 18:51:58
えくすぷろらライクのファイラーにコンテキストメニュー付くだけでいいんだがな
0500デフォルトの名無しさん2010/11/11(木) 19:06:45
>>499
プログラマはそれでも良いが、デザイナなどの一般のユーザ対象だと、その画面の開き方の説明から始めないといけない。
エクスプローラという共通インターフェースを使っているTortoiseSVNの功績は大きい。
0501デフォルトの名無しさん2010/11/11(木) 20:50:18
>>495
＞シェルはOSの基盤だよ。
ぷ。ｗ
「シェル」をそう呼ぶ所以をご存知？
0502デフォルトの名無しさん2010/11/11(木) 22:18:29
shell と core という言葉の意味においても語源においても
破格の位置付けだと思うけど
0503デフォルトの名無しさん2010/11/12(金) 09:12:42
>>501
出たよ、揚げ足取り薀蓄たれのドアホウが。
「OS の基盤はカーネルだろｗｗｗｗｗ」
とか言いたいのか？
お前、人とまともにコミュニケーション取れないだろ。
いや、お前は取れてると思ってても相手は実に不快な思いをしているはずだ。
お前が友達と思ってるやつの大半はお前のことを友達とは思ってないな。
0504デフォルトの名無しさん2010/11/12(金) 09:17:55
そう言うのをさらっと流せないのがお前の駄目なところだな
0505デフォルトの名無しさん2010/11/12(金) 09:20:22
>>503
間違いを認めずに全力で言い訳を続けるような、お前こそまわりとコミュ
ニケーションとれてないだろ。
お前うざいと思われている事確実。空気読めない発達障害なんだろうな。ｗ
0506デフォルトの名無しさん2010/11/12(金) 09:32:12
Windows NT 3.51 まではウィンドウシステムはコアとは分離していたけど、
NT 4.0 からはコアに含まれたんじゃなかったっけ？
0507デフォルトの名無しさん2010/11/12(金) 09:58:18
それはGDIの事だ。
0508デフォルトの名無しさん2010/11/12(金) 10:18:54
userもカーネルモードだぞ
0509デフォルトの名無しさん2010/11/12(金) 10:54:48
kernel32もuser32もgdi32も一部ユーザー一部特権
0510デフォルトの名無しさん2010/11/12(金) 11:12:44
>>503
ttp://togetter.com/li/66450
0511デフォルトの名無しさん2010/11/13(土) 16:19:10
インスコ済のTortoiseHgをコピーしてきて使う件だけど、試してみたら、
パスを通しておけば、 hgtk log とか hgtk status とかでGUI呼び出して使えるね。

Explorerは汚染されないし、これで十分な気がする。
0512デフォルトの名無しさん2010/11/13(土) 17:52:45
そういう裏技的に使えるようにしても嬉しくない・・・

よく「このツールは便利！」とか聞くけど、「残念なのは・・・」とかで回避法が一緒にくっついてる
そういうのって便利でない上に冷める・・・結局使わない
0513デフォルトの名無しさん2010/11/13(土) 23:45:58
裏技ってか、元々独立して作られたものじゃないの？
hgtkって
0514デフォルトの名無しさん2010/11/14(日) 08:37:27
>>512
むしろそうじゃない便利なツールというものが世の中にあれば教えて欲しいが


それはそれとして、今の話の流れはエクスプローラーが重くなるのでシェル拡張から外した状態で
エクスプローラーに組み込むためのTortoiseツールを使いたいという話なのね。

つまり今の>>463の言うところの「残念なのは・・・」というのはそもそもがエクスプローラーが多少なりとも重くなる、
しかもTortoiseSVN一個ならよいが、TortoiseBzr、TortoiseGitも入れるとさらに重いという点だ。
TortoiseHgは>>463はいれていなかったか。

>>512が「裏技的に使えるようにしても嬉しくない」と思うならエクスプローラーに組み込んで使えばいいだけだし、
>>463には単体で起動出来れば嬉しいわけだし、意味がわからん。


0515デフォルトの名無しさん2010/11/14(日) 08:42:21
まあまあ

>>512
こういう馬鹿がいるから、TotoiseSVNは普及してシェアを獲得したわけだし、
BazaarExplorerのように単体で使えるツールを持っているバージョン管理ソフトならば、
スタートメニューなりにショートカットなり作れば解決する話じゃねーの

できれば、後からインストーラーでシェル拡張のON/OFFを切り替えられればなおよし
0516デフォルトの名無しさん2010/11/14(日) 08:49:11
オープンソースだし分散型なんだから自分用にフォークして改造するか本家にパッチを送れば良いだけ
0517デフォルトの名無しさん2010/11/14(日) 10:49:11
http://www.ohloh.net/tags/tortoise
0518デフォルトの名無しさん2010/11/15(月) 03:10:03
>>516

>>515にできるわけないじゃんｗ
0519デフォルトの名無しさん2010/11/15(月) 07:04:51
TotoiseSVN程度で重いとかほざいてる馬鹿はとっととSSDにしとけ
よほどの無能でもない限りは投資分回収できるだろ
問題解決能力の低さから見て、そのよほどの無能なのかも知れんけどさ
0520デフォルトの名無しさん2010/11/15(月) 07:05:43
今気付いたがスペルミスってんじゃねぇか使えねぇｗ
0521デフォルトの名無しさん2010/11/15(月) 07:10:17
>>519
>>519が見るにディスクアクセスが原因ってことか？
わかった試してみるわ

ソースがあるローカルのストレージは容量の都合で変えられんが
OSのHDDは変えられると思うので
0522デフォルトの名無しさん2010/11/15(月) 13:11:13
>>521
ソースのドライブを変えなければ
ほとんど意味がないと思うが。

TSVNCacheプロセスの優先度を
上げれば。
あんまり勧めないけどな。ｗ
0523デフォルトの名無しさん2010/11/17(水) 14:54:24
以前、TortoiseSVNが見る対象パスを設定できるとか書いたけど間違ってた。すまそ。
実際は、対象から外すパスの設定だった。
Settings→General→ContextMenu→Do not show..のテキストエリアな。
とりあえずエロ画像ドライブとかは設定しといた方がいいよ
0524デフォルトの名無しさん2010/11/17(水) 15:33:24
これは良い情報
㌧㌧
0525デフォルトの名無しさん2010/11/17(水) 15:43:45
アイコンオーバレイの方の対象/除外パスの方が効果があると思うが
0526デフォルトの名無しさん2010/11/17(水) 15:57:09
このスレ、何でTeam Foundation Serverの話題が皆無なの？
0527デフォルトの名無しさん2010/11/17(水) 16:36:14
>>526
みんなVSSで満足しているから
0528デフォルトの名無しさん2010/11/17(水) 19:01:58
貧乏だから。
0529デフォルトの名無しさん2010/11/17(水) 19:16:54
>>526
ClearCaseに到底及ばないから
0530デフォルトの名無しさん2010/11/17(水) 19:52:39
MSDNに入ってれば、Team Foundation Serverタダで使えるようになったのに。
この話題にならなさは異常。
0531デフォルトの名無しさん2010/11/17(水) 20:12:57
MSDNがタダでないから
0532デフォルトの名無しさん2010/11/17(水) 21:38:37
Express版でも出してくれればいいんだけどな。
全く話題に上ったことがない。
0533デフォルトの名無しさん2010/11/17(水) 22:46:07
誰が欲しがるんだよ
0534デフォルトの名無しさん2010/11/17(水) 22:54:00
確かにいまどきMSのEnterpriseな製品を有り難がる人間は少ないだろうな。
ほんの数年前までは、嬉しそうにして購入してる人とかも居たかもしれん。
0535デフォルトの名無しさん2010/11/17(水) 23:00:03
で、Team Foundation Serverとやらは、VSSよりはぶっ壊れなくなったの？
0536デフォルトの名無しさん2010/11/18(木) 00:45:20
誰も使ったことのない、幻のシステムなので知らん。
0537デフォルトの名無しさん2010/11/18(木) 02:07:21
このスレは　無料バージョン管理システムについて語るスレ7　なんで間違えないように
0538デフォルトの名無しさん2010/11/18(木) 03:00:33
microsoft内の開発チームがTeam Foundation Serverを使うようになったら
考えてもいい
0539デフォルトの名無しさん2010/11/18(木) 03:03:17
バリバリ使ってるだろ
0540デフォルトの名無しさん2010/11/18(木) 03:18:07
microsoftが自分で使ってなかったのはVSSの話であって、
TFSは使ってるはず。
0541デフォルトの名無しさん2010/11/18(木) 03:21:20
microsoft内ではパッチベースだと聞いたよ
0542デフォルトの名無しさん2010/11/18(木) 03:28:21
それは逆にかっこいいな！
0543デフォルトの名無しさん2010/11/18(木) 03:30:48
自分が使わないものを人に使わせるのか
0544デフォルトの名無しさん2010/11/18(木) 05:46:48
>>537
そんなことないだろ
たまたま今は無料のものが普及していてコミュニティのひとつとしてここが使われているにすぎんでしょ

有料のものを使うのは公式のサポートが必要なこともあり、
それで済むならここで聞く必要ないからな

0545デフォルトの名無しさん2010/11/18(木) 05:47:38
>>538
自分たちは何使ってんだよ、ということだよな

今はmercurialなんだっけ？
0546デフォルトの名無しさん2010/11/18(木) 09:24:27
mercurialを脱共有するつもりだなM$FTめ
0547デフォルトの名無しさん2010/11/18(木) 16:58:59
いまはHG一択だろ
ふぉー
0548デフォルトの名無しさん2010/11/18(木) 21:31:33
Linuxのコンソールで、diffを行単位だけでなく、変更行の中の変更ワード単位で
（カラフルに）表示させたいんだけど、なんかいいツール有る？

Windowsで言えば、ExamDiffみたいな感じで。
0549デフォルトの名無しさん2010/11/18(木) 21:41:58
vimのdiff mode(vimdiff)とかは？
0550デフォルトの名無しさん2010/11/18(木) 21:44:03
>>548
$ vimdiff foo.txt bar.txt
0551デフォルトの名無しさん2010/11/18(木) 22:03:06
うちの色設定の問題なんだろうが、色が付いたところが塗りつぶされて、
結局差分が分からないという ＞ vimdiff
あれ、syntax切ればいいだけかな？
0552デフォルトの名無しさん2010/11/18(木) 22:03:15
vimdiffやってみたけど、結構使えそうだね。
ちょっとワードの分割基準が変だったけど。

あと、こんなのも見つけた。
http://mercurial.selenic.com/wiki/WordDiff
誰かさんの書いたシェルスクリプト + wdiffのようだが、これもまあまあ使える。
見やすいのはvimdiffの方かも。
0553デフォルトの名無しさん2010/11/20(土) 10:09:02
>>548
gitだと--word-diffとか--color-wordsとかで出来るよ
0554デフォルトの名無しさん2010/11/23(火) 12:29:29
>>55
1.6には--word-diffなかったから--color-words試した
いいねこれ

分かち書きがいい加減なのか、変更していない箇所も変更してる箇所と連続していると
差分として認識されてしまうみたいだけど、色が表示できる環境だと見やすい
05555542010/11/23(火) 12:53:26
>>554のアンカーミス
>>553 へです
0556デフォルトの名無しさん2010/11/23(火) 13:40:44
git使ってると、2chのアンカミスも直す方法があるような錯覚がして仕方ない
0557デフォルトの名無しさん2010/11/23(火) 16:34:07
git reset --hard HEAD^
0558デフォルトの名無しさん2010/11/23(火) 16:38:44
git commit --amend
が素直
しかしすでにpushされてる状況と考えると、gitでもやっぱり手遅れ
0559デフォルトの名無しさん2010/11/23(火) 19:12:16
なんというか、頭をガツンとリセットみたいな
0560デフォルトの名無しさん2010/11/23(火) 23:42:51
2ch用のproxy用意して書き込んだらローカルでは反映されていて、
pushしたら実際に投稿されるのでいいんじゃね？

掲示板も分散の時代だな
0561デフォルトの名無しさん2010/11/23(火) 23:43:40
レスアンカーがひどく長いハッシュ文字列になりそうだな
0562デフォルトの名無しさん2010/11/24(水) 00:18:50
削除人がammendした後にローカルでマージした古い履歴をあげてカオスに
0563デフォルトの名無しさん2010/11/24(水) 00:24:45
git commit --date='2011-01-01 00:00:00' -m 'あけおめ'
0564デフォルトの名無しさん2010/11/24(水) 00:48:26
http://hibari.2ch.net/test/read.cgi/tech/1231570128/
0565デフォルトの名無しさん2010/11/24(水) 01:32:58
>>560
network news の再来ですか。手元に過去のゴミログが全部あると。
2ch みたいのは、分散させなくても、Google App Engine 向きなんじゃないかなぁ、と思ったり。
0566デフォルトの名無しさん2010/11/24(水) 02:19:52
あんまり流行らなかったが、nyのBBSなんかがある種の方向なんじゃないかと
0567デフォルトの名無しさん2010/11/24(水) 20:19:38
コピペ連投もブランチ切ってrebaseで簡単に！
0568デフォルトの名無しさん2010/12/01(水) 14:49:02
個人情報削除せず新規顧客にコピー再販→流出
http://www.chunichi.co.jp/article/gifu/20101123/CK2010112302000115.html

これってやっちゃったってこと？
0569デフォルトの名無しさん2010/12/01(水) 16:19:57
>>568
http://slashdot.jp/security/article.pl?sid=10/09/28/0557220
0570デフォルトの名無しさん2010/12/02(木) 23:04:57
素人かよｗ
>>三菱電機インフォメーションシステムズ
0571デフォルトの名無しさん2010/12/03(金) 00:15:16
素人でももっとまし
0572デフォルトの名無しさん2010/12/04(土) 10:29:31
学生バイトの習作程度
0573デフォルトの名無しさん2010/12/07(火) 09:30:12
結局日本語ファイル名を扱うならBazaar一択ですか？
gitとか日本でも流行ってきてるから解決されてると思ったのに。
0574デフォルトの名無しさん2010/12/07(火) 09:35:51
>>573
あなたが解決すれば？何を解決するか知らないけど
0575デフォルトの名無しさん2010/12/07(火) 09:39:46
みんなドキュメントとか管理してないのかな？
0576デフォルトの名無しさん2010/12/07(火) 09:41:37
>>575
あなたはどうやって管理しているのですか？
0577デフォルトの名無しさん2010/12/07(火) 09:44:04
>>576
あなたはどうやって管理しているのですか？
0578デフォルトの名無しさん2010/12/07(火) 09:46:38
>>577
LaTex
0579デフォルトの名無しさん2010/12/07(火) 10:03:38
LaTexって分散バージョン管理できるんですか？
0580デフォルトの名無しさん2010/12/07(火) 10:39:12
>>579
https://github.com/progit/progit/tree/master/latex
0581デフォルトの名無しさん2010/12/07(火) 23:00:26
CVSのフロントエンド(GUI)をQtで作った。
まあ、フリーソフトが結構あるみたいだから、それでも良かったんだけど。
自分で作った方が自分好みに変更できていいよね。
0582デフォルトの名無しさん2010/12/11(土) 21:04:51
まだCVS使ってるとこって多いのかな？
何のメリットもないと思うんだけど。
0583デフォルトの名無しさん2010/12/11(土) 21:10:48
何使おうが勝手だろ
流行に飛びつくのはみっともない事だという美意識が近年なくなってむなしい
別に飛びつくなとは言ってないつもりだが
0584デフォルトの名無しさん2010/12/11(土) 21:21:31
流行だから飛びつくって考えの人は皆無だろ（＊人柱は除く
不満のあったところが改良されているから乗り換えるんだろ
0585デフォルトの名無しさん2010/12/11(土) 21:23:47
いや、ここでCVSの美点を語ってくれてもいいんだぞ？
0586デフォルトの名無しさん2010/12/11(土) 22:08:14
Subversionのブランチ・タグが特殊過ぎるからCVSを使いつづけている所は多いと思う
0587デフォルトの名無しさん2010/12/12(日) 01:24:32
CVS使っててイライラさせられる点しかなかったけどw

当時、周囲でバージョン管理してないプロジェクトやプログラマーはアホみたいな風潮が流れて、
CVS使ってみてこんな糞みたいなものをよくつかってたと当時ですら思ったわ


そして近年、昔のプロジェクトを弄ろうと久しぶりにWinCVS立ち上げたら気狂いそうになったぞ。
短気でない人間をも短気にさせるツールそれがCVS

もう全部Subversionのリポジトリ変換したからいいが

しかし、数年前から俺にとってのイライラツールがSubversionになろうとしてる、、、
0588デフォルトの名無しさん2010/12/12(日) 01:26:00
いやひょっとしたら、WinCVSが使いにくいだけだったのかもしれんな
それだったらスマソ

今はコマンドラインやシェル使うが当時はあまり使っていなかったからな
0589デフォルトの名無しさん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が遭遇してきた問題点とその解決策が
ハッカーの間で共有知になってないことが問題なのかもしれぬ
0590デフォルトの名無しさん2010/12/12(日) 01:32:13
誤爆・・・
0591デフォルトの名無しさん2010/12/12(日) 01:41:23
>>589-590
こっちでいいじゃん
http://d.hatena.ne.jp/hnw/20081024
0592デフォルトの名無しさん2010/12/12(日) 01:42:16
ここも
http://www23.atwiki.jp/selflearn/pages/55.html
0593デフォルトの名無しさん2010/12/12(日) 01:44:57
あとここ
http://hibari.2ch.net/test/read.cgi/tech/1251208950/466-474
0594デフォルトの名無しさん2010/12/12(日) 03:21:11
いまどき昔のCVS(WinCVS含む)使ったらファイル破壊されそうで怖い
0595デフォルトの名無しさん2010/12/12(日) 03:26:44
>>594
Subversionのbdbの方がもっと怖い
0596デフォルトの名無しさん2010/12/12(日) 13:47:47
bdbはとっくの昔にデフォルトでは使われなくなってるぞ
0597デフォルトの名無しさん2010/12/12(日) 13:56:24
>>594, 595 破壊方法教えてくれ
過去のプロジェクトメンテの必要性から、いまだに CVS と bdb 使った SVN が動いているが
一度も壊れたことがない。
壊れる危険性があるのなら、こいつらを新しい VC に移行させる立派な理由になる
0598デフォルトの名無しさん2010/12/12(日) 13:58:36
うろ覚えだけどbdbはLANでリポジトリ共有して同時アクセスするとやばいんだっけ。
0599デフォルトの名無しさん2010/12/12(日) 16:09:42
排他制御がおかしいとかだったような気がする。
0600デフォルトの名無しさん2010/12/12(日) 19:04:32
ちゃんとsvnserve通してれば問題は出ないだろうね。
割と最近までbdbで数十Gあるリポジトリ扱ってたけど、中身が壊れたことは無いな（今はFSFSに移行）。
ロックはよくおかしくなってたが。
svn bdb でググるとBerkeley DBが壊れたって話はいっぱい引っかかるけど、
読んでみるとロックがおかしくなったとかログファイルが壊れたとかで、リカバリできたって話ばっかりだな。

もちろん新規リポジトリで使う理由は全く無い。
0601デフォルトの名無しさん2010/12/12(日) 23:27:07
CVS派の人達は、Subversion初期の頃のイメージで停まってるって感じ？
未だにBDBの話なんかしてるし。

ま、今じゃSubversion自体が老害の域に入ってるんだけどね。
0602デフォルトの名無しさん2010/12/12(日) 23:32:30
> CVS派の人達は、Subversion初期の頃のイメージで停まってるって感じ？

ことの発端は >>597 が言ってる過去のリポジトリが現役で動いてるって話だろ？
複数のVCを一本化したいってのがそもそもの主旨だと思うけどな…
0603デフォルトの名無しさん2010/12/13(月) 08:00:24
>>591-593
誤爆したのにありがと

Subversionスレの方は追い出されてワロタww
0604デフォルトの名無しさん2010/12/13(月) 08:02:00
bdbはバージョンアップの度に使えなくなってリポジトリのアップグレードが必要になったから捨てたわ
今はリポジトリ頻繁に変わらないのかも知れないが
0605デフォルトの名無しさん2010/12/13(月) 08:04:08
>>601
CVSだかSubversionだかいっているうちは大丈夫。
デザイナー界隈はまだバージョン管理の必要性の議論が度々起こる。
思い切ってSubversion導入したとか言ってる。数年遅れてる。
0606デフォルトの名無しさん2010/12/13(月) 09:03:18
>>592
なんだよこれ
散々、言っておいて結局variantsで別途配布じゃねーか
MacユーザーがただSubversion入れただけだと誰しもが使える状況じゃないじゃん
全世界のMacユーザーがSubversion入れるときにvariantsもいれろっていって回るのかよ
0607デフォルトの名無しさん2010/12/13(月) 09:12:13
>>606
糞OSは使うな
以上
0608デフォルトの名無しさん2010/12/13(月) 10:01:29
svnはMacOSXでaddできるけどbzrはそれすらできないってことでは
0609デフォルトの名無しさん2010/12/13(月) 22:27:19
>>594
cvsつかったらファイル破壊されそうとか言ってるガキはなんなんだ？
何年前＆何プロジェクトで使われて実績積んできたか分かってるのか
0610デフォルトの名無しさん2010/12/13(月) 22:34:28
エキサイトするのは具体的な破壊の手順が提示されてからで十分だ
0611デフォルトの名無しさん2010/12/13(月) 22:50:58
>>610
*,vの中身を手でいじる
0612デフォルトの名無しさん2010/12/13(月) 23:10:02
エレクチオンはしているがエキサイトはしていない
0613デフォルトの名無しさん2010/12/14(火) 00:31:56
リポジトリを直接いじって破壊できないVCSなんてないだろうに。
CVSはリポジトリを直接いじらないとならないケースがあるのがダメだって話なら否定はしないけど。
0614デフォルトの名無しさん2010/12/14(火) 01:18:25
find .. | xargs sed -iみたいなことして.svnや.hgや.gitの中身まで変更しちゃうことはたまーにある
0615デフォルトの名無しさん2010/12/14(火) 01:27:27
cvsのリポジトリの中身はテキストファイルで、チェックサムが入っているように見えないから、
ファイルシステムが壊れかけの時、どうなるのか不安
0616デフォルトの名無しさん2010/12/14(火) 04:12:38
>>615
中身はRCSと全く同じなので、一応セパレータはあるから途中までしか読み出せないときはエラーになったはず。
その点、最新リビジョンが先頭に来る仕様だから,vファイルが壊れたときにも手動復元は比較的容易。
0617デフォルトの名無しさん2010/12/14(火) 21:18:53
>>614
よくやるわ…それ。
0618デフォルトの名無しさん2010/12/14(火) 22:30:09
さあ、今月で2010年も終了だ。
そこで現時点でどのバージョン管理システムを使うのがベターなのか考えてみよう！
条件は以下で、

・複数のプラットフォームで同程度の操作性が得られる。
・UIは色々選びたい。
・使用者のスキルによって破壊的な結果を招く事がない。
　※誤操作では破壊されない、但し、破壊しようという試みを防げうる必要はない。
・バイナリ、テキストなどを使用者が気にする必要がない。
・リソースの使用量を殊更気にする必要はないが、コストパフォーマンスは気になる。
・蛇足ながら、日本語で悩むのはなしで。
0619デフォルトの名無しさん2010/12/14(火) 22:31:20
>>614
おい、嫌なことを思い出させるな
0620デフォルトの名無しさん2010/12/14(火) 22:32:18
>>618

　な　い

この流れでわざとやってるだろw
0621デフォルトの名無しさん2010/12/14(火) 22:44:20
>>614のような悲惨な事故にはリポジトリが別に存在するsvnやcvsが強いな
0622デフォルトの名無しさん2010/12/14(火) 23:02:08
>>605
バイナリをメインで扱う仕事だと実際SVNとかかなり使いにくいから反発起こるのも判る。
ロックが必要な関係上、選択肢は事実上SVN・AlienBrain・Perforceしかないし。
0623デフォルトの名無しさん2010/12/15(水) 08:22:00
>>622
VSSもロックできるよ
0624デフォルトの名無しさん2010/12/16(木) 13:20:34
git がsubmoduleでディレクトリ分けしたリポジトリをgit svn dcommit できない
hgはできる？
perforceは？
0625デフォルトの名無しさん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は書いていないからどうなんだろう？
0626デフォルトの名無しさん2010/12/20(月) 12:04:06
WinMergeから乗り換えるメリットあるのかね

3ファイルの比較、多数のVCSに対応した比較ソフトウェア「Diffuse」
http://www.moongift.jp/2010/12/20101218-2/#more-24015
0627デフォルトの名無しさん2010/12/20(月) 12:21:31
>>626
gtkなので却下
0628デフォルトの名無しさん2010/12/20(月) 12:58:57
gtk却下ならtortoise*使わないってことか
0629デフォルトの名無しさん2010/12/20(月) 13:01:16
>>628
TortoiseHgはgtkからQtに移行中ですよ
0630デフォルトの名無しさん2010/12/20(月) 13:14:34
TortoiseBZR も Qt
TortoiseSVN は独自？
0631デフォルトの名無しさん2010/12/20(月) 13:20:10
プロジェクト名に普通名詞一語を付けるすべての開発者にイボ痔になる呪いをかけた
0632デフォルトの名無しさん2010/12/20(月) 13:46:31
何のことかわからない俺には効果がない

アッー！
0633デフォルトの名無しさん2010/12/20(月) 14:34:01
そして pwgen で付けたような
よくわからない名前のプロジェクトしか無くなった
0634デフォルトの名無しさん2010/12/20(月) 17:30:57
>>631
gitとかmercurialとかbazaarとかか？
0635デフォルトの名無しさん2010/12/20(月) 17:33:44
>>634
mercurialは形容詞。万歳！
0636デフォルトの名無しさん2010/12/20(月) 17:36:40
水銀製剤という名詞用法もあるのだよ
0637デフォルトの名無しさん2010/12/20(月) 18:29:48
オープンソースプロジェクト冬の時代の到来である
0638デフォルトの名無しさん2010/12/21(火) 17:55:59
イボ痔によってもたらされる初めての大規模な開発の危機
0639デフォルトの名無しさん2010/12/21(火) 17:58:40
でもPenとかRとか本当にググるのめんどいよな
0640デフォルトの名無しさん2010/12/21(火) 18:01:37
そもそもC++とかがすでに
0641デフォルトの名無しさん2010/12/21(火) 20:38:56
Clojureみたいにちょっとヒネった名前が
検索しやすくかつ覚え易くて好きだな
0642デフォルトの名無しさん2010/12/21(火) 23:19:11
gnomeやKDE関連ツールみたいに、頭にgを付けるとかKに変えるとかすると
検索には便利だな
0643デフォルトの名無しさん2010/12/21(火) 23:46:22
そこで例に gnome を出すのはどうかと。
0644デフォルトの名無しさん2010/12/22(水) 12:40:44
racketで検索してもひっかからないけど
pltなら引っかかる
0645デフォルトの名無しさん2010/12/24(金) 14:19:46
何だこの流れ
0646デフォルトの名無しさん2010/12/24(金) 14:22:03
ゲイツはすでにイボ痔だし

>>640
C#がでたときもググりにくいと言われていた気がする。
ググるはすぐに対応した気がするが、他の検索エンジンが対応されていないことがある
0647デフォルトの名無しさん2010/12/24(金) 14:23:18
>>646
TwitterでC#が検索できない。これはアンチWindowsぜいによるなんたらかんたら
http://search.twitter.com/search?q=%22C%23%22&lang=en
0648デフォルトの名無しさん2010/12/25(土) 22:17:30
>>647
ググルつかおーぜ
http://www.google.com/realtime
0649デフォルトの名無しさん2010/12/27(月) 15:28:37
個人でアプリを作るためにバージョン管理システムを使おうかと思うのだけど，お勧めのフリーソフトある？
ググってみてはいるが，個人向けのバージョン管理システムってどれがいいのかよくわからんorz

OSはWindowsで，Eclipseを使って開発する予定．
0650デフォルトの名無しさん2010/12/27(月) 15:34:29
>>649
http://www.eclipse.org/egit/
0651デフォルトの名無しさん2010/12/27(月) 15:34:40
文字コード絡みの面倒を抱えたくなければSubversionでいいんでね？
0652デフォルトの名無しさん2010/12/27(月) 15:57:36
>>650 >>651
早めのレスthx
ちょっと調べてみるわ
0653デフォルトの名無しさん2010/12/28(火) 05:43:33
Subversion関連サービスを提供する米WANDisco、Subversion改革計画を発表 - SourceForge.JP Magazine : オープンソースの話題満載
http://sourceforge.jp/magazine/10/12/27/0651200
0654デフォルトの名無しさん2010/12/28(火) 07:20:58
>>653
Subversionが2011年に分散型としても使えるようになるという事ですね。
Subversionに対するGit/Merculial/Bazaarの利点は分散型である事だと思うのですが、
Subversionが分散型として使えるなら今後もSubversionが主流なのでしょうか？
0655デフォルトの名無しさん2010/12/28(火) 07:47:02
SVNの今のmergeinfoが使い物にならないということか。
git/hgはハッシュとDAGでシンプルに実現しているのに、
SVNのリビジョン番号で直線的なモデルを変えない限り、複雑になるだけで使い物にならないでしょう。
0656デフォルトの名無しさん2010/12/28(火) 07:53:41
確かに。svnが進化して便利になったとしたら、それは最早svnという名前の別のvcsだな。
0657デフォルトの名無しさん2010/12/28(火) 07:58:36
>>654
分散型だけでなく完全なチェンジセット指向であることも利点。
.svnが各ディレクトリにあるのに対して、トップディレクトリに.git/.hgがある。
svnはディレクトリ・ファイル単位でチェックアウト・コミットできることは一見利点に見えるが、
今展開しているディレクトリ全体が整合性取れているかどうか保証ができない。
updateしないで、ブランチを作るためのcpコマンドをローカルでやると悲惨な結果になる。
0658デフォルトの名無しさん2010/12/28(火) 08:08:25
だね。
各ディレクトリに.svnがあることの利点を捨てれば、それはもうSVNではないし、
各ディレクトリに.svnがあることのデメリットはかなり大きい。

単純なディレクトリのコピーにまで要注意な点は、かなり足を引っ張る・・・はず
0659デフォルトの名無しさん2010/12/28(火) 11:50:02
>>653-654
どこにも「分散」とは書いてないが
0660デフォルトの名無しさん2010/12/28(火) 11:52:58
http://www.wandisco.com/php/pr.php?rss=0&prdate=2010-12-20
http://www.wandisco.com/svndisco
0661デフォルトの名無しさん2010/12/28(火) 13:00:14
Subversionの利点は個人的にはファイル名がUnicodeで扱われるということ。
GitかMercurialに移行したいと思ってもその点で躊躇してしまう。
0662デフォルトの名無しさん2010/12/28(火) 13:51:05
ファイル名をASCIIだけでつければノープロブレム。

0663デフォルトの名無しさん2010/12/28(火) 14:11:06
分散にしなかったらSubversionをどう改良するんだ？
0664デフォルトの名無しさん2010/12/28(火) 14:15:34
Subversionの最大の利点は、Tortoise何とかが枯れてる事だと思う。
他人に使わせるなら、これ超重要。
0665デフォルトの名無しさん2010/12/28(火) 14:30:39
>>664
枯れているか？古いWindows切り捨てらしいが。
0666デフォルトの名無しさん2010/12/28(火) 17:13:52
>>661
Bazaarはファイル名をUnicode文字列として扱う

まあUnicodeにもUnicode特有の問題があるが……正規化とか
0667デフォルトの名無しさん2010/12/28(火) 17:34:00
>>666
知ってるよ。だから抜いてるっしょ。でもBazaarは、シェアがちょっと不安。
よくMercurial/Gitと並んで書かれるけど、どうも今一つ垢抜けないというか・・・

Mercurialは色んなオープンソースで採用されてるし
GitはEclipseで入りやすいから、どっちかがファイル名とコミットコメントを
Unicodeにしてくれたら・・・と思う。
0668デフォルトの名無しさん2010/12/28(火) 17:40:07
開発元が同じUbuntuを除けば、EmacsやMySQLがBazaarを採用してる大手かな
0669デフォルトの名無しさん2010/12/28(火) 18:25:17
>>665
お前は何を言っているんだ
0670デフォルトの名無しさん2010/12/28(火) 18:33:20
>>667
同感。gitかhgでのファイル名の扱いが改善されれば…
でもそうはならないでしょうね
そのあたりの重要性が理解されてたら
ここまで普及する前に、初期の段階で改善されてたはずだし…
0671デフォルトの名無しさん2010/12/28(火) 18:37:20
>>670
http://hibari.2ch.net/test/read.cgi/tech/1251208950/439
0672デフォルトの名無しさん2010/12/28(火) 19:33:19
開発のコアメンバーが、「DVCSはソースコードを管理するもんだ。どこの国の人間だろうが
ソースコードのファイル名に英語以外を使う奴はアホ」、 とか発言しちゃうぐらいだし。
0673デフォルトの名無しさん2010/12/28(火) 19:42:31
バイト列で扱うのも利点がないわけじゃない

内部コードをUnicode系に固定すれば、Unicodeとロケール毎の文字集合の間で変換が起こる
その分計算量が増えるのは無視するにしても、一対一対応してない文字の扱いが難しい
しかも正規化や合成文字についても考える必要がある
要するにUnicodeも銀の弾丸にはならない

俺は基本的にBazaarを使って、既にGitを使ってる所ではGitを使って
MercurialやSubversionもどうしても使わなければ使うけど
0674デフォルトの名無しさん2010/12/28(火) 19:46:35
Bazaar+Eclipseならどのプラグインがいいかな？

Unicodeが問題解決にならないのは、Macの正規化を見ても分かるんだが
それでも問題を減らせると思うんだ・・・・
SubversionやBazaarが実現している訳で。。。。
0675デフォルトの名無しさん2010/12/28(火) 19:56:50
Javaのクラス名を日本語にするわけ？
0676デフォルトの名無しさん2010/12/28(火) 20:17:54
文書や画像のファイル名をローマ字綴りにする人は
漢字や仮名を使った方がいいんじゃね
あとindexesとかwritedとか書く人とか

>>674
bzr-eclipseって公式プラグインがあるがEclipseを使わないからいいかどうかわからん
利用者少ないからチケット送る羽目になるかもしれん
0677デフォルトの名無しさん2010/12/28(火) 20:23:13
http://d.hatena.ne.jp/odz/20061220/1166648625
0678デフォルトの名無しさん2010/12/28(火) 20:25:49
>あとindexesとかwritedとか書く人とか

わざとやってる人（または自動生成器）ならいくらでもいるぞ
0679デフォルトの名無しさん2010/12/28(火) 20:42:51
じゃあ今度からそれでいいや
ついでに形容詞も全部more/most xxxにしとこう
0680デフォルトの名無しさん2010/12/28(火) 20:46:31
オーウェルのやつ、実際に似たような人工言語なかったっけ？
0681デフォルトの名無しさん2010/12/28(火) 21:00:17
datasも気になるw
0682デフォルトの名無しさん2010/12/28(火) 21:11:13
だからってdatumとは・・・
0683デフォルトの名無しさん2010/12/28(火) 21:12:38
データを扱う場合に一件に限定することってまずないから
dataで問題ないと思う
0684デフォルトの名無しさん2010/12/28(火) 21:22:03
んじゃmediaは?
0685デフォルトの名無しさん2010/12/28(火) 21:27:50
複数系・単数形単体の問題よりもそれに応じた動詞の変化を忘れることが多いから困る
0686デフォルトの名無しさん2010/12/28(火) 21:52:19
>>680
esperanto
0687デフォルトの名無しさん2010/12/28(火) 21:54:11
>>672
酷い話ですね…
ソースコードしかバージョン管理しない
と思い込むヤツのほうがアホだよな…

と思ったが、
このツールはソースコード以外は管理するつもりがない
と明言してるのは、それはそれで意味があることかもしれない
ドキュメント等は別のツール、つまりgitやhg以外で管理しろ、
使い分けろ、なんでもコレでやろうとするな、
ということなんでしょうかね
0688デフォルトの名無しさん2010/12/28(火) 22:27:30
>>687
ソースと資料を同じレポジトリに突っ込んでたら
ドキュメントのサイズが膨れ上がってドキュメント専用のレポジトリが
欲しくなることは多々あるんだけど、
それでもソースや設定ファイル周りとかで日本語ファイル名を使いたいトコもある。
全部英語だとファイル名の見た目にメリハリがなくて見にくいんだな。
何にせよ、エンコードが沢山あるってのが問題で
Unicodeはその問題を解決しようとしたのに正規化とかワケワカラン問題を産んでしまった。

こういうのって、英語圏の連中にとっては問題の理解が難しいわけで
それだけで手を上げたくなる気持ちもわからんでもない。
でも、それでも・・・ちょっと使いにくいんだよな・・・CVS時代に逆行したようで・・・
0689デフォルトの名無しさん2010/12/28(火) 22:59:17
正規化はまあいいんだがUnicodeとJISが並立しているのが面倒くさい

統合漢字/互換漢字/異体字セレクタはJISでも包含基準や改定に伴う追加があるから
どっちにせよ似たようなことを考える必要があるが
0690デフォルトの名無しさん2010/12/28(火) 23:41:20
「＼」問題を日本人でさえ理解していない人間が多いのに欧米人にどうやって理解させる？
欧米人にとっては大文字小文字の方がはるかに重要。
0691デフォルトの名無しさん2010/12/28(火) 23:56:59
>>690
そ、それは日本人自体が招いた問題だから自ら問題解決すべきでは？＞「￥」「＼」問題
0692デフォルトの名無しさん2010/12/29(水) 00:15:57
nkfのオプションの多さを考えたら、ファイル名を「文字」として扱うことが如何にナンセンスか分かると思うが。
0693デフォルトの名無しさん2010/12/29(水) 00:17:07
なぜ日本も韓国もバックスラッシュの位置に通貨記号を割り当てたんだろうな……
0694デフォルトの名無しさん2010/12/29(水) 00:49:42
韓国は日本の真似しただけだろニダ
0695デフォルトの名無しさん2010/12/29(水) 01:01:35
http://ja.wikipedia.org/wiki/ISO/IEC_646
割り当てていいよと言われたから で FA
0696デフォルトの名無しさん2010/12/29(水) 01:04:44
むしろ何で\がパスデリミタ…
0697デフォルトの名無しさん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
0698デフォルトの名無しさん2010/12/29(水) 01:46:13
>>695
だから、割り当てなさい！と言われたんじゃなくて、割り当てていいよ┐(ﾟ～ﾟ)┌
と言われて割り当てたのは日本人自身なんだってば。
0699デフォルトの名無しさん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
0700デフォルトの名無しさん2010/12/29(水) 02:19:56
ファイル名の命名規則を話しだすと
7bit文字に収めろだの
記号を使うなだの
全部小文字にしろだの
全部大文字にしろだの
ドット区切りサフィックス(つーか拡張子)は3文字以内に汁だの
8+3に収まってないと怒り狂われるだの
プリフィクス+連番(PRG0000)以外は認めないだの

未だにファイル名に日本語が必要な場面が思い浮かばないぜ。
0701デフォルトの名無しさん2010/12/29(水) 03:30:38
>>699
MercurialとTortoiseHgのWindowsインストーラで配布されているものは、
CaseFoldExtensionという拡張がバンドルされているみたい
http://mercurial.selenic.com/wiki/CaseFoldExtension
0702デフォルトの名無しさん2010/12/29(水) 03:40:45
bzrの場合は
http://doc.bazaar.canonical.com/latest/developers/case-insensitive-file-systems.html
大文字小文字の違いだけの同じファイル名のファイルが既にある時は、そのファイル名の方向に正規化する
0703デフォルトの名無しさん2010/12/29(水) 14:51:34
>>687-688
例えソースコードしかバージョン管理しなくてもいくらでもバカが
Windowsのエクスプローラーで「～～ - コピー」「～～ - コピー (2)」「～～ - コピー - コピー 」みたいなファイルをリポジトリに入れてくるわけだが…

プログラマー向けだしというのもわかるし、
そういうのではない一般向けのDropboxは考慮されてるしな(Macとのやりとりは知らん)

Windowsならcygwin 1.7のようにWindowsのUNICODEをUTF-8に変換してその手のアプリに渡すのがまだ楽そうだわ
そうやっているとUnixのファイルシステムで作れないファイルを入れたりもできてしまうが、それは文字コードの問題じゃないしな
0704デフォルトの名無しさん2010/12/29(水) 15:00:11
>>703
> 例えソースコードしかバージョン管理しなくてもいくらでもバカが
> Windowsのエクスプローラーで「～～ - コピー」「～～ - コピー (2)」「～～ - コピー - コピー 」みたいなファイルをリポジトリに入れてくるわけだが…
githubのpull リクエストみたいにpullしないで放置プレイにする

> Windowsならcygwin 1.7のようにWindowsのUNICODEをUTF-8に変換してその手のアプリに渡すのがまだ楽そうだわ
> そうやっているとUnixのファイルシステムで作れないファイルを入れたりもできてしまうが、それは文字コードの問題じゃないしな
？？？
0705デフォルトの名無しさん2010/12/29(水) 15:17:06
>>704

> >‎ Windowsならcygwin 1.7のようにWindowsのUNICODEをUTF-8に変換してその手のアプリに渡すのがまだ楽そうだわ
> >‎ そうやっているとUnixのファイルシステムで作れないファイルを入れたりもできてしまうが、それは文字コードの問題じゃないしな
> ？？？

>>699のようなことかと思う。下手するとupdateやpullできなくなる。
0706デフォルトの名無しさん2010/12/29(水) 15:31:42
ext2/ext3は'/'と'\0'以外に制約無いし、'/'=0x2FでCP932の２バイト目には出てこないよ
0707デフォルトの名無しさん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
0708デフォルトの名無しさん2010/12/29(水) 23:15:36
やっぱbzrだな。
0709デフォルトの名無しさん2010/12/29(水) 23:50:22
ArchやDarcsのことも時々でいいから思い出してください
0710デフォルトの名無しさん2010/12/30(木) 00:47:49
Bazaarは日本語ファイル名も問題なさそうだし、付属のBazaar Explorerも悪くないが、ブランチが切りづらい。
0711デフォルトの名無しさん2010/12/30(木) 06:55:45
TortoiseHG単体でバージョン管理が出来るようになったら本気出すけど
>>497ってそうなったってこと？
0712デフォルトの名無しさん2010/12/30(木) 07:15:31
>>711
http://hibari.2ch.net/test/read.cgi/tech/1251208950/496-498
コピペ元のMercurialスレで、2番目は正しいと突っ込まれています。
詳しく知りたければMercurialスレで聞いてください。
0713デフォルトの名無しさん2010/12/30(木) 07:59:50
http://hibari.2ch.net/test/read.cgi/tech/1251208950/507-509
MercurialスレでSVNのロック機能不用論がでてますが、
総合スレであるここで突っ込ませてください。
ロック機能は複数の人による同時編集ができない代わりに
マージが不要になる利点があります。

ソフトウェア開発では同時編集禁止は不便なので
ロックせずにマージで頑張るバージョン管理システムが広まりました。
しかしアイコンのようなバイナリファイルはマージするのが困難なので
同時に一人しか修正しない事を保証するロックに頼らざるを得ません。
ロック機能でもある程度は共同作業が楽になります。
ですからバイナリファイルも扱わせるならロック機能は必須でしょう。
0714デフォルトの名無しさん2010/12/30(木) 08:12:52
>>713
ロックは前スレでやった
0715デフォルトの名無しさん2010/12/30(木) 10:47:24
ロック不要論者は馬鹿すぎて扱いに困る
論拠を聞いても結局「俺が使わないから要らない」以上のことは何も言わないし
0716デフォルトの名無しさん2010/12/30(木) 11:35:54
>713
ロック不要論じゃなくて、有った方がいいけど、無くてもまぁ運用で或る程度は何とか
なるじゃないのって話でしょ。人数や求める厳密さによるけど。

Subversionでもロックの不徹底は多そうだし。共有ディレクトリやDropboxだけで
やってるとこも、そのへん、なあなあでしょ？
0717デフォルトの名無しさん2010/12/30(木) 11:55:01
VCSはコミュニケーションツールではない
バイナリでなくてもコンフリクトはおきる
機械的なマージは時として信用できない
0718デフォルトの名無しさん2010/12/30(木) 11:59:22
VCSは最低限のインフラと捉えた方がいいのは確か
チャットやMLやWikiなどを併用していない開発体制ではどうにもならんところはあるさ
0719デフォルトの名無しさん2010/12/30(木) 12:08:09
VCSとは独立して、ネットワーク経由でファイルのアノテーションを共有出来るツールがあると
便利かもなぁ。ロックとかコメントとか。
0720デフォルトの名無しさん2010/12/30(木) 12:36:30
>>719
あーそれ良いね。VCSにロックは要らないと思うけど、
アドバイザリなロック情報を1アクションで共有出来るような
ツールがあったら、何かと便利な気がする。
0721デフォルトの名無しさん2010/12/30(木) 13:55:06
それは興味深いな
0722デフォルトの名無しさん2010/12/30(木) 15:49:34
>>718
上で出た共有ディレクトリやDropboxの運用だって、コミュニケーションなしじゃやってらんないしな

>>719
それこそ、チケット管理のシステム使ったり、コミットログやBTSのログをIRCに流すとかでいいんじゃないのか

あーでも、今メールで流してるけど数多すぎて全然みないなw
0723デフォルトの名無しさん2010/12/30(木) 15:52:25
プログラマー向けにはちゃちだと思っていたDropboxをデザイナが便利に使っているのを見て前にヒアリングしてたんだけど、
そのなかでいいと思ったのは「更新されたり、衝突したらポップアップで通知してくれること」だったわ

Windowsのクライアントの話なので他もそうかはわからんが
0724デフォルトの名無しさん2010/12/30(木) 17:01:25
>>702
ちなみにバグってるけどな。
0725デフォルトの名無しさん2010/12/30(木) 17:35:18
Bazaarの利用テストをしてみた。

・日本語コミット文、日本語ファイル名がOK。
→ GitやMercurialは日本語ファイル名を入れると、Windows - Linuxでリポジトリの共有が不可能になる。

・通しのリビジョン番号で操作できる
→ Mercurialと同じで、ハッシュ値のGitよりは操作が楽。

・commitは自由に取り消せる（uncommit）。
→ Gitのreset --hardと同じで、1回より取り消せないMercurialよりは手軽。ただし、管理上はマイナスかも。

・ブランチの作成時に、ディレクトリ（フォルダ）の指定がいる。
・ブランチを変更するときは、作業ディレクトリの変更がいる。
→ ブランチ名だけでいいGit、自動的に無名ブランチができるMercurialの方が楽。

あまり使い込んでいないので誤解があるかも知れないが、分岐やマージの頻度が低い所だと便利かも知れない。
0726デフォルトの名無しさん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は、まだバグが多いのかも知れない。
0727デフォルトの名無しさん2010/12/30(木) 17:56:42
>>725
> ・日本語コミット文、日本語ファイル名がOK。
> → GitやMercurialは日本語ファイル名を入れると、Windows - Linuxでリポジトリの共有が不可能になる。
いつまでも、こんな無知を晒すのやめてくれない？
0728デフォルトの名無しさん2010/12/30(木) 17:59:40
> ・通しのリビジョン番号で操作できる
> → Mercurialと同じで、ハッシュ値のGitよりは操作が楽。
bzrのリビジョン番号あとから変わるらしいじゃん。
あと、commit id、何あれ？本当に分散型なの？
0729デフォルトの名無しさん2010/12/30(木) 18:02:36
>>727
GitとMercurialで、日本語ファイル名を取り扱う方法を教えてくれ。もちろんcygwin無しでね。
0730デフォルトの名無しさん2010/12/30(木) 18:03:39
>>725
> ・commitは自由に取り消せる（uncommit）。
> → Gitのreset --hardと同じで、1回より取り消せないMercurialよりは手軽。ただし、管理上はマイナスかも。
hg backout/hg strip
0731デフォルトの名無しさん2010/12/30(木) 18:10:54
>>729
「リポジトリの共有」なら日本語関係無いよね？
0732デフォルトの名無しさん2010/12/30(木) 18:12:21
>>730
MQのhg-stripで消せばいいのね。hg-backoutは、履歴に残るよね？
0733デフォルトの名無しさん2010/12/30(木) 18:13:20
>>731
GitとMercurialは、文字コードが違う処理系でも共有はできるが、日本語ファイル名は化けると言いたいわけですね。
0734デフォルトの名無しさん2010/12/30(木) 18:17:04
>>733
人間の目から見て特定のロケールで「化ける」だけ。Windowsだとチェックアウトできないかもしれないが。
0735デフォルトの名無しさん2010/12/30(木) 18:19:47
「リポジトリの共有」はgitならbare、hgでもbareもどき。作業ファイルの展開とは関係ない。
0736デフォルトの名無しさん2010/12/30(木) 18:24:09
>>734-735
なるほど。ところで、CP932のMS-WindowsとUTF-8のLinuxの混在環境で、日本語ファイル名をつけたときにGitは実用的に問題はないの？
人の目で見て化けていて、チェックアウトできないかも知れないだけだから問題ない？
0737デフォルトの名無しさん2010/12/30(木) 18:29:43
>>736
CP932/CP950以外では問題なく使われている
0738デフォルトの名無しさん2010/12/30(木) 18:29:50
>>728
>bzrのリビジョン番号あとから変わるらしいじゃん。
>あと、commit id、何あれ？本当に分散型なの？

詳しくよろしく。
0739デフォルトの名無しさん2010/12/30(木) 18:36:13
>>738
http://hibari.2ch.net/test/read.cgi/tech/1284467898/59
0740デフォルトの名無しさん2010/12/30(木) 18:41:48
>>739
それで生じるデメリットって何？
0741デフォルトの名無しさん2010/12/30(木) 18:46:49
>>740
メールアドレス-時刻-ごくみじかいハッシュ
でしょ、メールアドレス、時刻は偽造可能。
ハッシュとして長さが短すぎ。
git/hgはハッシュの最初の数文字入れればリビジョン特定できるが、それもできない
0742デフォルトの名無しさん2010/12/30(木) 18:47:22
>>728
bzrは分散型だと思わないほうがいい。
ローカルコミットできる中央型
0743デフォルトの名無しさん2010/12/30(木) 18:48:51
>742
どのような点で？
0744デフォルトの名無しさん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を付けている。
0745デフォルトの名無しさん2010/12/30(木) 18:53:16
>>741
狙ってリビジョンIDを衝突させることができることを問題にしているの？
なら、リビジョンIDは好きに作れるから、別に偽装とかしなくていいよ。

で、狙ってリビジョンIDを衝突させられることのどこが問題なの？
0746デフォルトの名無しさん2010/12/30(木) 18:58:17
>>741
昨日、嫁に三行半を突きつけられた隣の席の鈴木が、Bazaarだと自棄になってCommit IDを衝突させてくるってこと？
0747デフォルトの名無しさん2010/12/30(木) 19:00:38
それは課長や部長が解決する問題であって、VCSが解決する問題ではない
・・・と思う
0748デフォルトの名無しさん2010/12/30(木) 19:18:40
>744
単調増加の意味するところがいまいちよく分からんが、とにかく、
今までDVCS比較話で聞いた事のない興味深い話であった。
0749デフォルトの名無しさん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替わりに使えること。
中央リポジトリ上のブランチはこの設定がおすすめ。
0750デフォルトの名無しさん2010/12/30(木) 19:46:31
>749
なるほど、全然分からん。
0751デフォルトの名無しさん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
0752デフォルトの名無しさん2010/12/30(木) 20:20:04
bzrはrebase文化でないわけ？
0753デフォルトの名無しさん2010/12/30(木) 20:28:40
>>751
さんくす、何となく分かった。
0754デフォルトの名無しさん2010/12/30(木) 20:43:38
>>752
rebase は拡張としては用意されているけど、bzr-svnとかbzr-gitとかでよく使われているだけで、
bzrで管理されているプロジェクトでは普通にマージを使ってると思う。
0755デフォルトの名無しさん2010/12/30(木) 20:45:00
>>752
単純に言うとBzrにはブランチがない。必ず1列に並ぶ。
0756デフォルトの名無しさん2010/12/30(木) 22:03:39
>>751のおかげで、Mercurialを使いつづける勇気が沸いた。
0757デフォルトの名無しさん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
0758デフォルトの名無しさん2010/12/30(木) 23:35:25
>>757
ぜひbzrとhgの比較もしてもらいたいものですね！
0759デフォルトの名無しさん2010/12/30(木) 23:47:24
>>758
http://www.atmarkit.co.jp/fjava/rensai4/devtool03/devtool03_5.html
0760デフォルトの名無しさん2010/12/31(金) 00:03:26
>751
おかげで、bzrは候補から外す事にしたよ。
つーか、この件、マジで初耳なんだが。
今までほんとに使ってるbzrユーザは居なかったのか？
0761デフォルトの名無しさん2010/12/31(金) 01:09:51
>>760
bzrユーザーは日本語使えれば何でもいい奴らしかいないｗｗｗ
0762デフォルトの名無しさん2010/12/31(金) 01:12:34
>>760
日本語ファイル名が使えるのと、Bazaar Explorerは悪く無いと思う。
>>751のリビジョン番号の変化は再現できていないけど、>>751に解決方法は書いてあるし問題ない。
しかし、ディレクトリがブランチなので、他の分散バージョン管理システムに比べると、かなりSVNに近いのがどうも気になる。
0763デフォルトの名無しさん2010/12/31(金) 01:47:33
なるほど、pushされるとリビジョン番号が変化する。
0764デフォルトの名無しさん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/".
0765デフォルトの名無しさん2010/12/31(金) 07:34:28
>>761
そういう奴はSubversionを使う
0766デフォルトの名無しさん2010/12/31(金) 10:32:24
>>760
> 今までほんとに使ってるbzrユーザは居なかったのか？
svnユーザでbzrを検討したユーザはあまりの使えなさに幻滅してsvnに戻る
git・hgユーザはbzrは眼中にない・少し触って重くて止める
cvsからbzrに移ったEmacsは特異な存在
0767デフォルトの名無しさん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は友達の輪に入れないオレには無理なようだ。
0768デフォルトの名無しさん2010/12/31(金) 17:08:51
つまり、こういう事か。

bzr　　リア充向け
git　　 nerd向け
hg　　それ以外のhuman beings向け
0769デフォルトの名無しさん2010/12/31(金) 17:33:33
ああ、俺は半端者だからBazaarとGitは使うけどMercurialは使わないのか

リア充はOS XのTime Machineを使うような気もするが
0770デフォルトの名無しさん2010/12/31(金) 18:30:33
Time Machineはバックアップ以外の用途に使えるのだろうか。
Mercurialはpush時に衝突が発生しないから楽だよ。
0771デフォルトの名無しさん2010/12/31(金) 19:17:39
いや、バックアップ用
Windowsのシステムの復元がデータ領域を対象にした感じ
0772デフォルトの名無しさん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風、どのワークフローにも対応できるのが利点と言えるけど、
逆にそれで混乱してしまう人もいる。
0773デフォルトの名無しさん2010/12/31(金) 21:47:28
>>772
> 2) (git風) append_revisions_only = False にし、みんな適当に push する。
gitでみんな適当になんかpushしてねーよ
0774デフォルトの名無しさん2010/12/31(金) 21:53:03
>>772
さんくす。共有リポジトリにpushする運用だと、Bazaarはちょっと使いづらいね。
0775デフォルトの名無しさん2010/12/31(金) 22:50:39
>>773
言い方が悪かったな。すまん。
ちゃんとしたプロジェクトではgitでもLaunchpadと同じマージリクエスト＆コードレビュースタイル
なのは判ってる。

身内の少人数内でレビュー必須みたいなしっかりしたフローが無い状況における、
ワークフローとして、svnとgitの典型的なスタイルを挙げたつもり。
そういう状況でgitだとみんなでtrunkにpushしちゃうんだけど、俺の周辺だけ？
0776デフォルトの名無しさん2010/12/31(金) 22:53:24
>>774
どう使いにくそう？
append_revisions_onlyは今のところデフォルトでFalseなのでpush自由だし、
デフォルトTrueになってもちゃんとFalseにするオプションは用意される。
ログを見るときもデフォルトではメインラインだけを表示するけど、サブラインも
表示するオプションが用意されている。

みんなで適当にpushできて、連番のリビジョン番号は恒久的なIDがわりには使えない、
Mercurialと特に違いは無いと思うけど。
0777デフォルトの名無しさん2010/12/31(金) 23:07:24
>>776
> みんなで適当にpushできて、
・push先に新たなheadを作らない
・svn的ブランチは別リポジトリに分ける
・bzrの独自の概念だと言っている「メインライン」は、
　hgではリポジトリの分離と「名前付きブランチ」

> 連番のリビジョン番号は恒久的なIDがわりには使えない、
hgの場合、リビジョン番号はリポジトリで固有というコンセンサスが出来ているけど、
bzrの場合出来ているの？
0778デフォルトの名無しさん2010/12/31(金) 23:07:38
罵倒は2chの風物詩として違いは参考になる。それぞれがみな異色に見えるなw

>>729
おーっとここで将軍様「トラを捕まえろ一休、屏風から出さずにな」と

>>733
どうしてもcygwinが嫌なら仮想マシンでファイル共有してLinuxからWindowsのファイルをバージョン管理すればいいよ
gitはそれでやってるわ。面倒なときはcygwinのgit使う

>>736
UTF-8のファイル名をコミットするのはともかく、CP932は他の環境だとかなり大変だから
CP932でコミットするのは本当におすすめできないな。
今の時代、将来的に他の環境で使うことはないなんていいきれん。

別にファイルの中身の文字コードやコミットログはなんとでもなるんだがな
0779デフォルトの名無しさん2010/12/31(金) 23:15:29
>>776
> みんなで適当にpushできて、連番のリビジョン番号は恒久的なIDがわりには使えない、
> Mercurialと特に違いは無いと思うけど。
「公開リポジトリ」上で"hg strip"、"hg rebase"などの履歴の編集はまずしない。
この場合、公開リポジトリのリビジョン番号は０からの連番で変更されることはない。
だから、hgweb、bitbucketでのリビジョン番号は恒久的なIDとして捉えても良い。
でも、hg logなどでの出力の"123:abcdefg"のようなスタイルの方が望ましい。
0780デフォルトの名無しさん2010/12/31(金) 23:21:22
>>765
うちは面倒なので中央svnにして使うやつはgit-svnなりだなw
こちらの使う範囲内では、UTF-8環境ならgit-svnで日本語ファイル名を扱えることは確認済み

しかしCygwinのgitkはtkのバージョンのせいか設定が悪いのか何故か化けるし不安定

git-svnはcygwinは1.7だし大丈夫だと思うが、Linuxのディストリによってはパッケージのものは古くて不便なので注意



0781デフォルトの名無しさん2010/12/31(金) 23:32:29
bzrは、設計のセンスが悪いなぁ。
0782デフォルトの名無しさん2010/12/31(金) 23:37:35
>>781
Subversionの真似をしているから当たり前
0783デフォルトの名無しさん2011/01/01(土) 00:06:11
>>776
> どう使いにくそう？
1. append_revisions_only = Falseだと、pushしやすいがリビジョン番号が変化する。
2. append_revisions_only = Trueだと、pull requestを送る運用になる。
3. checkoutをすると、SVNと運用が変わらない（？）

共有リポジトリをファイル共有の目的でも使いたい現場だと、(2)は使いづらそうな感じはする。
イメージしている運用スタイルだと、リビジョン番号の変化に慣れるべきなのは分かった。
0784デフォルトの名無しさん2011/01/01(土) 00:10:30
>>778のGitの運用を見ていると、日本語ファイル名は重要な問題な気がしてくる。
0785デフォルトの名無しさん2011/01/01(土) 00:17:31
>>776
Mercurialは、コミットの統合や削除を意識して行わない限り、あるリポジトリの中のリビジョン番号は変化しない。
Bazaarだとオペレーターが気づかない間に、同じリビジョン番号が、他のチェンジセットに入れ替わる気がするんだが。
uncommitとかの狙いが外れて気づかなかったら大惨事。
0786デフォルトの名無しさん2011/01/01(土) 00:45:14
gitとmercurialとbazaarはbranchの概念が3者共全く違うという所から
考え直した方がいいと思う
0787デフォルトの名無しさん2011/01/01(土) 00:49:48
>>786
gitとmercurialはそんなに違わない。bazaarがsubversionを意識し過ぎ
0788デフォルトの名無しさん2011/01/01(土) 01:07:50
>>786
ブランチの概念、かなり違うね。

>>787
Mercurialは全てのチェンジセットが独立したブランチみたいなもんだから、

・gitと異なり、ブランチを作成しなくても、自動で名前無しブランチができる。
・gitと異なり、同一（名前付）ブランチ内で、さらに分岐ができる。
・gitと異なり、pushでconflictは起きない。同じチェンジセットに編集を加えても、独立に分岐したチェンジセットになる。
・gitと異なり、ある（名前付）ブランチのチェンジセットを消すと、子孫にあたる別のブランチも消える（hg-strip）。
0789デフォルトの名無しさん2011/01/01(土) 01:43:34
>>788
ここでも紹介されているけど、Mercurialにはbookmark拡張がある。
http://anlyznews.blogspot.com/2010/12/gitmercurial8.html
hg-gitでbookmark拡張はほぼ必須で、gitのブランチの移植みたいなもの。
前はbookmarkはロカールでしか扱えなかったけど、最近のバージョンでリモートと同期もできるようになった。
07907762011/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
に違反しないと。
0791デフォルトの名無しさん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のブランチとは異なる。
0792デフォルトの名無しさん2011/01/01(土) 05:48:09
大雑把に特性をまとめてみた。

Mercurial:
・一つのリポジトリで複数のブランチが扱える。
・無名ブランチが自動で切られるため、分岐がしやすい。
・名前付ブランチもつける事ができる。目印なので、つけなくても操作に支障は無い。
・ブランチはツリー構造。あるブランチ内のチェンジセットを消すと、他のブランチに含まれる子孫チェンジセットも消える。

Git:
・一つのリポジトリで複数のブランチが扱える。
・ブランチ名を考える必要がある。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。

Bazaar:
・一つのリポジトリで一つのブランチ（メインライン）。
・マージするときは、他のリポジトリのコミットを傍流として記録。
・ディレクトリ配置を考える必要がある。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
0793デフォルトの名無しさん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 というオプションがある。
0794デフォルトの名無しさん2011/01/01(土) 08:56:36
>>793の続きと訂正
> 無関係なリポジトリに対してpull/pushしようとすると、
> 「無関係なリビジョンだよ」と怒られて失敗する。
『「無関係なリポジトリだよ」と怒られて失敗する。』に訂正。

>> ・push先に新たなheadを作らない
head=無名ブランチという紹介されているようだけど、
オプション無しでpushすることによって新たなheadが出来る場合、
「新たなheadができるよ」と怒られて失敗する。
これも-fオプションを付けることで強制的にpushできるけど、
あまりやってはいけないこと。
この場合、まず、リモートからpullする。
これでローカルに無名ブランチができる。
この状態をmulti heads状態とも呼ぶ。
これをローカルでマージしてheadを１つにしてからpushする。
0795デフォルトの名無しさん2011/01/01(土) 09:36:05
>>792
Bazaarのリポジトリとブランチは一対一じゃないような気がするんだが
0796デフォルトの名無しさん2011/01/01(土) 09:44:49
>>795
詳しく教えてください。
0797デフォルトの名無しさん2011/01/01(土) 10:45:38
Bazaarはブランチ格納用リポジトリ作ったり
そこは本来は分かれている必要がある、という思想で作られているんだろうと思う。
svnのように見える一旦かも知れないが
0798デフォルトの名無しさん2011/01/01(土) 10:56:52
>>796
bzr init-repo foo; cd foo; bzr init bar
とするとリポジトリfooのブランチbarが作られる

少し前に話されてたリビジョン番号については「Bazaarの哲学」を読めば
Bazaarの奇妙さとその意図が分かるかも
0799デフォルトの名無しさん2011/01/01(土) 11:10:50
bitbucketはなんで無料なの
0800デフォルトの名無しさん2011/01/01(土) 14:25:46
>>791
> ブランチ名で絞り込みは簡単にできるよ（hg log -b ブランチ名）。
TortoiseHg現安定版1.1.xの場合、別の名前付きブランチの親も表示させるのが仕様。
Revision Set の所にbranch("名前付きブランチ名")とすることで、その名前付きブランチだけ表示可。
次期TortoiseHg1.9では今のところリストボックスでどっちも可能。
0801デフォルトの名無しさん2011/01/01(土) 16:27:44
>>798
さんくす。試してみる。
0802デフォルトの名無しさん2011/01/01(土) 16:34:49
Bazaarのリポジトリは、ディスク節約・ブランチ作成高速化用のオプションか。
http://doc.bazaar.canonical.com/latest/en/user-reference/init-repository-help.html
0803デフォルトの名無しさん2011/01/01(土) 17:01:22
>>795
SCMのリポジトリとBzrのリポジトリでは意味がかなり違う。
Bzr厨はなぜかその事を認めない。
0804デフォルトの名無しさん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 になる。
0805デフォルトの名無しさん2011/01/01(土) 17:10:28
どうやらbzrは、無邪気にgit、hgと並べるようなもんじゃ
ないらしいな。
0806デフォルトの名無しさん2011/01/01(土) 17:11:25
>>804 は作業ツリーを無視して、リポジトリとブランチとリビジョンだけを考えた場合の話ね。

bzrは作業ツリーとブランチも切り離されていて色々な運用が可能で、gitとbzrを併用している
ユーザーには、bzrのブランチをgitの用に扱えるようになるbzr-coloってプラグインがお勧め。
0807デフォルトの名無しさん2011/01/01(土) 17:16:03
svnからbzrに移行した人はリポジトリとブランチと作業ツリーの区別が付いているから
bzrの概念が判りやすいんだけど、gitやhgから入った人はブランチとリポジトリの区別が
svnよりも曖昧になりがちだから、bzrを使い始めるときに混乱するよね。

bzrは分散型でマージが協力なsvnと思ったほうが良さそう。
0808デフォルトの名無しさん2011/01/01(土) 17:23:55
gitはsvnの全否定から入っているからブランチと言えばcvsのブランチ
少しでもsvnの匂いがするものは、拒否
0809デフォルトの名無しさん2011/01/01(土) 17:33:52
>>808
svnにブランチはない
0810デフォルトの名無しさん2011/01/01(土) 17:39:30
>>809
> svnにブランチはない
あ、そうか、bzrが意味不明なことを言いつづけているのはそのせいか
0811デフォルトの名無しさん2011/01/01(土) 17:45:53
皆様のレスを読んだ上で、再度、大雑把に特性をまとめてみた。

Mercurial:
・一つのリポジトリで複数のブランチが扱える。
・分岐時は、無名ブランチが自動で切られる。名前付ブランチもつくる事ができるが、目印なので必須では無い。
・ブランチ内のチェンジセットは木構造に並ぶ。
・分岐したブランチは、元のブランチに依存する。あるブランチ内のチェンジセットを消すと、別のブランチにある子孫チェンジセットも消える。
・複数のリポジトリで変更を行いpushしても、分岐しているので衝突はしない。ただし、解消が要求されるmulti-head状態になるので、先にpullが望ましい。

Git:
・一つのリポジトリで複数のブランチが扱える。
・分岐時に、ブランチ名を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のリポジトリで変更を行いpushすると、衝突が発生する。先にpullが必要。

Bazaar:
・ブランチだけで運用を行える。リポジトリを作ると、複数ブランチでデータを共有して省スペース、ブランチ作成などの高速化ができる。
・分岐時に、ブランチのディレクトリ配置を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・マージするときは、自分のリポジトリのコミットをメインライン、他のリポジトリのを傍流として記録。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のブランチで変更を行いpush/pullすると、衝突が発生する。先にpullが必要。
0812デフォルトの名無しさん2011/01/01(土) 17:50:34
Better Subversionを求めてるだけならgitらしい運用は大袈裟過ぎるし、gitらしい運用が不要なら、
gitじゃない方がその目的には適してるんじゃないかな

git-svnを使うのはgitらしい運用だ！と主張するなら話は別だけど、それはナイト新字体
0813デフォルトの名無しさん2011/01/01(土) 18:08:49
>>809-810
組み込みの機能か否かの差だけで、svnの運用上一般的な概念としてブランチはあるだろうが。
0814デフォルトの名無しさん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)
　↓
0815デフォルトの名無しさん2011/01/01(土) 19:44:38
5. GUIやEclipseでの利用を重視しますか？
　│
　├(YES)→ Mercurialをおすすめします。TortoiseHgとMercurialEclipseの開発が進んでいます。
(NO)
　↓
6. シンプルな操作がお好みですか？
　│
　├(YES)→ Mercurialをおすすめします。チェンジセットの指定方法や管理方法が簡単です。
(NO)
　↓
Gitをおすすめします。高速で高度な管理機能が充実しています。Linux環境下のCLIでは安定した挙動になっています。
0816デフォルトの名無しさん2011/01/01(土) 19:46:45
>>814
> 　├(YES)→ Bazzarをおすすめします。ただし、特殊記号の取扱いが重要な場合は、Subversionを選択してください。
「が」が特殊記号？
0817デフォルトの名無しさん2011/01/01(土) 19:50:37
>>816
日本語でおk
0818デフォルトの名無しさん2011/01/01(土) 19:54:10
>>817
つ>>589
0819デフォルトの名無しさん2011/01/01(土) 20:55:54
>>817
同じUTF-8でも、NFC形式とNFD形式があって「が」のような平仮名キャラクタでも、異機種互換性が無いケースがある。
0820デフォルトの名無しさん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)
　↓
0821デフォルトの名無しさん2011/01/01(土) 21:15:48
5. GUIやEclipseでの利用を重視しますか？
　│
　├(YES)→ Mercurialをおすすめします。TortoiseHgとMercurialEclipseの開発が進んでいます。
(NO)
　↓
6. シンプルな操作がお好みですか？
　│
　├(YES)→ Mercurialをおすすめします。チェンジセットの指定方法や管理方法が簡単です。
(NO)
　↓
Gitをおすすめします。高速で高度な管理機能が充実しています。Linux環境下のCLIでは安定した挙動になっています。

（チェンジセット: 4:ae4c01d241ab）
0822デフォルトの名無しさん2011/01/01(土) 21:18:31
Bazzarの日本語ファイル名対応にがっかりきたし
今後期待できるMercurialでいいやｗ
0823デフォルトの名無しさん2011/01/01(土) 21:23:32
何を期待するんだ
0824デフォルトの名無しさん2011/01/01(土) 21:26:38
M$のお金で専業開発が可能になったMatt Mackallが、M$圧力でファイル名の国際化を実現することに期待。
0825デフォルトの名無しさん2011/01/01(土) 21:35:24
そういや、最近、svkの話題が全くないな。
0826デフォルトの名無しさん2011/01/01(土) 21:43:56
RCSよりは話題あるよ>>SVK
0827デフォルトの名無しさん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"
0828デフォルトの名無しさん2011/01/01(土) 21:52:41
>>827
git config --global core.quotepath false
0829デフォルトの名無しさん2011/01/01(土) 22:01:58
svkは間違った設計のいい例だったな。
0830デフォルトの名無しさん2011/01/01(土) 23:09:11
UTF-8-MAC問題はちゃんと認識されているんだから、あとはMacユーザーが
ちゃんとしたテストつきの修正をLaunchpadに登録してマージリクエストをだしたら
すぐにでも治る。
正規化以前にUnicodeファイル名に対応する気がそもそも無いhgよりはずっと
期待できそうだけど？
0831デフォルトの名無しさん2011/01/02(日) 00:01:10
世の中には方向性が予測できる故に生まれる期待と予測できない故に生まれる期待がある
0832デフォルトの名無しさん2011/01/02(日) 00:25:19
python 3系に移行する時に修正されないのかな？
そもそもは、pythonの文字列の扱いが糞なのが問題の出発点なんでしょ？
0833デフォルトの名無しさん2011/01/02(日) 00:53:10
>>832
過去にM$がまともな仕事をしてればunicodeに関する問題は
ここまで混乱は広がっていなかったと思われる
0834デフォルトの名無しさん2011/01/02(日) 01:34:39
>>799
githubぶっつぶしたいから

>>805
ひと括りに出来ない気がするな

Unicode対応という(目標)のはいいんだが
0835デフォルトの名無しさん2011/01/02(日) 01:40:34
>>811
gitのブランチはチェンジセットへのポインタで、場所を指しているだけと思っていたのだけど
違うのかな

何かブランチのメタ情報みたいなものをチェンジセットに含んでたりする？
0836デフォルトの名無しさん2011/01/02(日) 01:42:40
>>816-819
BazzarはUNICODE正規化してどのプラットフォームで共有させられるようにという
前人未到の領域に挑もうとしているんだぞ


おいそこ笑うな！
0837デフォルトの名無しさん2011/01/02(日) 01:45:58
>>832
対応する気がないというより、ファイル名はバイト列で扱う物という指針なら
Python3でも直されない気がするんだ

>>833
同時にMacもdsiってんじゃねーぞ
0838デフォルトの名無しさん2011/01/02(日) 01:53:06
>>836
>Bazzarは
>おいそこ笑うな！

zが多すぎる・゜。・(ノД`)・゜・。
0839デフォルトの名無しさん2011/01/02(日) 02:05:09
>>835
ブランチ間に依存関係が無いと言いたいのでは？
チェンジセットにブランチの情報が含まれていないから、あるブランチを消しても、他のブランチに影響が無い。
0840デフォルトの名無しさん2011/01/02(日) 02:37:50
>>837
Python3でも変えないって中の人が既に宣言してたと思う。
MSからの圧力でどうにかして欲しいな。
0841デフォルトの名無しさん2011/01/02(日) 02:52:09
BazzarとMercurialってどっちがいいの？
Mercurialで出来てBazzarで出来ない事ってある？
0842デフォルトの名無しさん2011/01/02(日) 02:56:12
>>841
Mercurialの方が、スペルを誤解されることが少ないようだ。
0843デフォルトの名無しさん2011/01/02(日) 02:58:10
Bazaarって濁音または半濁音を付けなければ日本語パスやファイルの扱いは完璧
よってBazaarが一番だな
0844デフォルトの名無しさん2011/01/02(日) 02:59:45
>>842
ハサーはにほんこはかんへき
0845デフォルトの名無しさん2011/01/02(日) 03:06:06
MACでバをハ゛にする変態はそうはいないだろｗ
0846デフォルトの名無しさん2011/01/02(日) 03:50:02
hgとgit
ファイル名以外のコメントとかで非ASCIIを使うのは
問題ないんだっけ？
0847デフォルトの名無しさん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でコミットメッセージを書いてくれるそうだ。
0848デフォルトの名無しさん2011/01/02(日) 05:12:31
Windows版のhg.exe, hgtk.exeは、UTF-8でコミットメッセージを書くよ。
0849デフォルトの名無しさん2011/01/02(日) 10:13:54
Bazzarって綴る人は発声する際もバッザーって呼んでるんだろうか
0850デフォルトの名無しさん2011/01/02(日) 14:21:56
>>837
指針を持つのはいいんだけど、Python自体のJoinメソッドの処遇なんか見比べると
なんか筋が通ってないように感じるなぁ・・・
なるようにしかならんのだろうけど
0851デフォルトの名無しさん2011/01/02(日) 15:00:29
mercurialのbranchは、ちょっと気持ち悪い。
bzrのように複数のcloneによって自然に生じるblanch。
gitの機能を取り込む為の、pointer型のblanch。
それにnamed/anonymous blanchが混在してしまうから。
0852デフォルトの名無しさん2011/01/02(日) 15:17:51
>>832,837
Python2もPython3も、ファイルシステムはUnicodeでもバイト列でも利用可能。

複数のエンコーディングが混じってる等がありえるUnix系で全てのファイル名に対応できる
バイト列のファイル名を使うか、WindowsでネイティブでUnix系でもエンコーディングが正しければ
大丈夫なUnicodeファイル名を使うかは、アプリケーションが選択する問題。
bzrはUnicodeを、Mercurialはバイト列を選んだだけ。

ちなみにPython3.1からは、Unicodeにデコードできないバイト列も扱えるような
サロゲートエスケープという方法が提供されていて、デコードできないファイル名を扱える。
0853デフォルトの名無しさん2011/01/02(日) 15:24:13
>>851
用語の定義の問題で、普通ブランチと言った場合、名前付きブランチのことを言う。
あとはリポジトリ・ヘッドと言えば大抵通じる。
他のVCSから来る人のために名無しブランチとか紹介されているだけ。
0854デフォルトの名無しさん2011/01/02(日) 15:42:10
> のbranchは
> 生じるblanch。
> のblanch。
> blanchが
なんで最初だけ正しいスペル？
何か意図があるのか
0855デフォルトの名無しさん2011/01/02(日) 15:50:27
>>852
ぶっちゃけ、英語の事しか考えてなかったのを
後から問いただされて「い、いや、混在してる場合もあるから」
って正当化しただけでしょ。
ML見れば分かる。

混在なんか滅多にないのに。
全か無かで考えるのは典型的な思考ロジックミス
0856デフォルトの名無しさん2011/01/02(日) 16:05:09
>>855
伝説のなんたらかんたらってやつ？
0857デフォルトの名無しさん2011/01/02(日) 17:37:40
基本バイト列で、オプションorプラグインで他文字コード対応というのがきれ
いに実現できれば受け入れられない訳ないと思うが、なぜかここではそれをあ
きらめてしまってる>>837みたいな書き込み多いよな
0858デフォルトの名無しさん2011/01/02(日) 17:54:17
bitbucketやdocutilsあたりも多言語関係はボロボロで泥縄に直してるから、
Pythonが元凶なんじゃねえの？
0859デフォルトの名無しさん2011/01/02(日) 18:01:16
もう面倒だから文字コードはIPv6アドレス互換に一本化しようぜ
0860デフォルトの名無しさん2011/01/02(日) 18:20:38
今昔文字鏡使おうぜ
0861デフォルトの名無しさん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。
0862デフォルトの名無しさん2011/01/02(日) 22:11:25
>>861
たぶん論点がちゃってる。
つか、VCS側はbyte列で十分、プラットフォーム側で会わせる問題じゃねぇのか？
0863デフォルトの名無しさん2011/01/02(日) 22:44:07
同じ言語で複数のコード体系があるのが、理解できないんじゃないだろうか。
しかも、コードが異なるとマッピングできない文字もあるし。
0864デフォルトの名無しさん2011/01/02(日) 22:45:57
>>862
どっちかが正解でどっちかが間違いって事はないだろ。
CVSで利用者のミスでSJISとEUCが混じったりして管理に苦労して、svnのUnicode対応を喜んでる
人だって確実にいる。
0865デフォルトの名無しさん2011/01/02(日) 22:49:26
>>863
そのレベルの話はもう時代遅れで、今はUnicodeに統一しても正規化や結合・分解文字の扱いで苦労している。

で、gitやhgって、NFCのUTF-8ファイル名をLinuxでコミットして、Macでチェックアウトしたら、
UTF-8-MAC問題で勝手に分解文字にリネームされたりしないの？
Macの問題はファイル名をバイト列で扱ったら解決できるような簡単な問題じゃないと思うんだけど。
0866デフォルトの名無しさん2011/01/02(日) 22:54:25
>>865
GitやMercurialのファイル名の文字コードは、このレベルの話だから困っているのでは？
0867デフォルトの名無しさん2011/01/02(日) 22:58:10
>>864
> CVSで利用者のミスでSJISとEUCが混じったりして管理に苦労して
ファイルの中身は？
VCSは改行の変換はするけど、文字コードの変換しないよね？
ファイルの中身がUTF-16というものもあるし
0868デフォルトの名無しさん2011/01/02(日) 23:04:20
Linuxをデスクトップとして使っていて、メールで送られてくるSJISファイル名のzipの扱いに苦労していた経験があれば、
git、hgのファイル名はたいした問題じゃない
0869デフォルトの名無しさん2011/01/02(日) 23:25:53
>>868
zipは展開したあとにconvmvするとか、どうにでもなる。
バージョン管理ソフトで継続的に管理するファイルのファイル名だから困るんだろ。
0870デフォルトの名無しさん2011/01/02(日) 23:31:37
というか比較対象にすらなってなくね？ｗ
0871デフォルトの名無しさん2011/01/03(月) 08:09:23
>>869
何が困るの？ファイル名を変換するなら、Makefileなどファイル名が書かれているもの全て変換しないと
辻褄合わないよね？
0872デフォルトの名無しさん2011/01/03(月) 08:27:08
>871
Makefileに書くような種類のファイルには、日本語ファイル名は使われない。
日本語ファイル名多用する現場であっても。

知ってるくせに。何でとぼけるの？
0873デフォルトの名無しさん2011/01/03(月) 08:30:00
>>872
日本語.dat、日本語.yamlを使っているところはあるぞ
0874デフォルトの名無しさん2011/01/03(月) 08:36:25
>>872
Javaのクラス名は日本語使わない？
0875デフォルトの名無しさん2011/01/03(月) 10:34:57
>>874
JavaならantとかMavenとかだろ。Makefileと違って設定ファイルがxmlで、設定ファイルの
エンコーディングとファイルシステムのファイル名のエンコーディングが違ってても大丈夫。

>>873
そういう事をするのは、実行環境が限られている、非ポータブルなMakefileだけだろ。
それならUnicodeでもバイト列でも問題ない。

実際、svnはUnicodeでファイル名を扱っているけど、長年デファクトスタンダードとして
利用されてきた。
今分散型に押されているのはコミット権が無いとブランチが作れなかったり
オンラインじゃないと作業できなかったりマージが弱かったりするからであって、
ファイル名をUnicodeで扱うからじゃない。（ちなみにマージは改善されたし
ローカルコミット・ブランチも開発中らしい）
0876デフォルトの名無しさん2011/01/03(月) 10:53:33
>>875
> >>874
> JavaならantとかMavenとかだろ。Makefileと違って設定ファイルがxmlで、設定ファイルの
> エンコーディングとファイルシステムのファイル名のエンコーディングが違ってても大丈夫。
本当か？
xmlはutf-8と定義してあるのに、ファイル名がEUC-JPで書かれていても問題ないのか？
パセーントエンコードしないと不整合だぞ

0877デフォルトの名無しさん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 が違う環境で動かなくなる恐れがある。
0878デフォルトの名無しさん2011/01/03(月) 11:49:03
そろそろツールを１つにまとめようか
0879デフォルトの名無しさん2011/01/03(月) 12:08:19
今どき ja-JP.euc_JPなんてゴミ環境無視していいよ。

それよりUnix/LinuxのUTF-8とWindowsでまともに動かすにはどうすればいいか考えようぜ。
NFCなりNFDなりはその次のステップだ。
0880デフォルトの名無しさん2011/01/03(月) 12:13:00
>>879
それはbzrとsvnはデフォで対応しているし、gitやhgはutf-8 cygwin使ってutf-8に統一すればおｋだろ
0881デフォルトの名無しさん2011/01/03(月) 12:16:19
>>879
> 今どき ja-JP.euc_JPなんてゴミ環境無視していいよ。
君はLatin-Nの人に同じことを言えるか？
0882デフォルトの名無しさん2011/01/03(月) 12:48:32
> 君はLatin-Nの人に同じことを言えるか？

えー今でもLatin-1なのｗ
UTF-8で全部包含してるからen_US.UTF-8にしなよｗ
なに？「俺の読めない漢字が入ってるJIS2004ケシカラン」とかいう人？
0883デフォルトの名無しさん2011/01/03(月) 12:49:53
>>882
ということをLatin-1の人と英語で議論できるか？
0884デフォルトの名無しさん2011/01/03(月) 13:25:35
議論はできるが論破できる自信はないなｗ
0885デフォルトの名無しさん2011/01/03(月) 13:41:15
できるというレスなら頑張ってって応援しようと思ったのに。
英米人だけでなく、ヨーロッパ大陸の人でもLatin-1で十分と思っているからね。
そもそも、Latin-1とUTF-8の区別が付いているかどうかも疑問。
日本人は化け方でJISかEUCかSJISか分かっちゃうけど、
Latin-1の人は文字化けの経験があるのだろうか、と思ってしまう。
0886デフォルトの名無しさん2011/01/03(月) 14:02:39
とりあえず日本語が化けなければいいよ
0887デフォルトの名無しさん2011/01/03(月) 15:34:47
Subversionはソースコードに特化した一般ファイルの管理には向かないバージョン管理システム
だったからファイル名がUnicodeに限定されていても問題がなかっただけでしょ

今時のバージョン管理システムは一般ファイルのバージョンを管理するバックエンドとしての用途
も視野に入っているから今更Subversionの時代にまで退化しろと言われてもちと困る
0888デフォルトの名無しさん2011/01/03(月) 15:35:55
・・・は？
0889デフォルトの名無しさん2011/01/03(月) 15:41:11
SVNは個々のディレクトリ・ファイルをチェックアウトできることからも分かる通り、
個々のファイルのリビジョンしか管理しないCVSにちょびっと毛が生えた程度。
0890デフォルトの名無しさん2011/01/03(月) 15:48:50
>>887
> Subversionはソースコードに特化
・・・
何を見てそう思ったの？
0891デフォルトの名無しさん2011/01/03(月) 15:56:48
>>887
gitもhgもファイルのタイムスタンプその物は保存しない。
（svnは論外にしても）一般ファイルのバージョン管理に向いてるとはとても思えない。
0892デフォルトの名無しさん2011/01/03(月) 16:04:59
>>891
ファイルじゃなくてチェンジセットなの
だから個々のファイルのタイムスタンプは意味ないの
タイムスタンプもgitとhgはrebase、hgはMQを使えば時間順には並ばない
0893デフォルトの名無しさん2011/01/03(月) 16:48:19
>>892
個々のファイルのタイムスタンプを保存しないのは、チェンジセットとは関係ない。
VCSに個々のファイルのタイムスタンプを以前の状態に戻されると、makeが混乱するので却って
邪魔になるというのが元々の理由。
世代管理可能なバックアップツールであれば、個々のファイルのタイムスタンプも保存して元に
戻すのが当然だが、VCSであるsvn/git/hgは個々のファイルのタイムスタンプを保存しない。
よって、gitやhgが一般ファイルの管理にも向いているという >>887 の意見には同意できないと
主張しているだけ。
0894デフォルトの名無しさん2011/01/03(月) 16:53:34
>>887
> Subversionはソースコードに特化した一般ファイルの管理には向かないバージョン管理システム
ちょっとわかりづらいな。
一般ファイル以外だとシンボリックリンクとかのイメージなんだが。
0895デフォルトの名無しさん2011/01/03(月) 17:06:46
>>887
分かってて言ってるとは思うけど
Subversionはバイナリを扱うのが得意なのが特徴の1つなのだけど
0896デフォルトの名無しさん2011/01/03(月) 17:25:34
>>891
VCS でファイルのタイムスタンプを保存されてうれしいことでもあるのか？
VCS まともに運用できないおっさんの屑管理者か?
08978912011/01/03(月) 17:57:39
>>896
>>891 = >>893 ぐらいは察してくれ。
0898デフォルトの名無しさん2011/01/03(月) 19:31:44
>>887
Subversionって、WebDAVで一般ファイルのバージョンを管理するバックエンドとして開発が始まったんじゃなかったっけ。
0899デフォルトの名無しさん2011/01/03(月) 20:27:42
>>887
>Subversionはソースコードに特化した一般ファイルの管理には向かないバージョン管理システム

なにを根拠にいってるのかな？

>>893
>個々のファイルのタイムスタンプを保存しないのは、チェンジセットとは関係ない。

ですよねー
0900デフォルトの名無しさん2011/01/04(火) 01:40:49
>>759
いやそのblogの人に。
0901デフォルトの名無しさん2011/01/04(火) 08:44:03
エクスポートしてアーカイブするときだけだな、タイムスタンプを再現して欲しいと思うのは。
0902デフォルトの名無しさん2011/01/04(火) 13:58:28
このスレにはタイムスタンプに執着してる奴はいないみたいで楽だけど、
ファイルのタイムスタンプを絶対視するヴァカは世の中に一杯いる。
特に窓ユーザには多いようだ。
タイムスタンプ信者に限ってTortoiseSVN使ってたりするし。
Subversionはこういうヴァカも大勢相手にしなきゃいけないから大変だよ。
0903デフォルトの名無しさん2011/01/04(火) 14:17:01
VCSの知識なしにファイルの履歴管理したいと思ったら
タイムスタンプに頼らざるを得ないからな
0904デフォルトの名無しさん2011/01/04(火) 22:40:02
履歴管理なんて簡単。

src_20110104_copy3b_ver12_yamada_c.zip

0905デフォルトの名無しさん2011/01/04(火) 22:46:49
>>901
なんで？
TAG辺りをversion.hだかなんだかに放りこんどけばええんちゃう？
あとはdiffって下さいですまへんか？
0906デフォルトの名無しさん2011/01/04(火) 23:21:53
>>905
配布パッケージをつくるときは、各ソースモジュールのタイムスタンプが
last committed time になってる方がかっこよくないか? という私見。
つか git はどーだったか忘れたが、cvs, svn はそうなってた IIRC
0907デフォルトの名無しさん2011/01/05(水) 00:59:55
>>906 なるほどね
ずっと昔から、個人的に、タイムスタンプなんて信用しないからなぁ
# touch されたらその場でアウト
0908デフォルトの名無しさん2011/01/05(水) 16:23:05
makeやantは時間管理。
0909デフォルトの名無しさん2011/01/05(水) 16:26:56
make clean
0910デフォルトの名無しさん2011/01/05(水) 16:29:32
未来からのメールよこす奴はいっぱいいるぞ
0911デフォルトの名無しさん2011/01/05(水) 16:59:44
>>908
だからこそ VCS から取り出したファイルは、たとえ昔のリビジョンでも
常に最新のタイムスタンプである必要がある。
0912デフォルトの名無しさん2011/01/05(水) 21:57:02
>>902
> タイムスタンプ信者に限ってTortoiseSVN使ってたりするし。
どういうこと？コマンドラインとtortoiseでタイムスタンプの扱いが違うの？
0913デフォルトの名無しさん2011/01/05(水) 22:02:51
変更してコンパイルした。やっぱ思い直してrevertした。
タイムスタンプ戻ったらmakeが困るぞ。
0914デフォルトの名無しさん2011/01/05(水) 22:34:44
そういう時のためにtouchがあるんじゃないか
0915デフォルトの名無しさん2011/01/05(水) 23:26:14
タイムスタンプ変わっていいのかよ。ｗ
0916デフォルトの名無しさん2011/01/06(木) 00:37:35
>>912
そうじゃなくて、タイムスタンプ信者に一定の偏りがあるんじゃないかってこと。
なんつうか...まぁ、誤解を恐れずに言うと
「Windows/GUIマンセー」「CUIクソ!」な奴に多い...みたいな。
0917デフォルトの名無しさん2011/01/06(木) 01:31:59
タイムスタンプを保存して欲しいという要望自体は真っ当だな
Sconsユーザでもないお前はまともな説明能力が無いからタイムスタンプ信者とレッテル貼って逃げてるだけだろ
makeの挙動でも勉強してから出直してこい
0918デフォルトの名無しさん2011/01/06(木) 01:50:35
タイムスタンプ勝手にいじられても気持ち悪いだけだと思うんだが。
0919デフォルトの名無しさん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
0920デフォルトの名無しさん2011/01/06(木) 09:34:54
それはタイムスタンプを保存しない理由じゃなくてタイムスタンプを勝手に戻さない理由
実際には勝手に戻さなくても保存しようとするだけでいくつかの問題が発生する
自分の頭でほんの少し想像力を働かせれば何が問題になるかはすぐ分かるはずなんだがな
0921デフォルトの名無しさん2011/01/06(木) 09:38:38
パフォーマンスと容量以外の問題があるならぜひ教えて欲しいです
0922デフォルトの名無しさん2011/01/06(木) 09:57:23
このスレでも既出だぞ？
それだけが問題ではないけどな
0923デフォルトの名無しさん2011/01/06(木) 15:29:54
>>920は自分の想像力が不足しているので、他の人に説明して欲しいらしい。
0924デフォルトの名無しさん2011/01/06(木) 18:25:58
ひょっとして未成年だったのかな？　だとしたら申し訳ない
このスレで既出の問題は200番台に書いてあるから見てみるといい
このスレで既出じゃない問題の例としては例えば時刻分解能に起因した問題があるが他にもあるよ
若いうちからバージョン管理システムの使い方を勉強してるなんて偉いなあ
後からきっと役にたつから頑張れ
0925デフォルトの名無しさん2011/01/06(木) 19:36:55
タイムスタンプ信者の>>920がキモい
0926デフォルトの名無しさん2011/01/06(木) 21:43:02
若いうちからバージョン管理システムなんか使うと駄目になる。
0927デフォルトの名無しさん2011/01/06(木) 21:49:34
若いうちから日本語ファイル名なんか使うと駄目になる。
0928デフォルトの名無しさん2011/01/07(金) 06:14:19
若いうちから2chなんか見ると駄目になる。
0929デフォルトの名無しさん2011/01/08(土) 15:35:30
更新時刻も重要なファイルのメタデータのひとつだろうに。バージョン管理といえばmakeしか思い浮かばないヤツはどんだけ視野が狭いんだ。
PC内の全ファイルの更新時刻がOS起動時刻に変わっても文句言わないのかね。

Perforceはmtimeも保存するらしいけど、本当かな
0930デフォルトの名無しさん2011/01/08(土) 16:05:05
>>929
時間が全く合っていないマシンのネットワークドライブはどうする？
0931デフォルトの名無しさん2011/01/08(土) 16:15:59
確かにコミット時刻は重要な情報だ。
0932デフォルトの名無しさん2011/01/08(土) 16:28:44
git commit --date='2000-01-01'
0933デフォルトの名無しさん2011/01/08(土) 17:08:11
これだからgitってやつは
0934デフォルトの名無しさん2011/01/08(土) 18:25:44
>>929はどのバージョン管理システムを使っているの？
0935デフォルトの名無しさん2011/01/09(日) 04:36:11
>>930
うるせえ時刻合わせろチンカス
0936デフォルトの名無しさん2011/01/09(日) 11:00:03
バージョン管理といえばmakeを思い出す人なんていたっけか
0937デフォルトの名無しさん2011/01/09(日) 11:24:55
いつから make がバージョン管理ツールになったか教えてほしいもんだ
0938デフォルトの名無しさん2011/01/09(日) 12:09:44
>>932 のコマンドはMercurialでも使えるね。知らなかったがこりゃ便利。
0939デフォルトの名無しさん2011/01/09(日) 13:08:38
>>937
make dist
0940デフォルトの名無しさん2011/01/09(日) 13:55:24
>>937
そもそも dist って make の組み込みターゲットだったけか？
通常、配布パッケージつくるのが dist のお仕事ではなかったかと？
で、中で SCCS とか RCS とか…
0941デフォルトの名無しさん2011/01/09(日) 15:55:07
hoge-x-y-z.tar.gzのx-y-zはバージョンだからバージョン管理
0942デフォルトの名無しさん2011/01/09(日) 18:09:31
日本で最も普及してるバージョン管理ツールは、LHA
0943デフォルトの名無しさん2011/01/10(月) 15:09:21
Makefileのdistターゲットが一般化したのってautotools以降だよ。
autotools使わない人もdistターゲットを作るべきなんてルールもない。
まあ便利だけど。
0944デフォルトの名無しさん2011/01/13(木) 20:45:58
SourceForge.JP、個人向けGitリポジトリ/ストレージサービス「PersonalForge」をリリース
http://sourceforge.jp/magazine/11/01/13/0234231
0945デフォルトの名無しさん2011/01/14(金) 19:52:18
>>758
http://anlyznews.blogspot.com/2011/01/bazaarsvn.html
0946デフォルトの名無しさん2011/01/18(火) 03:58:44
>>944
Git採用ということは、Windowsで開発するな、ってことですかね…
0947デフォルトの名無しさん2011/01/18(火) 04:06:24
>>946
はぁ？
0948デフォルトの名無しさん2011/01/18(火) 04:41:08
あーそうか
ファイル名に日本語使わなければ問題は起きないのか
どうせソースを管理するだけだからこの場合問題は無いのですね
この手の開発する人が日本語ファイル名を使うわけもないし
失敬失敬
0949デフォルトの名無しさん2011/01/18(火) 04:49:53
あーそうか
ファイル名に「が」を使わなければ問題は起きないのか
どうせソースは管理しないからBazaarでも問題は無いのですね
ファイルに日本語ファイル名を使う人は英語を読めないし
失敬失敬
0950デフォルトの名無しさん2011/01/18(火) 05:07:07
大事なことなので(ry
0951デフォルトの名無しさん2011/01/18(火) 07:09:46
MercurialとEclipseが楽。
0952デフォルトの名無しさん2011/01/18(火) 07:28:06
あーそうか
ファイル名に「か゛」を使わなければ問題は起きないのか
と゛うせソースは管理しないからBazaarて゛も問題は無いのて゛すね
ファイルに日本語ファイル名を使う人は英語を読めないし
失敬失敬
0953デフォルトの名無しさん2011/01/18(火) 08:30:01
>>952 「ば」
0954デフォルトの名無しさん2011/01/18(火) 09:07:13
残念すぎる出来
0955デフォルトの名無しさん2011/01/18(火) 09:22:01
>>944
githubの個人主体のパクリなんだろうけど、容量制限があるのかが分からない。
BTS・wikiのあるgithubからわざわざ移ってくる人はまずいないだろう
0956デフォルトの名無しさん2011/01/18(火) 09:55:09
>>944
同じ終わコン同士Bazaarやれば良かったのに
0957デフォルトの名無しさん2011/01/18(火) 10:29:34
>>949 >>952
OS X使うなよ。
0958デフォルトの名無しさん2011/01/18(火) 12:30:09
>>957
BazaarはMacOSX以外ではNFDを扱えるのか？
0959デフォルトの名無しさん2011/01/18(火) 13:36:28
>>958
LinuxとWindowsだけ使っておけよ。
0960デフォルトの名無しさん2011/01/18(火) 16:10:43
>>952はNFDを勘違いしてるな。
独立した濁点と合成用の濁点は別のコードポイントが割り振られてるぞ。
問題になるのは合成用の濁点で、独立した濁点については何の問題もない。
0961デフォルトの名無しさん2011/01/18(火) 16:39:31
あーそうか
ファイル名に「かU+3099」を使わなけれはU+3099問題は起きないのか
とU+3099うせソースは管理しないからBazaarてU+3099も問題は無いのてU+3099すね
ファイルに日本語ファイル名を使う人は英語を読めないし
失敬失敬
0962デフォルトの名無しさん2011/01/18(火) 17:17:52
>>960は>>952を勘違いしてるな。
問題を起こさない為に日本語はこう書きましょうと言ってるんだろ。
0963デフォルトの名無しさん2011/01/18(火) 19:10:09
>>857
諦めてはないよ。自分からパッチ書く気がないだけで。

> 基本バイト列で、オプションorプラグインで他文字コード対応というのがきれ
> いに実現できれば受け入れられない訳ないと思うが、

現状で問題になっているWindowsでもcygwinを使えば、かなり綺麗に文字コード対応が実現できているんだが
ここでは受け入れられているようには見えないんだよな
cygwinを入れるのは簡単なのにな

Macにもcygmacがあれば解決できるなｗ
0964デフォルトの名無しさん2011/01/18(火) 19:16:10
正確には書く気がないじゃなくて、書けないだった。思わせぶりな書き方はよくない、反省
0965デフォルトの名無しさん2011/01/18(火) 19:28:02
お前らマルチプラットフォームのそれこそiPhoneだろうがAndroidだろうがMac OS Xだろうが
ちゃんと日本語対応できているDropboxも参考にしろや

素人向けのバージョン管理もできるツールが対応度が高いのもどんだけ
0966デフォルトの名無しさん2011/01/18(火) 19:46:45
素人向けの方がクオリティが高いのは当たり前じゃん
0967デフォルトの名無しさん2011/01/18(火) 19:51:13
Dropboxにその日の成果を"日付.zip"で上げてバージョン管理
0968デフォルトの名無しさん2011/01/18(火) 20:56:28
去年くらいにDropboxで一部のデータが消えたという事件があったばかりだろ
0969デフォルトの名無しさん2011/01/18(火) 21:46:58
>>968
無いだろ？
0970デフォルトの名無しさん2011/01/18(火) 23:43:09
>>963
パッチ書けなくても英語で議論すればいいだろ
Cygwinで困ってないなら別にいいけど
0971デフォルトの名無しさん2011/01/18(火) 23:59:22
msysgitのパッチなら進展しているんですけど
http://code.google.com/p/msysgit/issues/detail?id=80
0972デフォルトの名無しさん2011/01/19(水) 00:43:34
>>963
> 現状で問題になっているWindowsでもcygwinを使えば、かなり綺麗に文字コード対応が実現できているんだが
> ここでは受け入れられているようには見えないんだよな
> cygwinを入れるのは簡単なのにな

cygwinでutf-8が使えることを受け入れるとBazaarの存在意義が無くなるから
0973デフォルトの名無しさん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と似たような用途のようなのに、長期開発向けだったりますます意味がわかりません。
0974デフォルトの名無しさん2011/01/19(水) 03:51:26
いま眠いので朝返事する
0975デフォルトの名無しさん2011/01/19(水) 07:28:46
>>973
昔はrebaseとtransplant(gitのcherry-pickに相当)拡張が無かったけど、MQがあれば何でもできた。
逆に今でも、MQを使えばrebase・transplantを使わなくても同様のことはできる。
0976デフォルトの名無しさん2011/01/19(水) 07:33:00
>>973
> ブランチを切ったり切り替えたりするコストは格段に低いですよね？
> 何故ちょっとしたブランチを切って、そのパッチを当てたり、マージしたりといった既存の操作をすててまで、
> わざわざ新しい概念や操作を持ち出してMQを使うのでしょうか？

gitがrebase主義の所とそうで無い所があるように、hgでもなるべく履歴をきれいにしたい、という所は多いと思う。
名前付きブランチが昔はclose出来なかったので、コストが高かった。
bookmark拡張のpull/push出来る機能も今ひとつ使い勝手が悪い。
0977デフォルトの名無しさん2011/01/19(水) 07:37:53
>>973
Mercurial本体やTortoiseHgのログを眺めていると時間順に並んでいないのがあるのに気付くと思う。
これは大抵MQを使っている。
0978デフォルトの名無しさん2011/01/19(水) 07:56:37
>>973
gitとの比較で、hgはローカルブランチが無いというのがある。
リビジョン・名前付きブランチ名を指定してpushすればgitのローカルブランチみたいなこともできる。
この目的にもbookmark拡張が使えるけど、普通のチェンジセットにしちゃうと、
どれが実験的・デバッグ的なチェンジセットなのか見分けがつきづらくなる。
でもMQを使っておけば、pushして良いものと、まだダメなものの見分けがつきやすい。
0979デフォルトの名無しさん2011/01/19(水) 08:08:38
>>973
選択肢の問題で、

・不要なブランチを消したい
・チェンジセットをまとめたい
・別ブランチの一部のチェンジセットだけマージしたい
・ローカルではパッチをあてて作業したい（共有リポジトリ版と設定部分を変えたい）

と言うような要望が無い人には、拡張機能MQは要らない。
0980デフォルトの名無しさん2011/01/19(水) 08:12:53
>>973
職場で毎日コミットするルールがあるとして、ある機能の実装に5日間かかるとする。
5回コミットされるが、5つのチェンジセットを同時にマージしないと原子性が満たされない。
また4日間分のコミット・メッセージは「#12345機能の実装途中」であり、情報としては意味が無い。
こういう時に、チェンジセットをまとめたいという要望があるのは自然だ。
0981デフォルトの名無しさん2011/01/19(水) 08:13:34
>>973
　　　　　　　　　＼　　　∩─ｰ､ 　　　====
　　　　　　　　　　 ＼／　●　､_ ｀ヽ 　　======
　　　　　　　　　　　/ ＼(　●　 ● |つ
　　　　　　　　　　　|　　 X_入__ノ 　 ミ　　　そんな餌で俺様が釣られクマ――
　　　　　　　　　　　 ､　(＿／　　　ノ　/⌒l
　　　　　　　　　　　 /＼＿＿＿ノﾞ＿/　 /　　=====
　　　　　　　　　 　 〈　　　　　　　　 ＿_ノ　　====
　　　　　　　　　　　 ＼　＼＿　　　　＼
　　　　　　　　　　　　　＼＿__）　　　　　＼　　　======　　　(´⌒
　　　　　　　　　　　　　　　　＼　　 ＿＿_ ＼＿＿　　(´⌒;;(´⌒;;
　　　　　　　　　　　　　　　　　 ＼＿＿＿）＿＿＿）(´;;⌒　 (´⌒;;　　ズザザザ
09829732011/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とは状況が全く違っていたようですね・・・
0983デフォルトの名無しさん2011/01/19(水) 15:14:39
>> ブランチを切ったり切り替えたりするコストは格段に低いですよね？
>というのをgitを使っていたときの感覚で言ってしまったのですが、

ブランチを切る手間が問題なのではない。
Gitにもgit-resetや、git-cherry-pick、git-merge --squash、guiltがある。
0984デフォルトの名無しさん2011/01/20(木) 03:53:27
>>980 職場で毎日コミットするルールがあるとして、ある機能の実装に5日間かかるとする。

これって、未完成でもコミットしなきゃいけないってことなの？
時間切れでビルドできない状態でも「毎日コミットする」ルールなんて、有害だよ？

ある機能の実装が完了してからコミットすれば良いんでは？
0985デフォルトの名無しさん2011/01/20(木) 04:21:22
>>984
Subversionについて言っている？
デスクトップPCが５日目で壊れたらどうする？
いざコミットしようとしたらコンフリクトしたらどうする？
gitならmerge --squash、hgでもMQのqfoldやらいろんな手段の方が安全では無いか？
0986デフォルトの名無しさん2011/01/20(木) 04:59:31
>>984
> 時間切れでビルドできない状態でも「毎日コミットする」ルールなんて、有害だよ？

Mercurialだと、ビルド不可能なチェンジセットの存在は開発の阻害にならない。つまり、
・他の人はビルドできるバージョンに戻って、コミットするだけで無名ブランチが切れる。
・SVNの2-waysマージとは違い、3-waysマージが賢いので無名ブランチのマージは怖くない。

また、編集者がローカル・リポジトリに無闇にコミットをしても、共有リポジトリへpush前に拡張機能MQでコミットの統合ができる。
つまり、コミット必須は有害なルールとも言えなくなる。

SVNでは、管理者がブランチを切りマージ性能も低いため、ビルド可能や、テスト完了済みバージョンのコミットが必須になっているだけ。
0987デフォルトの名無しさん2011/01/20(木) 05:20:47
>>984
ビルドに１日かかるとしてコミットするのに１日待たないといけないの？
make clean しないでmakeだけでビルドが通るって言っているの？
Subversionの作業フォルダでmakeが通っても、他の所でmakeが通らなかったら、
コミッタが血祭りにあげられるの？
0988デフォルトの名無しさん2011/01/20(木) 06:59:19
すらっと流しているけど
>他の人はビルドできるバージョンに戻って、

どうやってビルド可能なバージョンを「知る」の？
まさかいろんなバージョンをとっかえひっかえ？

管理システムの外に、もう一つ管理システムがないと実質対応できないじゃないか？
0989デフォルトの名無しさん2011/01/20(木) 08:01:09
>>984
Team Foundation Serverだと、そういう場合はシェルブ機能が使えるね。
コミットはしたくないけどサーバーには上げておきたい時にシェルブを使う。

Subversionでも1.8あたりで実装予定じゃなかったっけ？
0990デフォルトの名無しさん2011/01/20(木) 08:25:52
ついに、Team Foundation Serverを使った事のある奴が現れた！
0991デフォルトの名無しさん2011/01/20(木) 08:44:10
>>988
フックでビルド叩くツールかませばいい
それが成功したら、Bazaarでいうメインなんたらってのにpushすればいい
0992デフォルトの名無しさん2011/01/20(木) 09:50:19
機能が未完成≠コンパイルできない

0993デフォルトの名無しさん2011/01/20(木) 10:09:36
なんか見えない前提がいろいろ設定されているようだ
0994デフォルトの名無しさん2011/01/20(木) 10:14:41
毎日コミットするルールがある職場って人間関係が崩壊してそうだな
0995デフォルトの名無しさん2011/01/20(木) 10:49:47
作業の記録として重要。進捗の確認。担当に事故があった場合にも引継ぎが楽。
0996デフォルトの名無しさん2011/01/20(木) 11:10:07
それ以前に必要な会話すらできてないから毎日コミットするなんていうルールを
作っちゃうって気がする
0997デフォルトの名無しさん2011/01/20(木) 11:24:03
ま、会話しても話が通じないんだけどね。
0998デフォルトの名無しさん2011/01/20(木) 11:43:46
CVS/Subversionでコミット前にレビューするというルールの所は
そんな不完全な状態でレビューして何の価値があるのか聞きたい
0999デフォルトの名無しさん2011/01/20(木) 11:58:04
コミットしたからって完成度が上がるわけじゃないだろう
1000デフォルトの名無しさん2011/01/20(木) 12:07:08
1000
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。