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

1 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 12:26:04 ] バージョン管理システムについて語りましょう ●過去スレ バージョン管理システムについて語るスレ 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/ バージョン管理システムについて語るスレ7 hibari.2ch.net/test/read.cgi/tech/1283780922/ 41 名前：methane mailto:sage [2011/01/26(水) 14:13:42 ] >>36-37 つbzr-colo 42 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 14:53:47 ] >>41 何それ？ 43 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 15:19:30 ] >>40 > >>35 > >hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、 > >って、これも知っているよね？ > > bzrの場合は、ハードリンク機能によらない shared repository と stacked branch を > 用意してて、同じファイルシステムで clone した後に push / pull したら共有できない > という制限もない。 foozy.bitbucket.org/hgbook-ja/d6ca1334a19d/hgbookch4.html#x27-790004.5 何人かの構成管理ツールの開発者により、この方法 完全にリポジトリ固有のものとしてファイルを複製する が ディスク使用量削減にそれほど効果的でないとの指摘を受けています。それは事実ではありますが、 ディスク容量の 確保は安価であり、 OS への複製要求を遅延することにより高い性能を得ることができます。 別な仕組みを用いる場合、性能が低下しソフトウェアの複雑さが増しますので、 日々の利用における “体感” に非常に影響を及ぼします。 訳注: つまり、 Mercurial でのハードリンクの使用は、複製を行うことによるディスクヘッドのシークを 低減するのが主眼で、ディスク使用量の低減が主眼ではな い、ということです。 44 名前：methane mailto:sage [2011/01/26(水) 18:32:36 ] >>42 簡単に言えば、gitみたいな名前付きブランチを実現するもの。 bzr自体は作業ツリー、ブランチ、リポジトリを分離して自由に構成できるけど、 逆に自由すぎるのが面倒なので、1リポジトリ, 複数のブランチ、1つの作業ツリーの 組み合わせを git のように扱えるようにしてくれるもの。 >>36 で言えば、 bzr colo-branch -r30 NewBranch の1ステップになる（現在のブランチ=OldBranchのr30からNewBranchを作って、 作業ツリーを新しいブランチのチェックアウトに切り替える） 45 名前：デフォルトの名無しさん [2011/01/26(水) 19:00:02 ] >>44 > >>42 > 簡単に言えば、gitみたいな名前付きブランチを実現するもの。 　　　　　　　　　＼　　　∩─ｰ､ 　　　==== 　　　　　　　　　　 ＼／　●　､_ ｀ヽ 　　====== 　　　　　　　　　　　/ ＼(　●　 ● |つ 　　　　　　　　　　　|　　 X_入__ノ 　 ミ　　　そんな餌で俺様が釣られクマ―― 　　　　　　　　　　　 ､　(＿／　　　ノ　/⌒l 　　　　　　　　　　　 /＼＿＿＿ノﾞ＿/　 /　　===== 　　　　　　　　　 　 〈　　　　　　　　 ＿_ノ　　==== 　　　　　　　　　　　 ＼　＼＿　　　　＼ 　　　　　　　　　　　　　＼＿__）　　　　　＼　　　======　　　(´⌒ 　　　　　　　　　　　　　　　　＼　　 ＿＿_ ＼＿＿　　(´⌒;;(´⌒;; 　　　　　　　　　　　　　　　　　 ＼＿＿＿）＿＿＿）(´;;⌒　 (´⌒;;　　ズザザザ 46 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 23:34:10 ] 誤解を恐れずに言えば、Gitにはブランチは存在しない 旧来のブランチの機能を果す何物かがあるだけ 47 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 23:54:13 ] mercurialの設計で一番の間違いはブランチを名前で管理できると思ったところだと思う。 48 名前：methane mailto:sage [2011/01/27(木) 00:12:55 ] え、じゃぁ progit.org/book/ja/ch3-2.html ここでいう 'master' ブランチ とかいうのは名前付きブランチじゃないの？ まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように なるのが bzr-colo 49 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 00:40:14 ] 突然だけど、Meld と Diffuse ってどっちが使いやすい？ プラットホームは Linux で。ほかにも何かおすすめがあれば。 50 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 00:43:20 ] >>48 bzrはよく分かんないんだけど、 gitは>>46の通りで、SHA1ハッシュに対するエイリアスをブランチと呼んでいるだけで、 内部的には「ブランチを作る」という機能は無いと言っていい。 ただUIとしては「ブランチ」と特化した表現をしたほうが分かりやすいので 「ブランチを作る」というコマンドは存在する（エイリアスを作るだけのコマンド） 51 名前：methane mailto:sage [2011/01/27(木) 00:47:49 ] >>50 うん、で、今は内部構造じゃなくてワークフローの話をしているんだから、 >>44 の発言って別に間違ってないよね。 >>45-47 の突っ込みは気にしなくて いいよね。 52 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 00:54:56 ] >>50 馬鹿なの？ ブランチの意味知らないんなら喋らないほうがいいよｗｗｗ 53 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 01:10:01 ] 極端な例だけど下記のような分岐をした場合、各VCSはどのようにbranchを管理するでしょうか？ ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿branch1 ＿×＿×＿×＿×＿×＿×＿×＿branch2 ×＿×＿×＿×＿×＿×＿×＿＿branch3 ＿×＿×＿×＿×＿×＿×＿×＿branch4 ×＿×＿×＿×＿×＿×＿×＿＿branch5 54 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 02:27:26 ] >>52 は？ 55 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 04:46:40 ] MercurialやGitのようなブランチの操作をするのに、bzr-coloが必要となる時点でBazaarは使いづらい。 「ブランチ」に対するアプローチが、 ・ディレクトリ名を指定 ・共有リポジトリ作成後、その下にあるディレクトリ名を指定 ・bzr-coloを利用 と3種類もある。 GitやMercurialはシンプルなコンセプトで実装が見えない所が、SVNに似ているので見えてしまうのがBazaarという印象が拭えない。 56 名前：methane mailto:sage [2011/01/27(木) 07:43:19 ] >>55 だから俺は >>30 で >どちらが優位とかは完全に個人の感覚に依存しちゃうから賛同も反論もしない。 って言ったんだけどね。 俺はsvnやbzrに慣れているから、ブランチがディレクトリにひもづいている方が 安心できる。（作業中のブランチを数か月放置して復帰するときにやりかけの 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか） だから、自分では bzr-colo はあまり使ってない。 ブランチ管理についてできるだけ特定のスタイルを押し付けないのがbzrの方針。 逆に言えば「こういうフローで作業しましょうね」という指針を提供してくれていないので 初心者にはどう使ったら良いのか判らなくなるし、gitと同じワークフローを採用すると gitよりもブランチ管理が手間になったりもする。 この点は結構前からBazaarのMLで議論されていて、bzr-colo は git と同じワークフローを 楽にするプラグインという以上に、将来の bzr の "bzr init" で作成するのを standalone branchじゃなくてcolocated branchにするための proof of conceptにも なっている。 57 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 07:44:04 ] >>47 Mercurialの「名前付きブランチ」は「おまけ」 リポジトリの分離と名無しブランチでも運用可能 cvsのブランチのように消さないことを前提としている 名前付きブランチを乱発すると収集が付かなくなるからcloseする機能が後から出来た 「名前付きブランチ」と「リビジョン番号」はgitには無い 58 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 07:46:13 ] >>48 > まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように > なるのが bzr-colo 用語はどうでもよいから、bzrは意味不明な用語を乱発しているのか 59 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 07:54:07 ] >>56 > 俺はsvnやbzrに慣れているから、ブランチがディレクトリにひもづいている方が > 安心できる。（作業中のブランチを数か月放置して復帰するときにやりかけの > 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を > 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか） 大量のごみブランチが発生するのは害でしかない マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい ブランチとやらがbzrの売りらしいが、 大規模コミュニティの開発では何のメリットも無い 60 名前：methane mailto:sage [2011/01/27(木) 07:58:51 ] >>58 いちいち突っかかるなぁ。。。 僕が git が定義している用語を知らないし興味もないってだけだよ。 gitはgithubクライアントにしか使ってないから。 bzr ではきちんと用語を定義して使い分けてるよ。 で、git で refs 以下で「コミットに対する名前による参照」を提供しているけど、 この「コミットに対する名前による参照」って git はなんて定義しているの？ 「ローカルブランチ」だとブランチが存在する場所が焦点になってしまって、 hgの無名ブランチと違って「名前で参照されている」という点に焦点を当てたかったから hgの用語を拝借して「名前付きブランチ」と呼んだんだけど。 61 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 08:04:16 ] >>60 ローカルブランチ、リモートブランチを勉強してから出直してきな 62 名前：methane mailto:sage [2011/01/27(木) 08:07:51 ] >>59 > 大量のごみブランチが発生するのは害でしかない > マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない だからこういう個人の主観による優劣で議論する気ないんだってば。 **俺は** 目に付くところ（ディレクトリ）にあった方が、「あの作業中のブランチどこおいてたっけ？」 ってならないし、本当に要らないものを整理する気になるから好きってだけで、 別にbzrはそれを強制してないから、 >>59 が bzr を使うときには俺と違う使い方をすればいい。 > github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい 意味が分からない。 リポジトリのフォークって個人所有のブランチ切る以上の意味があるの？ 63 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 08:09:19 ] >>60 > 僕が git が定義している用語を知らないし興味もないってだけだよ。 bzr開発者はgitに興味が無いから、bzrは使い勝手の悪い誰得アプリになってしまったのか 64 名前：methane mailto:sage [2011/01/27(木) 08:12:07 ] >>61 gitも一応githubクライアントとして少しは使ってるから、 ローカルブランチとリモートブランチは使ってるよ。 どちらもコミットのハッシュ値ではなくて名前で参照できるという点では、 hgでいう「名前付きブランチ」だね。 もちろん完全に同じものとは言ってないよ。 65 名前：methane mailto:sage [2011/01/27(木) 08:13:34 ] >>63 本当にそうなら bzr-colo なんて存在しないよ。 66 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 09:01:24 ] >>62 > **俺は** 目に付くところ（ディレクトリ）にあった方が、「あの作業中のブランチどこおいてたっけ？」ってならない Gitはブランチの一覧ができる。 Mercurialはブランチやヘッドの一覧ができる。 Bazaarはディレクトリを見て、「これブランチだっけ？」と考える必要がある。 目につくところに無いのは、Bazaarとしか思えない。 67 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 09:05:55 ] >>62 > > github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい > 意味が分からない。 > リポジトリのフォークって個人所有のブランチ切る以上の意味があるの？ 意味が分からない 「個人所有のブランチ」って何？ 68 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 09:19:32 ] >>62 > だからこういう個人の主観による優劣で議論する気ないんだってば。 「個人の主観」ではなく、VCS運用の基本ではないか。 Git、Mercurialとも基本機能は単純だが、プロジェクト毎に方法論を確立している。 Bazaarはオープンソースでの実績があまりにも乏しいのもあって、方法論が確立しているように見えない。 69 名前：methane mailto:sage [2011/01/27(木) 09:35:19 ] >>66 だから **俺は** って言ってるじゃん。別にbzrがgit,hgより優れてるなんて言ってないよ。 **俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て 「これブランチだっけ？」なんて考えないし、そもそもコミットしてないデバッグ目的の変更や、 addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って そこに残しているの。 bzrならこんな使い方もできるというだけで、一般的にこの方法が優れているなんて思ってないし、 bzrもこの使い方を強制しているわけじゃない。 >>67 自分がpushできるブランチ >>68 個人の作業中のデータを個人のPCのどこに置くのが便利かなんてプロジェクトで確立するべき ワークフローか？個人が便利に使えたらそれで良いじゃん。 70 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 09:40:39 ] >>69 > >>68 > 個人の作業中のデータを個人のPCのどこに置くのが便利かなんてプロジェクトで確立するべき > ワークフローか？個人が便利に使えたらそれで良いじゃん。 bzrは個人でしか使えないという認識で良いのですね？ 71 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 09:41:55 ] なんか煽るだけしかできない奴が張り付いてるな 72 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 09:42:12 ] お前らってホント色んなネタで宗教戦争できるのな 73 名前：methane mailto:sage [2011/01/27(木) 09:44:07 ] >>70 そもそもこの議論の発端が俺の 「ブランチがディレクトリにひもづく」 発言なんだから、 最初からローカル作業の話なんだけど？ 開発サイトでのブランチの管理と、ローカルでの作業ツリー＋ブランチの管理は別物。 74 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 09:49:59 ] methaneたんﾍﾟﾛﾍﾟﾛ 75 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 10:00:45 ] >>69 > そもそもコミットしてないデバッグ目的の変更や、 > addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って > そこに残しているの。 Subversionの欠点をそのまま踏襲しているのか？ 76 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 10:20:06 ] >>69 >**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て GitやMercurialと比較して、Bazaarは運用にmethane氏のようなコツがいるわけだね。 77 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 10:23:16 ] なんで普通に読めばbzrの不便な点が書いてあるだけなのに、それを個人に対する批判と捉えちゃうんだろう 78 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 10:30:24 ] Twitterでやれ 79 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 11:01:41 ] >>77 bzr特有の概念の「ブランチ」をあたかも普遍的な概念としていて、 誰も理解できないことを書いているのだから、批判と捉えても仕方がない 80 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 11:04:12 ] 話がかみ合ってなくないか 81 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:03:18 ] >56 > 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を > 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか） svnでrepo/projectname/trunkをチェックアウトするのではなく、 repo/projectnameをチェックアウトしてたって事？ 変わった使い方だな。 82 名前：methane mailto:sage [2011/01/27(木) 12:19:23 ] >>81 project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo をそれぞれ並列にチェックアウトして作業したい事ってない？ 僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。 というかこれもう完全にbzrの話じゃないよね。 hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。 83 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:24:13 ] >82 > hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。 いや、あんたがsvn, bzrの特徴として言い出したんだが。 84 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:41:23 ] >>82 > project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo > をそれぞれ並列にチェックアウトして作業したい事ってない？ > 僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。 hgは同じファイルシステムだとリポジトリはハードリンクだからコストがかからなし、 gitもhgもcheckoutで切り替えればいいだけ わざわざ全部チェックアウトするメリットは？ 85 名前：methane mailto:sage [2011/01/27(木) 12:41:47 ] >>83 単に、ブランチごとに作業ツリー作るのが楽と感じる人もいるんだよという ことが言いたかっただけなんだが、 >>56 を見るとそれが bzr の特徴って 思われても仕方ないな。すまん。 86 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:50:52 ] >>81 > svnでrepo/projectname/trunkをチェックアウトするのではなく、 > repo/projectnameをチェックアウトしてたって事？ > 変わった使い方だな。 なるほど、bzrは"svn switch"も簡単にできないから全部チェックアウトする必要があるのか 87 名前：methane mailto:sage [2011/01/27(木) 12:53:10 ] >>84 だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で 持っておきたい場合があるんだって。 コミットしない変更とか、バージョン管理下に無いテストデータとか、 色々なゴミファイルが作業ツリー配下にできるから。 別に git stash; git checkout; とかでも良いんだけど、ファイルシステム上に 合った方がテキストエディタで開くにもgrepするにも何かと便利だったりするんだよ。 というかこれもう完全にバージョン管理ツールの話じゃなくて個人の 作業スタイルの話だからやめようぜ。 88 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:54:05 ] Mercurialは、BazaarやGitとはちょっと違う。ブランチもまとめてclone/push/pullになる。 89 名前：methane mailto:sage [2011/01/27(木) 12:55:07 ] >>86 bzr switch そのものズバリのコマンドがある。 90 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:59:49 ] >>87 > だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で > 持っておきたい場合があるんだって。 > コミットしない変更とか、バージョン管理下に無いテストデータとか、 > 色々なゴミファイルが作業ツリー配下にできるから。 分散型で「コミットしない変更とか、バージョン管理下に無いテストデータとか」が 発生すること自体が理解できないのだが MercurialのMQや"git merge --squash"のような機能が無いってことなのか？ 91 名前：methane mailto:sage [2011/01/27(木) 13:22:14 ] >>90 違う違う、 cd 1.1; ./foo --test > test.result; cd .. cd 1.2; ./foo --test > test.result; cd .. diff -u 1.1/test.result 1.2/test.result とか、あとは勝手に入れてコミットには絶対含めないprintfデバッグ用 コードとか、ローカルで動かすための設定ファイルetcetc... 最初から最後まで一切バージョン管理には含めないゴミだけど 作業中は残しておきたいファイルだよ。 もちろんそういったデータを管理するためのプラグインもある(pipeline) んだけど管理するよりディレクトリ分けた方が楽だと思ってるから 分けてるだけ。 だからもうこの話もうやめようぜ。 俺は作業ツリーを複数持ちたいからそうしているだけなのに、 なんでいちいちbzrの機能不足という事に繋げようとするのかねぇ。 bzrが使いにくくないと何か困ることがあるんだろうか？ 92 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 13:26:28 ] > bzrが使いにくくないと何か困ることがあるんだろうか？ Bazaarが使いづらいと、指摘している人が多いだけ。 このスレだと、比較分析されて当然。 93 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 13:36:04 ] >>91 > >>90 > 違う違う、 > > cd 1.1; ./foo --test > test.result; cd .. > cd 1.2; ./foo --test > test.result; cd .. > diff -u 1.1/test.result 1.2/test.result > > とか、あとは勝手に入れてコミットには絶対含めないprintfデバッグ用 > コードとか、ローカルで動かすための設定ファイルetcetc... > 最初から最後まで一切バージョン管理には含めないゴミだけど > 作業中は残しておきたいファイルだよ。 これこそMercurialのMQの目的なのだが。 gitにも輸出されているそうだし。 94 名前：methane mailto:sage [2011/01/27(木) 13:49:43 ] >>93 うん、だから、 > もちろんそういったデータを管理するためのプラグインもある(pipeline) > んだけど管理するよりディレクトリ分けた方が楽だと思ってるから > 分けてるだけ。 って言ってる。 作業ツリーを分けるのは僕が楽と思ってるスタイルであって、別にbzrが推奨 しているわけではないし、bzrの機能不足で仕方なくこのスタイルをとっている わけでもない。 ディレクトリを分けるのが面倒という意見に対する反例としてディレクトリを 分けるのが楽と感じる人もいるんだよという意味で自分のスタイルを紹介した だけで、別にこれがbzrのスタイルではない。 bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では どのスタイルも推奨していない。 が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、 bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる 可能性が高い。 95 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 13:51:58 ] 自由度の高さがわかりづらさを助長してる部分はあるよね、Bazaar。 といいつつ愛用しているけれど。 96 名前：デフォルトの名無しさん [2011/01/27(木) 15:24:29 ] bzr init --append-revisions-only したリポジトリに対して pull をすると、以下のようにでる。 No revisions to pull. しかし、push しようとすると、以下のようになる。 bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "/var/tmp/bazaar/trunc/". これ、もしかしてuncommitして編集しなおさないとpush不可能？ 不便すぎない？ Bazaarの--append-revisions-onlyを使っている人いるの？ 97 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 15:51:15 ] Bazaarは色物だな。 98 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 15:53:11 ] >>56 > （作業中のブランチを数か月放置して復帰するときにやりかけの > 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を > 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか） これって、Trac/Redmineを使えば良いだけでは？ 99 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 16:39:14 ] >>94 > bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では > どのスタイルも推奨していない。 > が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、 > bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる > 可能性が高い。 Bazaarの言う自由度の高さとGitのこれとは何が違うの？ Pro Git 5.1 Git での分散作業 分散作業の流れ progit.org/book/ja/ch5-1.html 100 名前：methane mailto:sage [2011/01/27(木) 16:45:30 ] >>96 branch, merge, push で運用したいなら、 append-revisions-only は設定しちゃだめ。 例えば github のグラフとか見ると、 push したら一番上のラインがゴソっと入れ替わる ことがあるけど、それを防止するのが append-revisions-only だから。 append-revisions-only を使って運用したら、履歴がこういう風に、ほかのブランチのマージだけになる。 bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes bzr-colo 使わない場合は、bzr checkout example.com/repo/trunk; cd trunk; して、 bzr merge ../my_own_branch; bzr commit; のように、「trunkがローカルブランチを取り込む」 ようにしないといけない。 大規模プロジェクトでは、この trunk に merge して commit は、限られたコミッタが 手動でやるか、PQMみたいなシステムが自動的にレビューが完了したブランチを取り込む。 TortoiseBZR の開発では、細かい修正は直接 trunk の checkout 上でやってしまっている。 bzr-colo を使って作業ツリー1つでローカルブランチ使いたい場合は、多分こんな感じになる。 bzr colo-ify --trunk-name=local # (初回のみ)colo化して、今のブランチを local という名前にする bzr branch example.com/repo/trunk colo:upstream --bind # (初回のみ)trunkを upstream という名前で持ってくる bzr switch colo:upstream bzr merge colo:local bzr commit -m "Add XXX feature." 2回目以降は、bzr switch, bzr merge, bzr commit で良くなる。 ただし、coloは常用してないので嘘ついてるかも。後でやってみる。 101 名前：methane mailto:sage [2011/01/27(木) 16:49:44 ] >>99 svnと同じく checkout, update, commit でリモートと同期がとれるのが git の中央集権よりも svn チックな使い方かな。 会社で導入したとき、svn に慣れた人には branch, pull, merge, commit, push の一連の操作が面倒らしく、特に非プログラマには最初はすごい不評だった。 今では基本的に checkout を推奨して、bzrを使いこなしたい人だけ ローカルにブランチ作るということにしてる。 102 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 16:53:42 ] >>101 それって、Subversionに慣れている人はSubversionで、 Gitに慣れている人はgit-svnのGitで、を使えば出来ることだよね 103 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 17:04:14 ] >>102 それだとSubversionとgitの両方の環境を維持しなきゃいけないじゃない。 101の方法だとbzrだけに統一できて管理がシンプルになる。 業務でやるなら管理のシンプルさはけっこう重要だと思うがな。 104 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 17:15:15 ] >>103 Eclipse, Netbeans, Visual Studio, Trac, Redmine, Hudson これら全てでBazaarはSubversionと遜色無く動くの？ 105 名前：103 mailto:sage [2011/01/27(木) 18:17:04 ] 知らんよ。 動かないといけない職場なら、それを前提に検討すりゃいい。 それでbzrが候補から落ちるならそれはそれ。 でもそういう状況にないそれが必要ない職場ならbzrでいいし、実際 methaneさんとこはそういう検討の末にbzr選んだだけでしょ? 106 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 18:51:20 ] じゃあ、プロジェクト管理は何でやっているの？ もしかしてExcel？ だから日本語ファイル名が必要なの？ append-revisions-onlyを使わないとリビジョン番号が変わるんだよね？ チケット駆動の開発をしていて、どのリビジョンで修正しました、ってのは、 どう指定すれば良いの？ make distでリビジョン番号を埋め込んだりするよね？ これもリビジョン番号変わっちゃうよね？ 107 名前：methane mailto:sage [2011/01/27(木) 19:02:33 ] なんか会社での運用の話になってるな。 あまり普通の会社じゃないからどれだけ役に立つか判らないけど、 TortoiseSVNに慣れたユーザーは以外とTortoiseBZR使って文句が無い Eclipse, Netbeans は使ってる人いるけど、バージョン管理はコマンドライン bzr-svn で svn プロトコルで serve することができるので、それを使って trunk から svn としてチェックアウト＆コミットがどれくらい実用に耐えるのかは 今後検討しようと思ってる。 Trac, hudson は問題なし。Redmineは使ってない。 チケットはtracのURLを設定ファイルに書いておけば、 commit --fixes で連携可能だけど、 僕が見てる範囲だとあまりチケットとコミットの連携はしてないでユルく運用してる。 make dist をするプロジェクトは少ないんだけど、 >>101 に書いた通り 基本 checkout でやりたい人だけ branch する運用なので、 append-revision-only で問題なく運用できてる。 108 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 19:10:28 ] bzr send使えばいいし 109 名前：96 mailto:sage [2011/01/27(木) 19:38:11 ] オレの問題は解決しないの？ 110 名前：デフォルトの名無しさん [2011/01/27(木) 19:41:58 ] >>109 これまでのレスを見ての通り、日本でBazaarを分散型として使っている人はいない 111 名前：methane mailto:sage [2011/01/27(木) 19:45:00 ] >>109 append_revisions_only = False にするか、 trunk をチェックアウトしてそこから merge する。 詳しくは >>100 112 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 20:05:11 ] bzrもLaunchpadもばりばり使ってるけどね 113 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 11:04:08 ] >>28 > >>26 > リポジトリの構造ってMercurial優位だっけ？ > bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を > 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、 > いつの間にか新しいリポジトリフォーマットが出てきてたのかな。 mercurial.selenic.com/wiki/Win32LongFileNamesExtension 114 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 11:14:29 ] >>32 > Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。 https://bitbucket.org/remleduff/win32lfn/src/a21c5be76398/src/win32lfn.py#cl-65 115 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 11:35:20 ] >>28 > >>26 > リポジトリの構造ってMercurial優位だっけ？ > bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を > 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、 > いつの間にか新しいリポジトリフォーマットが出てきてたのかな。 mercurial.selenic.com/wiki/fncacheRepoFormat#Hashing_of_long_paths > Paths inside the store that would be longer than 120 chars are now hash encoded. 116 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 12:41:08 ] >>111 リビジョン番号が変化するか、不便を強いられるかの2択か。 117 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 12:46:12 ] どんなんかなー 118 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 14:06:25 ] それは、ChangeLogを書き換えてコミットしたら、もうリポジトリはChangeLogとは 違うバージョンになってるってことと比べて、どの程度の不便さなん？ 119 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 14:11:57 ] ChangeLogはCVSのバッドノウハウじゃない？ リリースノートは別管理でしょ？ Bazaarにあるか知らないけど$Rev$が意味をなさない弊害は大きいと思うが 120 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 18:32:49 ] >>118 ChangeLogって、CVSのログから自動生成するものだと思っていたが、手書きするのか Subversion以降見かけたことが無いからぐぐってみたら、こんなの見つけた svnlogbrowser.org/demo/ 121 名前：デフォルトの名無しさん mailto:sage [2011/01/29(土) 10:55:21 ] >>297 これって何で美乳なの？微乳じゃいかんの？ 122 名前：デフォルトの名無しさん mailto:sage [2011/01/29(土) 11:18:08 ] なるほど。乳をバージョン管理か。そいつは思いつかなかったｗ。 123 名前：デフォルトの名無しさん [2011/01/29(土) 11:48:47 ] >>121 美乳　EUCでぐぐってみよう 124 名前：デフォルトの名無しさん mailto:sage [2011/01/29(土) 11:55:48 ] >>121 は落ちたスレへの誤爆と思われ 次スレがあるのでそちらへどうぞ hibari.2ch.net/test/read.cgi/tech/1291075205/ 297 名前：デフォルトの名無しさん [sage]： 2010/09/10(金) 12:24:16 >>290 >>292 >>294 単なるZERO WIDTH SPACEだ？ じゃあお前らは編集者が意図した覚えも無いのに、先頭に勝手にunkoって保存されたりされなかったりする環境に何の問題も感じないの？ エンコーディングが明確になるだ？ 文字化け対策の<!-- 美乳 -->かっつーの いらねーもん無断でつけんなカス 125 名前：デフォルトの名無しさん mailto:sage [2011/02/12(土) 12:37:38 ] gitのイメージカラーってマリオ＆ルイージだよね 126 名前：デフォルトの名無しさん mailto:sage [2011/02/13(日) 18:46:29 ] >>23 直っていない https://bugs.launchpad.net/bzr/+bug/172383/comments/15 127 名前：methane mailto:sage [2011/02/13(日) 22:51:01 ] >>126 irclogs.ubuntu.com/2011/01/25/%23bzr.html#t07:44 128 名前：デフォルトの名無しさん mailto:sage [2011/02/15(火) 02:29:43 ] 【bzr】Bazaarでバージョン管理 Rev 3 hibari.2ch.net/test/read.cgi/tech/1297704483/ 129 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 16:58:30 ] Hg/Git/Bzr のシェアってどんなもんなんですかね？ 130 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 17:08:32 ] Git 6/Hg 3/Bzr 1 131 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 17:18:08 ] Git優勢なんすね 132 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 17:20:26 ] >>130 githubが目立つからそうかもしれないけど、 hgはbitbucket/google code/codeplexと分散しているのと、 hgwebが簡単に立てられて、自前で立てている所が多いから、 オープンソースでもhgはもっと多いと思う。 hgはWindowsサポートでgitより先に行っていたので、企業内ではさらに多いと思う。 133 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 17:35:28 ] qa.debian.org/popcon-graph.php?packages=bzr,git-core,mercurial,subversion&show_installed=on&want_legend=on&from_date=2008-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 134 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 17:49:06 ] >>133 一面ではあると思うが参考になったthx。 135 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 22:40:17 ] 大事なのは、 どのVCSを使うかではなく、 VCSを使って何を作るかである、 とジョン・F・ケネディーも言っていたお。 136 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 13:50:37.67 ] 最近、 思ったけどWindowsのデフォルトロケールをUTF-8に出来ないんだろうかね・・・ Linuxは、UTF-8にできるし、MacはUTF-8 Windowsさえ変えれれば幸せになれるんだけどなぁ・・・(正規化はおいとくとして) いずれにせよ、GiもHgもバイナリ列でファイル名を扱うってポリシーなんだから そのバイナリ列を作る部分にフックを置いて変換できるようにしといてくれればいいんだよぉ・・・ 137 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 14:50:33.54 ] >>136 文字コードスレによれば、WindowsでDBCSが２バイトまでと決まっているから無理だそうだ Mercurialでは関数のよこどりで実現している。あまり美しくないけど 開発者の問題意識はあるという所まで来ているので、大きい声をあげれば フックみたいなのも実現できるかもしれない 138 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 15:47:16.08 ] >>137 Windows8以降でいいのでその辺り何とかして欲しいです・・・ いい加減、UTF-8を扱えないシステムって旧世代ってイメージが・・・ Mercurialの開発者に問題意識が？前は問題はないんだ、 という姿勢だったところからすれば勉強したのかね。自分の視野の狭さっぷりを。 139 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 15:54:28.95 ] Windows は NT のころから Unicode (UCS-2) 対応してて、LinuxやMacよりも 対応全然早かったんだけどな。 互換性のためにMBCSのAPIを残しているだけなんだから、Windowsの視点で言えば 10年以上前から用意しているUnicode API使わないで Windows 95 互換API使ってる アプリの方が旧世代という事になる。 140 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 15:56:36.88 ] そりゃ"Double Byte"が3バイト以上だったりしたら困るわな 141 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 16:04:56.51 ] 2byte用意しときゃ足りるだろ、というSingleByte圏の連中の発想が罪深い・・・・

---

---

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

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