バージョン管理システムについて語るスレ10
まあバージョン管理程度なら大した問題にはならんだろ。 ちょっとしたスクリプトを一枚かませばいいくらいの話。 嫌がらせならハッシュ衝突なんて凝ったことしなくてもできる訳で 嫌がらせ以上のことが可能かといえばそういう話も無く >>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 read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる