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


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

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



1 名前:前スレ858=879 mailto:sage [2010/09/06(月) 22:48:42 ]
バージョン管理システムについて再び語りましょう

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

●関連スレ
CVS 1.3 [UNIX板]
pc12.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ〜 Rev.3 [プログラム板]
hibari.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
pc11.2ch.net/test/read.cgi/linux/1154701996/
Subversion r12 [プログラム板]
hibari.2ch.net/test/read.cgi/tech/1254838551/
git スレッド [Linux板]
hibari.2ch.net/test/read.cgi/linux/1197798039/
【分散型バージョン管理】 Mercurial 【hg】
hibari.2ch.net/test/read.cgi/tech/1251208950/
【bzr】Bazaarでバージョン管理 Rev 2
hibari.2ch.net/test/read.cgi/tech/1265951333/


357 名前:353 [2010/10/25(月) 07:29:02 ]
用語もわからなくて質問してすいません。

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

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

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

358 名前:デフォルトの名無しさん mailto:sage [2010/10/25(月) 07:33:56 ]
>>357
ここに行け
hibari.2ch.net/test/read.cgi/linux/1154701996/

359 名前:デフォルトの名無しさん [2010/10/25(月) 13:59:49 ]
バージン管理システムに見えた

360 名前:デフォルトの名無しさん mailto:sage [2010/10/27(水) 20:10:38 ]
Gitを統合した「KDevelop 4.1」がリリース
sourceforge.jp/magazine/10/10/27/0315212

361 名前:デフォルトの名無しさん mailto:sage [2010/10/27(水) 21:41:00 ]
>>359
最近は過去の改竄しまくりで、けしからんな

362 名前:デフォルトの名無しさん mailto:sage [2010/10/28(木) 00:43:16 ]
>>361
前彼女の履歴から俺のコミットがロールバックされていた件

363 名前:デフォルトの名無しさん mailto:sage [2010/10/28(木) 00:50:29 ]
revertならまだ望みはある

364 名前:デフォルトの名無しさん mailto:sage [2010/10/28(木) 12:48:35 ]
別の誰かの記憶にマージされていた

365 名前:デフォルトの名無しさん mailto:sage [2010/10/28(木) 14:19:02 ]
お前ら二人とも愛してやる!
fast-forwardだ!



366 名前:デフォルトの名無しさん mailto:sage [2010/10/28(木) 15:19:20 ]
VS2010で扱いやすいバー管おしえてください

367 名前:デフォルトの名無しさん [2010/10/28(木) 15:47:27 ]
>>366
Mercurial Source Control Plugin for MS Visual Studio
visualhg.codeplex.com/

368 名前:デフォルトの名無しさん mailto:sage [2010/10/28(木) 15:57:16 ]
>>366
VS2010で扱いやすいのはVSSじゃないかな
使ってる人間が扱いやすいかは別にして

369 名前:デフォルトの名無しさん mailto:sage [2010/10/28(木) 16:08:12 ]
>>366
Git Extensions
code.google.com/p/gitextensions/
> Git Extensions is a toolkit to make working with Git on Windows more intuitive.
> The shell extension will intergrate in Windows Explorer and presents a context menu
> on files and directories. There is also a Visual Studio plugin to use git from Visual Studio.

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

370 名前:デフォルトの名無しさん mailto:sage [2010/10/28(木) 16:50:33 ]
なんで何でもかんでも合体せにゃならんのか。

371 名前:デフォルトの名無しさん mailto:sage [2010/10/28(木) 18:36:29 ]
>>367
俺はVisualHGよりは、hgsccの方が好きだな。
でも、両者をチェックしたのは1年以上前だから、今は状況が変わってるかもしれないが。
当時はVisualHGは低機能すぎてイマイチだった。

372 名前:デフォルトの名無しさん mailto:sage [2010/10/28(木) 23:56:34 ]
お手軽で普通に使えるので俺はVisualHGのほうがオススメ。

373 名前:デフォルトの名無しさん mailto:sage [2010/10/29(金) 01:19:21 ]
>>370
>>366じゃないがIDEやエディタに統合すると便利よ
リアルタイムに変更箇所表示してくれたり、TortoiseXXXみたいにアイコンファイルビューで状態を表示してくれたり


