バージョン管理システムについて語るスレ10
平均的プログラマーの7割は、gitを理解できない。 これが現実。 OSS開発者の事じゃないぞ。サラリーマン開発者の事だ。 >>283 もうわざとでしょ、彼にとってはバージョン管理なんかより git でもアクセス制御ができると言えることが最重要なんだよ、例えそれに意味がなくても (w >>284 現状ではそれが一番みたいですな。 >>285 特に SCM 使ってたら直接共有する必要ないしな。 >>287 やっぱり気づいてないみたいね。 はっきり言うと、わかってないのはお前。 >>287 > 現状ではそれが一番みたいですな。 それは最初に俺が言ったことだろw 140 名前:デフォルトの名無しさん[sage] 投稿日:2014/03/10(月) 06:24:12.14 >>139 えとさ、どういうディレクトリ構成なのさ? それ言ってくれんとわからん。 なんか、話を聞いていると、一つのディレクトリのあちこちに、 社内に公開できる部分、出来ない部分があってごちゃごちゃ 混ざってるように思えるんだけど? もしそうだとしたら、それ人為的ミスで間違って ファイルわたしてしまう可能性があるから修正した方がいいよ。 簡略化するとこういう感じ root ├メインプロジェクト(自社開発) └外注さんに任せるライブラリ もしくは root ├メインプロジェクト(外注さんと共同開発) └自社専用ライブラリ ライブラリ部分はgitで言えばsubmoduleという機能を使えばいい。 submoduleは外部のリポジトリを自分のリポジトリに埋め込む機能。 もちろん別々のリポジトリとして扱える。 submoduleはルート直下にしか置けない。 メインプロジェクト以下にライブラリを置かなければいけないことはよくある話で、 そういう場合はシンボリックリンクを使ってメインプロジェクト配下に見せる。 最初に俺がサブモジュールというちゃんとした答えを言って サブモジュールを使うより劣るけど、git+共有ディレクトリでもやれなくてはないよ。 (だから共有ディレクトリでやれるアクセス制限はもちろん出来る) って話をしているのに、わかってないんだな。やっぱり馬鹿か。 >>288 , >>290 きみ、もういいから (w >>289 うん、そうだよ。 でも、リポジトリ構成変えないといけないからうちでは採用できないって書いてある。 一番マシだからと言って使えるかどうかは別の話でしょ? >>290 > サブモジュールを使うより劣るけど、git+共有ディレクトリでもやれなくてはないよ。 いや、やれないじゃん そこは外注使うと決まった時点でリポジトリの構成を変えるべき 手続きが面倒とかは甘え 「共有ディレクトリでやれるアクセス制限」って意味わかんないんだけど。 何のこと? >>296 ディレクトリのパーミッションのこと言ってるらしいよ。 だから当たり前だけどgitでもディレクトリを共有すれば同じこと出来る。 >>292 > でも、リポジトリ構成変えないといけないからうちでは採用できないって書いてある。 え? どこに? >>295 馬鹿だからファイル共有を使ったやり方しかできないんです。 パーミッション設定で精一杯なんです。 >>297 > ディレクトリのパーミッションのこと言ってるらしいよ。 わかんないのはそっちじゃなくて、「共有ディレクトリ」の方。 普通、共有ディレクトリというと、ネットワーク上に存在するディレクトリ/フォルダを指すことが多いけど、そのことかな? で、そこのアクセス制限と個々人の開発環境とはどうリンクするのかがわからない。 >>300 複数のユーザーで共有ディレクトリを使いたい http://www.itmedia.co.jp/help/tips/linux/l0461.html > Linux上で複数のユーザーが使えるようchmod 770などと >指定するディレクトリを用意しても,それぞれのユーザーが >書き込んだファイルやディレクトリは,他のユーザーが書き換えることができない。 >>301 そういう意味の「共有」だとしたら、個々人の開発環境とはどうリンクするの? あぁ、個人ごとにホームディレクトリに ローカルリポジトリを持つという発想ではなくて サーバーにある一つのディレクトリを みんなで共有して開発するやり方か。 グループ権限とか設定して。 でも同じ設定すればgit使いながら 共有ディレクトリ使えるんじゃねーの? ってそういう話をしていたわけか。やっと分かった。 sticky bitのことを知ってるのは俺だけだと思ってそうw >>303 > サーバーにある一つのディレクトリを > みんなで共有して開発するやり方か。 そのやり方が全く想像できないんですが。 >>302 個々の人の開発環境っていきなり何の話。 スレを「開発環境」検索しても 無関係なものしかヒットしないんだけど。 プロジェクトファイルだけを共有するんだから 個々の人の開発環境は、個々の人でしょ? (つまりホームディレクトリに設定ファイルがある) 好きなエディタ使えるよ。そういう話だよね? >>305 > そのやり方が全く想像できないんですが。 そのやり方っていうか、そもそもグループ権限を理解してないよね? gitを知らないどころか グループ権限までしらん人がいるのか。 下には下がいるもんじゃw >>295 なんでツールのためにそんな苦労するの? SVN ならちょっと設定するだけですよ。 >>298 >>148 の後半 >>310 なんでSVNの話? 共有ディレクトリの話でしょ? >>304 なんか昔に聞いたことあったけどすっかり忘れてたので、ググってみた 忘れたままでいい機能だった... >>310 >>311 SVNで一つのディレクトリを複数の人で共有して 開発してるんでしょ? なんでそんなことをしているのかしらんけど。 その程度のやり方で満足しているなら gitでも同じようにすればいいじゃん? gitでも一つのディレクトリを複数の人で共有して使えるよ。 不便だけどね。(SVNでも不便なはずだが?) >>311 すまん、共有ディレクトリの話なら誤レスだ、無視してくれ。 >>312 お前それは恥ずかしいセリフだぞ。 たとえば、sudoコマンドには sticky bitがついてる。 ついてるからこそ一般権限で実行できるわけだ。 ただ今の話はsticky bitよりもSGIDの方が重要なんだけどな。 >>304 はちょっと無知っぽいw >>313 > SVNで一つのディレクトリを複数の人で共有して開発してるんでしょ? ねえねえ、どこからそんな変な解釈思い付いたの? (w SVNで一つのディレクトリを複数の人で 共有して開発ってマジでやってんの? ちょっとその発想はなかった。 >>316 それは>>229 だな。しっかりやり方を説明しちゃってる。 229 名前:デフォルトの名無しさん[sage] 投稿日:2014/03/11(火) 10:40:50.83 >>220 user = {dev1, dev2, co-dev1} がいるときに、 /proj/src/app/ /proj/src/lib/ /proj/src/else /proj/else というディレクトリ構成で、 * dev1,dev2は全てのディレクトリ以下を参照できる * co-dev1は/proj/src/lib以下を見ることができない。それ以外は全部参照できる という設定をするとき、 dev-group = {dev1, dev2, co-dev1} lib-dev-group = {dev1, dev2} というグルーピングをし、 chgrp -R /proj dev-group chgrp -R /proj/src/lib chmod -R 770 /pro/src/lib とすれば実現できるが、これをgitではどうやるかという話だと思うが。 もちろん、複数人で開発するのだから、サーバでの話。 >>319 あぁ、ほんとだ。グループで共有するって 話の発端はそいつなのね。 で、まじでこんなやり方でSVN使ってんの? >>315 sudoとかで立ってるのは04000でSet-user-id bit Sticky bitと言われるのは01000 >>304 > 304 名前:デフォルトの名無しさん[sage] 投稿日:2014/03/11(火) 18:31:23.02 > sticky bitのことを知ってるのは俺だけだと思ってそうw なんでここでsticky bitがでてくるの? >>319 それ SVN 関係ない 単なる説明用だろ SVN はサーバー側で設定すれば見せたくないフォルダーとかはチェックアウトできなくなるからクライアント側で設定する必要がない >>313 とかは玉砕した git 脳が同じ土俵に引きづりこもうとしてるだけだろ (w > SVN はサーバー側で設定すれば見せたくないフォルダーとかはチェックアウトできなくなるからクライアント側で設定する必要がない サーバー側で設定すればだろ? 同じことがgitでもできるってなんで考えられないの? >>322 自分が知ってる一番難しそうな奴書いたんだろ。 まあ、>>315 みたいなアホが釣れたからちょっとは効果があったんじゃね? (w ゲーム脳ってあるでしょ? あれ、ゲームやってる人の脳がおかしいって話だったけど、 よくよく聞くと、「ゲーム脳」といっている人の脳がおかしいって気づく。 自分が「ゲーム脳」とはこうである!と決めて それが絶対正しいと思い込んじゃう。 論理的に考えれば、明らかに間違っていることを 指摘しても聞く耳持たなくなっちゃう。 git脳という単語を見た時、そう思ったよ。 >>324 > 同じことがgitでもできるってなんで考えられないの? えっ、まだやるの? 仕組みが違うことぐらいは知ってるんだよね? まあ、できると言うなら方法を具体的に書いてくれ。 /.Jに集うLinuxヲタ達と同じ臭いがする gitスレ行けばいいのに >>326 自分が【「ゲーム脳」といっている人の脳がおかしい】と決めてそれが絶対正しいと思い込んじゃうんですね、わかります (w 論理的に考えればこの手のレスが返ってくることぐらいわかるだろうに... >>327 やらなくていいよ。 サブモジュールを使えばいいって 答えが出てるんだから だよな、サブモジュール使えばいいだけなのに なんでこんなにぶつくさ言ってるんだろ? >>330 俺、○○脳なんてひとことも言ってないけど? ○○脳って言っている奴ってあほだな−って 言ってるだけなんだけど。 >>333 誰かが君が○○脳なんて言ってるのか? ○○脳って言っている奴をあほだな−って言ってる奴ってバカだろって思われてるだけなんだけど (w ○○脳って言っている奴をあほだな−って言ってる奴ってバカって言ってる奴はバカだなw 以下リソース使い果たすまで無限ループ これぐらいマならすぐ気づくよね (w git脳とかruby脳とかは確かにいそうだな というか、兼ねてそう ということにしたいのですね てゆーかrubyのリポジトリはsvnだし >>341 > てゆーかrubyのリポジトリはsvnだし 別にそれは関係ないだろ Linux でソフト作ってる奴がみんな git 使ってるわけないし 集中型も分散型も長所短所があるから、それぞれ使い分ければいいと思う。 いくつがある分散型のいずれを使うべきかは、もう少しふるいにかけられそうだけど ところで gif は「じふ」なのに、なんで git は「ぎっと」と発音するの? おいらずっと「じっと」(GitHUBも「じっとはぶ」)かと思ってたんだが char の「ちゃー」くらいには許される呼び方? 読まないパターンもあるよねgって 何にしても英語は1文字で色んな読み方させすぎなんだよなあ 日本語だって外国人の耳には、ガ行の鼻濁音とか、nとngとmとか、 違って聞こえるらしい、とは聞くけど。 >>348 gh, oughなどは特例と見做すと、サイレントなgってないと思う。 いろんな発音と言えば、fish = Ghoti = 無音 ってネタがあるね。 paradigm align sign foreign gnome(地の精) gnu(動物) >>348 で本当に言いたかったのは英語のスペルと読み方とのパターンが多過ぎってほうだったりするが…済まないな分かりにくくて 音声会話しなければ読み方を間違っていようとどうということはない この板でgnuにgnomeって言ったら発音するほうだろ だからわざと地の精だの動物だの、単語の後ろに括弧書き入れてるんじゃないか >>345 んじゃお前はGIANTSをガイアンツとかギアンツって読むの? って返しになるぜ >>346 まぁそうだわな 英単語の git から名付けられているんだから辞書引けよ。 発音の文句は英語に言え。 Word Excelでバージョン管理できないか探したら 以外とsvnが充実してた My Docmentsの下を全部svnで管理してみる事にする gitで対応させてみてるけど差分が見れるだけで差分だけ保存できるわけでも バイナリだけ変更されたファイルを更新から除外できるわけでもないからあまり意味なくないか 今のとこ文書は別のツール使わないならサブモジュールで別管理することでバージョンアップごとに コードと違うスパンで不要な差分を捨てて圧縮できるようにするのがベストかなと思う progitレベルで分かりやすくsvnを説明してるサイトってない? >>370 これって日本語化はフッターから設定出来るってこと? 日本語化なんて必要ないだろ gitに限った話じゃないが GitHubは多国語化をすすめようとしてたが、中止して英語オンリーに戻った 英語使えない奴はいらねえって方針です ファイルのバージョン管理と ソフト機能のバージョン管理の 違いを認識しろよ。 >>376 これ Word は大丈夫だと思うけど Excel って開いてるだけでファイル変更しちゃう (閉じた時に戻すけど) のにはどう対応してるのか気になる あと、更新ボタンがあるってことはいよいよマージができるようになったのか? 暇ができたらちょっと試してみるかな。 WordはWord自体がバージョン管理機能あるからな ある程度システム化が進んだ会社だとシェアポイント導入してるし >>380 > WordはWord自体がバージョン管理機能あるから このスレでまともにマージもできないバージョン管理機能持ってくる奴がいるとは... Word文章を複数人で同時に書き換えなきゃいけないシーンが思いつかない ソースコードと違って普通は自分が担当するページは決まっているから全員が並行して作業を進めても問題ないし >>382 > Word文章を複数人で同時に書き換えなきゃいけないシーンが思いつかない そりゃ残念だったな てか、マージで並行開発しか思い付かない時点で終っとる ブランチとか使ったことないのかよ WordやExcelをブランチ切って使ってるというのは聞いたことがない そりゃ現状マージできないので、ブランチ切っても旨味がないからな もしかして、想像力がないのか? このスレでいくらWordが、Excelがと騒いだ所で世の中何もかわらないぜ。 マイクロソフト、オプソ開発者のどちらにもメリットがないからな。 もしそういう機能が欲しければ、自分の手を動かそうぜ。 Rdemineで 作業Aチケット(例:桶を組み立てる) 作業Bチケット(例:桶に水を入れる) みたいにあAの後にBがこないと行けない場合って チケットA、Bの関係は親子関係にすればいいの? >>388 水の入った桶を用意する、の子チケットは以下の2つ +桶を組み立てる +桶に水を入れる って手もある。 自分は子チケットの粒度が大きいときは、こうやってる。 redmine のチケットって block みたいなの扱えなかったっけ? 親子以外にも色々関係が定義されてたはず Redmineで30人ぐらいのユーザーを一括登録するとき シェルスクリプト書いて一括登録みたいな事できないんだね 全部GUIというのも不便だ rails なんだから rails console からでも 結局ベストなバージョン管理システムはなんなのですか? でも、日々バッアップするって意味じゃバージョン管理とは別のベクトルで必要だよね 他の物理ドライブに最新のクローンを残しておけばいいだけじゃないの? 火事や倒壊からリストアする必要がないならそれでいい まぁそんなことまで考える必要があるプロジェクトはそんな多くないだろうが >>402 日本だと、違う地域にという必須条件が加わる mercurialは負けなん? まぁ、Unicodeファイル名を取り入れるのにのんびりしすぎだから俺もあきらめ気味だけどさ Git だってリーナスのアホが勝手に作ってるだけで Unicode なんか眼中ないんじゃないの? tortoiseの都合でmercurial使ってる TortoiseHgはワークベンチが使い易かったからVistaまでだと現役だったが Win7以降はSourceTreeもあるからなぁ リーナスはもうGitには関わってないんじゃなかった? Source TreeよりTortoiseHGの方が使いやすいと思うけどなぁ。 >>412 でも、俺が窓が絡むときにMercurial使うことにしてたのは コマンドプロンプトがイマイチで常用に耐えんのに gitフロントエンドもイマイチだったことだもん 俺の場合比べるのは、TortoiseHgでなくTortoiseGitのほうよ 最初にgitのが良いなぁがあって、窓が絡むからcmdやフロントエンドの絡みでhgにしてたのが フロントエンドの話が取り敢えず何とかなるからgitになったってことね 必要なライブラリを入れとけば素のままでビルドできるのでcygwinでgitを使っている sourcetreeはMacのguiをそのままWindowsに持ち込んでるから使いにくい 個人的にはOSX版と違う部分であるブックマークが使いにくいと思うがな なんでOSXと同じ別窓にせんかったのだろうか…別タブとかでも良かったが そろそろgitの次の世代のバージョン管理ツールが出てきて欲しい 巨大プロジェクトへの対応が単一巨大リポジトリかsubmoduleの塊になってもうちょっと使い勝手良くならないものかといつも思うが解決案はわからない そこが工夫された新しいバージョン管理システムが出来るとイイネ! svn, git, mercurial 以外に選択肢があっても良いと思うんだけどな 何か黒船的なインパクトのあるやつを望む gitはrebase対象がひとつのブランチだけでマージの再現も弱かったけど リポジトリ全体の履歴を気軽に書き換えられるようなの頼む で、履歴への変更それ自体もバージョン管理されるような2次元的なのを > リポジトリ全体の履歴を気軽に書き換えられるようなの頼む プラグインで実現できる範囲 > で、履歴への変更それ自体もバージョン管理されるような2次元的なのを 純粋な履歴が汚いから書き換えられるようになってるのを劣化させるだけ GNU Emacs Finally Switching Over To Git From Bazaar http://www.phoronix.com/scan.php?page=news_item& ;px=MTgzNjI >>435 使い心地どうなん? Subversion から移行する価値ある? なんか知らんが、自分とこのワーキングコピーをupdate。 他人の変更とコンフリ。 人間判断入れたマージ。 なんかコミットできねぇ。 何となく再度アップデート。 エラー。 はひょ? てな現象にちょくちょく見舞われた。 svnでもgitでもbazaarでも、そんなのなったことないんだが。 バージョン管理システムでも、関連ツールでもいいんですが、ソースの行毎に最終的に編集したのが誰かを見られるものってなにかありますか? ユーザ:行:ソース user1:1:... user1:2:... user1:3:... user1:4:... user2:5:... user2:6:... ... みたいなイメージなんですが。 gitにもsvnにもblameやannotateがある サーバへソフトのインストールしないで windowsの共有フォルダで管理しようと思ったら 何が便利? >>441 分散バージョン管理だったら、なんでもよくね? レポジトリが共有さえされてればいいわけだから。 >>441 ああ、ローカルレポジトリを持ち、適当なタイミングでpushするのではなく、共有先から直接チェックアウトして、直接コミットか。 Bazaarだとできる。 個人的には気に入ってて、愛用してるけど、もはやバージョンアップされてないのでオススメはしない。 いや、だからgitなら当たり前にできることだって。 いまだにbazaar使ってるの、わたしだけ(´・ω・`)? >>449 大丈夫だ。俺もいる。 ただ世界中で2人だけかもしれんけど あと10年使い続けたら、NHKがドキュメンタリーの取材に来るよ。 >>441 取っ付き易さだけ言えば、TortoiseSVN をクライアントにインストールするのが簡単だと思う。 リポジトリの作成を含めて GUI でできるし。 >>450 (´・ω・`)人(´・ω・`)ナカーマ bzr使いやすいんだよね・・・ぼくには gitなんて使ったこともないはずの上司が「プルリク送っといたからよろしく」と言い出すから何かと思ったら、プルリクなんて何も来ていない。 目の前でもう一度操作させたら、addしてなかった。 当然commitできていないし、どうしてこれでプルリク作った気になれたのか不思議。 「addするんですよ」と言ったら「めんどくさい!もうやらん!」だとさ。orz プルリクって言いたいだけちゃうんかと(´・ω・`)(´・ω・`)(´・ω・`) まずローカルリポジトリだけで便利ってのを知っとくとadd/commitが面倒なんて言わないと思うんだよな いきなりリモート前提でやると面倒に見える手順だけども >>459 それは違う。 作業を計画的にやらないからそうなる。 行き当たりばったりでコード書いてるでしょ? >>450 私も使っとるぞよ。 ファイル名に日本語があるドキュメントの管理が主な用途だが。 まあでも3人てことはないぞ。KiCad では Bazaar が使われてるっぽい。 ソースコードなんかは、なぜか名前が出てこない Mercurial を使ってる。 > なぜか名前が出てこない Mercurial 知名度ではGitに劣るからVCS全体での話に使いづらいし 専用スレがある程度には有名だから、悲観ネタにするほどでもない上に このスレじゃないと話せないってものでもないんだよなあ Windowsのコードもunixのコードも一緒に管理できるやつはないですかねぇ >>3 のやつ大抵WindowsでもUnixでも動くと思うけど >>3 のやつって資材は各環境に格納できて、Windowsクライアントとかから一元操作できるんですかね? 安心して日本語ファイル名が使えるものはないですかねぇ… どうでもイイけどdevは、デバイスと混乱されるから使わないで欲しいw 匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、 BitTorrentがオープンソースで開発されています 言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか? Covenantの作者(Lyrise)がそういう人と話したいそうなので、よろしければツイートお願いします https://twitter.com/Lyrise_al ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーw The Covenant Project 概要 Covenantは、純粋P2Pのファイル共有ソフトです 目的 インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します 特徴 Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW) 接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です DHTにはKademlia + コネクションプールを使用します UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります) 検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません z 「BitKeeper 7.2」、Apache License 2.0でソースコードを公開 https://osdn.jp/magazine/16/05/12/153000 OSSコミュニティとの対立から11年、BitKeeperがオープンソース化される http://opensource.srad.jp/story/16/05/15/0457249/ 感慨深い話ではあるが、今更過ぎるけど使えるの? GPLじゃないなら組み込むアプリケーションでてくるのかな gitを版管理として使いたいという需要以前からあるよね gitコマンドを一緒に置いておいて外部プロセスとして使う分にはGPL関係ないし、libgit2ならリンク時例外あるしでそっち方面には影響なさそう しかし15年前なら… 名前を変えてイメチェンすべき ZuttoKeeper Git 対 Subversion:長引く争い | ReadWrite[日本版] http://readwrite.jp/startup/4492/ なかなかGitに移行しないなんて言われてた時代があったんだな > 2010年にはSubversionが、ソフトウェアの共同開発には > 欠かせないツールであるバージョン管理システムの60%以上を占めていた。 > Forresterによれば、この時期Gitのシェアはわずか2.7%であった。 > Redmonkのアナリストであるステファン・オグレディが集めたデータによると、 > 今日(注2014年)ではGitのシェアは28%まで増加し、Subversionの地位を脅かしている。 今の時代にSubversion使います言われたら絶望するわ >>489 cvs「おい!お前は……」 rcs「関係ねえ!」 >>491 TeamWare「俺には、お前しか居ねえよ」 tortoisegit とか初心者でも使いやすいんじゃないかね。 ↓のブログによると、Subversion 「スナップショット」型で、Gitは「チェンジセット」型なんだそうだ。 SVN脳患者から見たGit http://qiita.com/kaityo256/items/81e7951a1ca2706955a4 だけど、↓のブログによると、darcsはpatch-basedで、他のVCSはsnapshot-basedなんだそうだ。 darcs 恐るべし。 分散VCSのモデル、あるいはPijulについて http://keens.github.io/blog/2016/02/14/dvcsnomoderu_aruihapijulnitsuite/ 不要なパッチを削除できるあたりdarcsのほうが好きだったのでうまく成長してほしい 内部での保存方法はgitこそスナップショットでsvnは(逆方向の)patch-basedだろ? 少なくともgitがチェンジセット型ってこたーない。gitでの差分の見え方なんて後からオプション次第で変わるし SVN脳の問題点というかSVN系統の人が怖がってるのは結局 SVN 系統では commit と push が同一になっているから merge を極端に恐れてるってだけじゃないかと。 svnだって、commitするときに他の人が先に変更を加えていたら updateしてからcommitしなおす事になるし、このときローカルでちょこちょこ辻褄合わせをする作業は git pull --rebaseと同じはずなんだけどな コミット時にコンフリクトする集中型の方が恐怖だけどな。 分散型は、いったんコミットした後で改めてマージするんで、 わけわからなくなっても、何度でもやり直せる。 いやだからその svn での恐怖心を なんだか知らんが git を使ってても引きづってるってことなんじゃないかと。 一番の恐怖は、コンフリクトが判明するのが後のタイミングになるってことなんだよ Excelとかマージできないバイナリ系ファイルも一緒に管理してるから…… 記事のコメントを見ると WebKitのSVNリポジトリで、ハッシュ衝突したPDFがキャッシュ・ポイズニング攻撃に使えるかテストするために ハッシュ衝突したPDFをコミットしたら リポジトリがあぼ〜んってなったと言う訳か てかWebKitってまだSVN使ってたの? gitは仮に衝突しても大丈夫みたいな事言ってたけど どんな感じなのかは知らない 分散型は、一旦コミットした後でマージするから、 最悪マージ前の双方のバージョンは残ってるってことじゃないの? 読んでないけどハッシュが衝突する奇跡が起きたらあぼーんしても不思議で無いね リーナス・トーバルズがハッシュ衝突について語ってるGoogle+の投稿 https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL 別のハッシュアルゴリズムを使う計画はあるらしい Gitを修正してmitigation(緩和?)できるってのはどういう事だろう 実際は衝突する事なんてそんな無いってのはまあ分かる >>513 悪意を持った誰かが公開されているpdfをコミットしただけでぶっ壊せる もしくはWebkitのように、システムの振る舞いを調べるテスト目的でコミットしても壊れる >>515 そのうち SHA-256 とかにするんじゃね >>517 旧バージョンでダンプして新バージョンでロードするだけでしょ いままででもリポジトリのバージョン変わったらそうやってたし まあバージョン管理程度なら大した問題にはならんだろ。 ちょっとしたスクリプトを一枚かませばいいくらいの話。 嫌がらせならハッシュ衝突なんて凝ったことしなくてもできる訳で 嫌がらせ以上のことが可能かといえばそういう話も無く >>487 未だに使ってるとこあるよ。あり得ないと思った >>523 普通に使ってるけど? git だとアクセス制限とかかけられなかったりするから会社では使えないケースもあるし >>525 かけられる。かける方法を知らないお前が馬鹿なだけ 素人でスマンが、実際のところsubversionではできてgitではできないアクセス制限ってどんなのがあるの? >>531 リポジトリの一部を読み出し不可にすること >>532 svnだとリモートリポジトリを作るのが面倒(?)とかいう理由で 全てのプロジェクトを一つのリポジトリに入れるとかいう アホな使い方をしている例をしていたけど、そういう話? リポジトリの一部を読み出し不可にするのであれば その部分だけ別リポジトリに分ければ良いと思うけど? submoduleがあるからリポジトリの特定のディレクトリだけ 別リポジトリにするなんてことも簡単にできる それからsvnでリポジトリの一部を読み出し不可にするって apacheの設定の話をしてる? それapacheの機能だよね? 横だがsubmoduleはアンチパターン的な扱いになってきてなかったっけ >>533-534 プロジェクトとかシステムの一部のソースは外注さんには公開しないと言うのは別に珍しい話ではない アクセス制御のために別リポジトリにするのは本末転倒 あと Apache の機能で Subversion の機能じゃないじゃんとか子供みたいなこと言うのは恥ずかしくないのか? > あと Apache の機能で Subversion の機能じゃないじゃんとか子供みたいなこと言うのは恥ずかしくないのか? いいや? Apacheの機能を使ってもいいというのであれば gitでも同じことはできる。 > プロジェクトとかシステムの一部のソースは外注さんには公開しないと言うのは別に珍しい話ではない 公開するものだけを渡せばいいだけの話 公開しないものと公開するものを同じリポジトリに入れる必要がない。 > アクセス制御のために別リポジトリにするのは本末転倒 それこそ別リポジトリにするべきことだろう。 別リポジトリににすればいいだけなのに、 公開しないものを同じリポジトリに入れて アクセス制御するほうが本末転倒だろう。 プロジェクトで要求するような詳細な権限管理はGitHubみたいなアプリケーション側ですることでSCMの責務ではない 以上 >>538 > > アクセス制御のために別リポジトリにするのは本末転倒 > それこそ別リポジトリにするべきことだろう。 時系列を考えないと。 最初は全て同一リポジトリで社内ユーザなら誰でも見られるようにする。 その後、一般公開したり、一部を外部に開発依頼することになったりするときに、全部を公開するのがまずいとなる。 そういうときに、権限管理があったら便利だよねってこと。 最初から、将来起こりえるだろう事象を見越して、リポジトリを分割管理する方が本末転倒だと思うけどね。 最初は全て同一リポジトリで社内ユーザなら誰でも見られるようにする。 その後、一般公開したり、一部を外部に開発依頼することになったりするときに、 公開するものだけをまとめたほうがいいだろう? アクセス禁止がデフォルト設定 公開したいところだけ、別リポジトリにまとめる リポジトリをアクセス許可にして制限するというやり方では ミスしやすい >>541 どちらがベターかはケースバイケースでしょう。 あなたがべき論でもって、権限管理方式を全否定しているからレスしただけ。 もともと「社内だけで使えるリポジトリ」と思っていたわけで、 どこに何をおいても社内だけだから安全だと思ってしまう。 「社内だけで使えるリポジトリ」の一部を社外にも公開しますよと 通知した所で、忘れる可能性がある。 その一部に間違えて、公開してはいけない情報を入れてしまったら? そうなるから「社内だけで使えるリポジトリ」を あとから変更するというのはやってはいけない。 「社内だけで使えるリポジトリ」は将来に渡っても 社内だけにしておかないといけない。 そうすると当然、社外とも共有するリポジトリを作るという話になる。 もちろん最初に作るわけじゃない。 必要になった時点で作ればいいだけ。 必要になった時点で必要な権限で新しいリポジトリを作る。 最初から公開するものとして作っているのだから間違えることもない。 別リポジトリにすることは、安全に公開範囲を決める方法となる いちいち、このディレクトリって、誰が見れるんだっけ? などと気にする必要もなくなる。 >>542 いずれのケースでもリポジトリを分けるほうがベター subversionを使っていたとしてもリポジトリを分けたほうが良い >>543 そういうこと言い始めたら、ファイルシステム全体で権限管理しているLinuxなんて信用ならんってことになりませんかね。 ならないな。 ユーザーごとにディレクトリ別れているわけだし そう、なりませんよね。 だったら、もしgitにも権限管理機能があったら、やはり同じように信頼できるやり方ができるんじゃないですかね。 ソースコードの場合は、原則として リポジトリの全てがないとビルドできないのだから ディレクトリの一部が見れないという方式は取れない。 もし別々にビルドできるのであれば、 それは別のリポジトリにする方が良い モジュールの独立性を高くできる。 モジュールの時点で独立しているので、 ソースコードの一部を隠すという発想よりも 安全に運用できる。 >>537 使っていいからやり方教えて >>538 アクセス権限の変更が必要になる度にリポジトリの構成を変えるの? なかなか小学生らしい斬新な発想ですね w >>539 github ならできるの? 非公開の情報を間違ったディレクトリに突っ込む >>543 みたいな間抜けな奴は同じ情報を間違ったリポジトリにも突っ込むと思った方がいい そもそもそう言う間抜けに書き込み権限を与えるなよ w >>549 > ソースコードの場合は、原則として > リポジトリの全てがないとビルドできないのだから そんなことない。 メインアプリ+プラグイン/ライブラリ複数を一度のビルドでコンパイルするケースは結構ある。 出力されるのが、LM + .so複数みたいな。 >>554 一部だけビルドできるってことは、別のリポジトリにできるということ。 ならば、そうすればいいだけの話 >>555 > 一部だけビルドできるってことは、別のリポジトリにできるということ。 なるほど、ここに誤解があるのか。 「一部だけビルドできる」というのと「別のリポジトリにできる」というのはイコールじゃない場合が多い。 両者に依存関係がある場合ね。 簡単に分割できるのは、ビルドが不要な言語に多いんじゃないか? それは一部だけビルドできると言っていいのか…? あとそれってsvnでアクセス権設定しても同じように困るんじゃないの? >>557 > それは一部だけビルドできると言っていいのか…? まあ、こんな感じですかね。 foreach dir in subdirs cd dir; exec build_script end > あとそれってsvnでアクセス権設定しても同じように困るんじゃないの? subdirのいくつかが欠けていても、それは単にビルドされないだけですね。 あと、svnでできるかどうかは知りません。 とういか、別にそんな細かい話したいわけじゃなくて、リポジトリの一部をomitして提供、 あるいは一部のみ提供する必要があったとき、リポジトリを分割するだけが解じゃなくて、 権限設定機能があるならそれで済み場合もあるってこと。 なぜだか、それに強行に反対する人(たち?)がいるようで。 >なぜだか、それに強行に反対する人(たち?)がいるようで。 逆じゃないの gitじゃアクセス権出来ないから使えない状況がある(>>525 )って所が発端で、リポジトリ分ければ良いじゃんって人とリポジトリ分けられないじゃんって人が言い合ってたのが今の流れでしょ >>560 > 逆じゃないの そこも認識が違ってますね。 他の人はともかく、俺はSCM一般の話をしてたつもり。 > リポジトリ分けられないじゃん いや、そんな人いないと思うけど・・・。 git固有の話をするなら、モジュールを分割してsubmoduleで扱う方式だと、そのリポジトリの 利用者全員に影響を与えてしまうというデメリットがあるね。 リポジトリ分けたい人は分ければいい 俺はアクセス権のためにいちいちリポジトリ分けたりするのは本末転倒って思ってるからそんなことをしないだけ >>562 ですねぇ。 この話題ももう終わりだろうから、一つだけコメントしておこう。 >>533 > 全てのプロジェクトを一つのリポジトリに入れるとかいう > アホな使い方 googleはそうしてますね。 >>562 > 俺はアクセス権のためにいちいちリポジトリ分けたりするのは本末転倒 いや、どこが "本末" が "転倒" してるんだ?って話なんだが。 重要なのはアクセス権が違うのだから、きちんと役割を分けましょうということだろう? リポジトリを分ければ、きちんと役割が分かれるのだから 本末は転倒してないだろ? やり方が複数あるってだけだよ。 リポジトリごとに分ければ、誰がそこにアクセスできるのか明確になるし、 githubなんかの情報共有でもリポジトリが別れているから、 issueなどに書かれた見せてはいけない情報だって見れなくできる。 メリットのほうが大きいと思うが? 逆に聞きたいんだが、ファイルのアクセス権に対応したチケット管理ツールとかあるの? このディレクトリに関するチケットは見せないみたいな >>559 たぶん、「権限設定機能」の設定が無駄に複雑な機能になる。 (>>565 の話にも関係してるけど) それからsvnにあるのはアクセス権の機能じゃないからな。 svnにあるのはリポジトリの特定ディレクトリ以下のみをチェックアウトできる機能だけ ユーザー登録をsvnに設定するわけじゃない。apacheなどの設定 バージョン管理ソフト自体にアクセス権の機能をつけたら無駄に複雑になる。 本末転倒というならば、むしろこっちの方だろう。 アクセス権を実現するためだけに、apacheなどと連携しなければいけない。 リポジトリそのものを分ければ、git単体でアクセス権を実現できるのに アクセス権を実現するためだけに、ユーザー管理用のサーバーが必要になってしまう。 ちなみに、 > svnにあるのはリポジトリの特定ディレクトリ以下のみをチェックアウトできる機能 があるために、svnではいちいちブランチ切るのに長いディレクトリ名を指定したりして 面倒になってしまっている。 authzはsvnサーバーの設定じゃないというのか? >>564 > 重要なのはアクセス権が違うのだから、きちんと役割を分けましょうということだろう? 意味不明 役割とアクセス権は関連がある時もあるが基本的には別々の話 >>566-567 何で話をループさせたがるんだろう? > あと Apache の機能で Subversion の機能じゃないじゃんとか子供みたいなこと言うのは恥ずかしくないのか? せめて > >>537 > 使っていいからやり方教えて > >>539 > github ならできるの? に回答してからにしなよ まだ終わらないんですかね。 >>564 > やり方が複数あるってだけだよ。 「分けるべし」というべき論じゃないのなら、それで終了ですね。 > リポジトリを分ければ、きちんと役割が分かれるのだから 例えば、アクセス権がが違うユーザを登録する必要があるから、redmineを別サーバに建てて既存コンテンツを分割したりしますかと聞きたくなりますね。 本質的には、それと同じ事。 > たぶん、「権限設定機能」の設定が無駄に複雑な機能になる。 まぁ、gitをベースに考えるとそうかもしれませんね。 Perforceから入ったりすると、権限設定という概念の方が普通だと思うかも。 ちなみに、Perforceはこんな感じです。 > 「メタデータのみ参照可」「ファイルの内容まで参照可」「ファイルの更新可」 「ディポの更新可」 > 「システム管理用コマンドの実行可」等のアクセス制御を、ユーザ単位かつ ファイル単位に行う > ことができます。 > ユーザの指定は、PERFORCEが独自に管理するグループの指定で行うことも可能ですし、 > ファイルに指定には "*" や "..." 等のワイルドカードも指定可能ですので、 細かい設定も簡単に > 実現できます。 http://www.toyo.co.jp/ss/faq/detail/id=7208 デフォルトが全アクセス可で、駄目な奴だけ禁止するブラックリスト方式も、 デフォルトが全アクセス不可で、いい奴だけ登録するホワイトリスト方式もとれます。 そんな設定するくらいならリポジトリ分けた方がよっぽど簡単じゃん。 外出先でもすぐに使用できる 1CDバージョン管理システム的なものないかな USBブートができないマシンでもCDブートならできそうだから リポジトリはUSBで たとえば--prefix=/mnt/mygitでビルドしておいて、使うときはそこへmountすればいいんでない >>583 >>286 の回りではってことだろ 井の中の蛙は自分の回りが平均だから Sourceforge.netでCVSのサポートが終了するらしいが そもそもCVSってSourceForgeでまだ使えたんだ https://sourceforge.net/blog/decommissioning-cvs-for-commits/ 使いやすくはないだろう。 いろいろできることの代償かもしれないけど。 できることがあきらかだったsvnのほうがわかりやすくはあった。 >できることがあきらかだったsvnのほうがわかりやすくはあった。 VisualStudioとかのIDEって使いにくいよなよな make最強 制御機械のソースコードをバージョン管理したいのだけど、どれがお勧めですかね? ソースコードといっても.NETやCみたいにテキストで開いても見れず1ファイルで保存されます。 プログラム作成ソフトもメーカー専用のものです。 svnを使ってみることにします。 とりあえずVisualSVN Serverをインストールしてみたけど、さっぱり分からんかった。 ・客A/納入先X/制御機器 ・客A/納入先Y/制御機器 ・客B/納入先Z/制御機器 といった感じでリポジトリを作成したいけど無理なのかしら? 階層構造は無理だからリポジトリ名で工夫するしかないよ >>603 それリポジトリ分ける必要あるの? リポジトリをひとつにして中にその階層構造入れるんじゃダメなの? >>604 階層構造は無理なんですね。 "_"で繋ぐとかで工夫してみます。 >>605 リポジトリ=プロジェクト(客Aの納入先Xに対する制御機器)単位で 作成するものだと思い込んでました。 そういった方法もありですね。 全部別々のリポジトリにしておいて それとは別にsvn:externalsで階層構造として見せる用のリポジトリを作ればいいんじゃね >>606 プロジェクト毎にリポジトリ分けるか、全部一個のリポジトリに詰め込むかはメリット/デメリットがあるのでとりあえずこのあたりを読んでおいた方がいいかも http://jtdan.com/vcs/svn/svn-book/svn.reposadmin.projects.html#svn.reposadmin.projects.chooselayout (バージョン古いけどここら辺の考え方は変わってないから) まあ管理者コマンド使えばリポジトリを分割したりマージしたりもできるからあまり悩まずにまず使ってみればいいと思う バージョンを1.9から1.10にしたら、バージョンダウンですか?ってお客さんにツッコまれた。 >>609 てか1.10ってまだalpha版じゃねーの? リポジトリの仕組みについて質問です。 gitはファイル自体、svnは差分を保持している(最初のリビジョンだけファイル自体?) というような情報をどかっで見たんですが、 差分ということは、たとえばリビジョン10のファイルをチェックアウトしようとしたら 内部的にはリビジョン1のファイルにリビジョン2〜9の差分情報(パッチ)を 摘要してるってことでしょうか? その仕組みだとリビジョンが大きくなったら困る(パッチ摘要に時間かかりすぎる)ような… 結局、gitもsvnも全てのリビジョンのファイル自体をリポジトリに保持 してるんですかね? だとしたら、リビジョンの数(コミットした回数)だけリポジトリのサイズが大きくなるの? (10MBのファイルを100回コミットしたら1GB?) このあたりのこと詳しく解説してるサイトないですか? ファイルの中身が変わってないなら重複して保持する必要ねーだろ? >>614 変わってないファイルは保持する必要ないですね。 変わっていたら全てのリビジョンのファイルを持つ? [リビジョン1] 1 [リビジョン2] 1 2 〜〜〜 [リビジョン100]※ 1 2 … 99 100 って数字を1行ずつ増やしてコミットしたあったとして リビジョン100をチェックアウトするときに※の状態のファイルが用意されている状態なのか 差分摘要して※の状態のファイル作るのか という質問です。 どっちも、ローカルマシンにリポジトリを簡単に作れるんだし、作って中身を見てみたら。 そういうところまで気になるのなら、少しは自分で実践しないと。 ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の 両院で、改憲議員が3分の2を超えております。 『憲法改正国民投票法』、でググってみてください。国会の発議は すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 役に立つかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 9HEXK アホが、如何にアホであるかについて議論することは時間の浪費である。 チンポスター ヤッたその日から チンポの虜に 虜になりました♪ Sapling入れてみたけど、GitHub使いたいMercurialユーザーにはちょうどいいかもしれない コマンド体系はMercurialに近いのに、サーバーに無料のGitHub使えてうれしい >>637 saplingは最初からGUIついてるぞ sl web で起動する たまに同じコードが飛び飛びに複数行作られてんだが なにこれ read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる