バージョン管理システムについて語るスレ10
いまだに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にも権限管理機能があったら、やはり同じように信頼できるやり方ができるんじゃないですかね。