374 名前:デフォルトの名無しさん mailto:sage [2010/10/29(金) 01:31:03 ]
>>370が言ってるのは、コマンドをパイプで繋げてお手軽にオレスゲーが出来なくなるのが問題だって事じゃないの

375 名前:デフォルトの名無しさん mailto:sage [2010/10/29(金) 03:19:39 ]
>>368
MSはTFSに乗り換えて欲しいようだが



376 名前:デフォルトの名無しさん mailto:sage [2010/10/29(金) 08:49:39 ]
>>374
Emacsはデスクトップ環境だそうだが、
GNU EmacsがBazaar、XEmacsがMercurialなんだね。

377 名前:デフォルトの名無しさん [2010/11/04(木) 20:10:45 ]
Subversionスレから誘導されて来ました。

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

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

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

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

378 名前:デフォルトの名無しさん mailto:sage [2010/11/04(木) 20:21:14 ]
>>377
・Subversionのフォルダ単位の分散型のミラーを立てる
・Subversionにpush時に一本道になるように履歴を整える

379 名前:デフォルトの名無しさん mailto:sage [2010/11/04(木) 23:03:52 ]
>>377
Mercurialではじめる分散構成管理
第5回 分散による「多段連携」 〜 大規模開発への応用
gihyo.jp/dev/feature/01/mercurial/0005?page=1

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

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

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

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

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

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

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

381 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 00:37:38 ]
追記

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

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


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







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

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

383 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 00:48:38 ]
Dropbox を入れるデメリットは無視ですかそうですか

384 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 00:55:11 ]
>>380-381
そのような状況なら、自分のブランチと共同作業員のブランチを用意して
共同作業員のブランチも貴方(もしくはプログラマ)が管理すればいい

385 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 00:59:18 ]
>>380-381
Trac、Redmineを立てなくても、
5人まで無料で無制限でプライベートリポジトリが持てて、wikiとBTSが付いているbitbucketが良いんじゃね



386 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 01:39:06 ]
コンフリクトする度にぶち切れて暴れてみせれば、デザイナの方から
バージョン管理システム導入しようって言ってくると思うよ。

387 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 01:43:31 ]
>>386
それいいなw って思ったけど、デザイナの人ってそういうの気にしなーいんだよね…

388 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 04:04:37 ]
そんなの人の問題
ブチ切れ方が足りない
「俺のファイルを上書きするんじゃねぇ」とキーボードぶん投げてやれば
バージョン管理の導入に同意してくれるだろ


389 名前:デフォルトの名無しさん [2010/11/06(土) 05:44:58 ]
>>386-387
ぶちきれても無駄
そんなことするより
こっちからコンフリクト上書きして
デザイン壊してやればいい



390 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 05:59:24 ]
>>380
デザイナーを変えればいいんじゃね?

391 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 06:56:49 ]
社内リポジトリを公開せずに、社外のコントリビューター(ヘルプ、ドキュメント、アイコン、その他、主に非プログラム関連)の
ファイルをバージョン管理するのなら、一番簡単なのは社内の人間を一人貼り付ける。代行チェックイン/アウト。

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


392 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 12:30:41 ]
バージョン管理面倒くさいとか言ったら、次の仕事は頼まないからってなことを匂わす

393 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 14:05:14 ]
あー同僚のデザイナーにもおるわ、意地でもsvn使わん奴。もう死ねよ

394 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 14:13:03 ]
そんな屑クビにしろよw


395 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 14:41:42 ]
バージョン管理のノウハウ的な所についての入門とか手引きは見当たらないけど、
皆どうやって覚えてるんだ?
誰もが習うより慣れろで問題ないというわけでなし。



396 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 14:47:47 ]
いろいろ書籍出てるけど?

397 名前:デフォルトの名無しさん [2010/11/06(土) 14:56:08 ]
書籍「Dropboxで楽々バージョン管理」
・コミットなどの専門用語とは、おさらば
・ブランチ、マージは必要無し


398 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 18:23:36 ]
近所にいくら勧めてもバージョン管理使わないチームがいてな
いつも、上書きしたとか機能を変更したとか勝手に変えるなとかチーム内でけんかばっかりしている連中がいる。

399 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 18:53:41 ]
>>397
ブランチはともかく、マージ必要無しって・・・
上書き上等ってことか?

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

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

400 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 19:49:48 ]
ぶっちゃけオンラインストレージよりはグローバルアドレスがひとつ欲しいんだよなあ

401 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 20:27:10 ]
うちのプロバイダだと固定IPとるのに月5000円かかるからなぁ…

402 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 20:39:31 ]
月500円ぐらいのVPS契約すれば、グローバルのIP1個貰えるじゃん。

403 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 21:39:25 ]
固定IPなんか必要ないだろ

404 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 21:43:59 ]
電気代とか、サーバーの構築費用考えたら、
クラウドでも借りた方が安いんじゃね?

405 名前:デフォルトの名無しさん mailto:sage [2010/11/06(土) 22:01:46 ]
このスレ的には、bitbucketかgithubで決まりだろ?



406 名前:380 mailto:sage [2010/11/06(土) 22:42:00 ]
レスサンクス。参考になりました。俺デザイナ?っていいましたっけ・・・なんでバレてるんでしょ

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

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

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

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

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

>>390
人員変えられたら苦労しないし、むしろ俺が変わって欲しいw

407 名前:380 mailto:sage [2010/11/06(土) 22:47:05 ]
>>397
ワロタww
実際そんな感じでいい、という流れになってるw
プログラマがリソース受け取って手動マージw

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

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

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

ですが、扱うデータがグラフィックデータやバイナリほとんどだと
最初から差分やマージの恩恵がうけにくいので、諦めている感じがします。
システムで解決しようとする人たちが少ないのわからないですが、
この辺もう少しプログラマ界隈のようにツールが整っていてもいいのにとは思います。

408 名前:380 mailto:sage [2010/11/06(土) 23:05:12 ]
ちょっと閃いたのですが、サーバー側にもDropboxクライアントを入れておいて、
作業員がDropboxの共有にファイルを入れたら、サーバー側で取得、
リポジトリの(デザイナは知らない)デザイナ用ブランチに自動コミットというのはありかも。


実際、そこまで手間かけてやる必要あるのか?という問題はありますが、
(こちらに支障でない程度に)なんとかカバーしてあげたいですよね。

409 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 04:27:31 ]
今のご時勢バージョン管理使えるデザイナっつーのはどこに行っても重宝されるよ。現にここでもニーズがあったろう?って言えば
ぜひ使い方を教えてくれってなるんじゃねーの

410 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 04:42:27 ]
>>380の人に助言できるとしたら、VCSは、何も差分だけを管理してる訳じゃないよと
履歴すなわち、誰がいつ何をしたか、ってのも残ってるんだよってことかな
DropBoxでも、それはわかるんだろうか

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

あと、コミットログがあるので、「なぜ」その変更をしたのか、が一応残っている。
これもDropBoxで再現できているっていうならまあもう言うことはないけれど。

411 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 09:23:42 ]
Redmineを入れているそうだから、「誰がいつ何をしたか」の記録は残るでしょ。
VCSの機能として欠かせないのにblameがあるけど、バイナリじゃ意味ないし。
Redmineのwikiはblameもできるし。
となると、VCSを使うメリットが見出せないというのも分からないでもない。

412 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 11:34:14 ]
Redmine の Wiki は微妙に使い辛いんだよなぁ。
Google Docs あたりと上手く連携出来たらいいのにってよく思う。

413 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 12:10:50 ]
昔の職場、CVS使えってどんだけ言っても面倒くさがって使わない奴らばっかだったんだけど
その理由として「価値を見出せない」というのもあるけど「何もかもオープンになる」のが嫌
ってのもあったような気がするな。
特にデザイナの人ってプログラマと違ってキチキチやらないから単純な間違いも凄く多くて、
それが全部見え見え(メール飛ぶ設定になってたり)になるのが嫌なのかも。

どっかで読んだブログで、新しく来た中国人ブログラマとのコミュニケーションに
ちょっと不安があったんだけど、コミットログを見てると最近の調子が手に取るように分かる、
ってのがあって、なるほどなぁ、と思った。

414 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 12:20:14 ]
業務でやってるんだから、作業内容にプライバシーなんか無いだろ。
個人の作業用ブランチに毎日コミットさせると良いぞ。

415 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 13:03:39 ]
いちいち他人のログを見るってどんな暇人だよとおもう。
自分のログだって、デグレートの問題が起きなきゃ見ないよ。



416 名前:デフォルトの名無しさん [2010/11/07(日) 13:07:03 ]
え?ログ見ないの?
一行目に目的を書くの常識でしょ?

417 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 13:18:06 ]
締め切り間際になって出来ていませんでしたと言われたくなかったら、進捗具合とかチェックするだろ。


418 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 14:12:18 ]
普段は最低でも1日1回、多い時は4〜5回コミットしているのに、
あるとき一週間コミットせずにいたら、部長に喫茶店に連れ出されて
面談になったw
お客さんの依頼で他の作業をしていただけで、リーダーの指示なんだから
上にも伝わっているものだと思っていたのに。
俺から部長に事情を説明したんだが、その後リーダーの機嫌は悪かった。
まあ知ったことじゃないけどね。

419 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 14:14:54 ]
うちのところはフックして自動的にコミット内容メールで流してるから、
全員の進捗具合や、何をどう修正・実装したかまでだいたいわかる
つーか、普通こうやっとくもんでしょ

420 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 14:15:59 ]
コミット内容がメールで流れると、コミットの粒度が無駄に大きくなりそうだ。

421 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 14:18:47 ]
そういう隠蔽体質を作らないのが管理の本当の仕事だと最近思う

422 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 14:59:44 ]
上司が隠蔽してのし上がった組織は隠したがるから理解されない

423 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 15:02:32 ]
徹夜すればなんとかなる気質の人とかはコミットトレースされたがらないんだろうなって気はするなぁ。

424 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 15:05:25 ]
そんなあなたにgit、Mercurialの--dateオプション

425 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 15:15:26 ]
>>423
別にトレースされたからってその人の作業結果の価値が下がるわけじゃないと思うんだけどな
評価するやつ次第なところっていう



426 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 15:18:00 ]
水面下のバタバタを隠せるって点で git は痛し痒し

427 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 19:12:29 ]
>>420
チーム内の仲のいい奴や意識の高い奴と示し合わせて、
「頻繁にコミットするのが当たり前、コミットを渋る奴はバカ」みたいな空気を
作っちゃうんだよ。
意識の低い奴は周りの雰囲気に合わせて何となく動くから、雰囲気に合わせるだけで
正しい行動が取れるような環境を作ってあげるのがリーダーの仕事だよね。

まあ、俺にはとても無理だけどね。

428 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 19:53:37 ]
BTS も SCM も俺ひとりしか真面目につかってない
辞めたい

429 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 21:09:11 ]
>428
俺も昔はその状態だった。半年後ぐらいに改善されたが。

430 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 21:50:03 ]
ttp://sourceforge.jp/magazine/10/11/01/0937206
俺も、参戦するぜ!


431 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 21:52:13 ]
>430
>リポジトリデータはSQLiteで管理する。

キモの部分が他人任せかよ。

432 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 22:09:21 ]
キモかどうかは判断が分かれるな
バックエンドの処理については実装部分の話で速度に影響する
もしmonotoneが速かったらGITもMercurialも産まれてなかったかもしれない

433 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 22:14:39 ]
po3a.blogspot.com/2007/12/subversion.html
> もし C++ で書かれた VCS が欲しいのなら、Monotone を見てみるといい。
> ほんとに。連中は「本物のデータベース」を使っているよ。
> 「素敵なオブジェクト指向ライブラリ」も使ってる。「ナイスな C++ の抽象化」も
> 使ってる。そして率直なことろ、一部の情報系の人間が喜びそうな
> これらすべての設計上の決定のために、できてきた結果はゲロゲロで
> 保守不可能なカオスだ。


434 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 22:29:00 ]
ケチョンケチョンだなw
Cが至高なのは同意だが

435 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 22:42:13 ]
Linus は最初 BitKeeper に変る SCM でMonotone を最有力に挙げていたが、
動作速度が遅いから Linus版 Monotone としてGitを作ったんだよな。



436 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 22:42:59 ]
そこは別にいいんじゃね?


437 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 22:44:07 ]
しょっちゅう使うツールは速いが正義なんだよなぁ。

438 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 22:48:02 ]
で、Monotoneは、user-visibleなとこでは、どの辺に新規性があるわけ?
公開鍵がどうこうのあたり?

439 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 23:00:55 ]
Monotone はファイル名をUTF-8に変換して管理してる。
これは Git に持ち込まなかった概念で、速度を犠牲にしたバカげた設計だと
Linus は思ったのだろう。

440 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 23:01:40 ]
>>428
同じく。一回提案したら便利そうだから使ってみようって流れになったんだけど、いざ導入したらよくわからんとか難しいとか言って使ってくれなくなった…。ちなみに相手はみんなプログラマ。

441 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 23:18:04 ]
Mercuの利点ってなに?

442 名前:デフォルトの名無しさん mailto:sage [2010/11/07(日) 23:34:18 ]
>>439
Linux上のファイル名をLANGで変換するのであるならば、それはバカげた設計

443 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 02:52:27 ]
義務教育でバージョン管理のし方は教えておけよ、と思う

444 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 03:03:40 ]
日記=コミットログ

445 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 03:24:26 ]
20年前のcommitにrevertするにはどうすれば



446 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 03:48:35 ]
種付け=フォーク

447 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 04:21:22 ]
結婚=マージ

448 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 04:27:37 ]
浮気=ブランチ

449 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 09:38:56 ]
子供っていう派生プロジェクトを亡き者には出来ないだろ。。。

450 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 15:31:29 ]
子供は分散システム

451 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 16:46:26 ]
性格の不一致=コンフリクト

452 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 17:20:20 ]
commit = sex

453 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 18:02:38 ]
再婚=リベース

454 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 21:47:04 ]
一つのリポジトリで複数(というか全て)のプロジェクトを管理できないかと考えています(無料のプライベートリポジトリサービスの多くは作れるリポジトリ数に制限があるようなので)。
個人でバージョン管理システムを使う場合、このような運用をする上で何か問題はありますか?
また、問題は無くともプロジェクト毎にリポジトリを分けた方がいい積極的な理由はありますか?

455 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 21:54:17 ]
プロジェクトで共有しているライブラリとかたくさん作ってるなら一つにしたほうがいいんじゃないの
完全に別物ならバージョンアップのとき別々の方がいいだろうし



456 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 21:54:22 ]
関連スレ

プログラマー的"女の口説き方"
hibari.2ch.net/test/read.cgi/tech/1142089873/
彼女にポートスキャンの形跡が!!!
hibari.2ch.net/test/read.cgi/unix/1014614044/
彼女がUNIX始めました。
hibari.2ch.net/test/read.cgi/unix/1018731587/
彼女にloginできません
hibari.2ch.net/test/read.cgi/unix/1007136614/
彼女がオープンソース化されそうです
hibari.2ch.net/test/read.cgi/unix/1000484092/
彼女をCVSで管理したい
hibari.2ch.net/test/read.cgi/unix/999837578/
彼女をmountできません
hibari.2ch.net/test/read.cgi/unix/1059971117/
彼女をGNU Screenで
pc8.2ch.net/test/read.cgi/unix/1073793361/
女子高生のカーネル領域における言語的等価性
hibari.2ch.net/test/read.cgi/unix/1010917395/
女性を UNIX に招くための HOWTO
hibari.2ch.net/test/read.cgi/unix/1042963649/

457 名前:デフォルトの名無しさん mailto:sage [2010/11/08(月) 22:31:57 ]
>>455
ありがとうございます。
やっぱりそんなに問題ないのかな。
共有ライブラリ的なものも色々作るつもりなので、単一リポジトリの方向で検討してみます。






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

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

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