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

**デフォルトの名無しさん** · 2014/02/23(日) 18:17:11.03

バージョン管理システムについて語りましょう

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

**デフォルトの名無しさん** · 2016/11/08(火) 12:40:00.00

>>489
cvs「おい！お前は……」
rcs「関係ねえ！」

**デフォルトの名無しさん** · 2016/11/09(水) 12:57:09.53

SCCS「...」

**デフォルトの名無しさん** · 2016/11/09(水) 14:08:17.25

>>491
TeamWare「俺には、お前しか居ねえよ」

**デフォルトの名無しさん** · 2016/11/10(木) 09:27:15.68

>>489
tsv「俺たちはお呼びじゃない」

**デフォルトの名無しさん** · 2016/11/15(火) 20:29:13.95

gitもここ数年意味ない機能追加ばかりだが

**デフォルトの名無しさん** · 2016/11/16(水) 02:41:12.10

gitスレ人いなくなっててわろす

**デフォルトの名無しさん** · 2016/11/16(水) 04:05:09.28

じゃ今なにが主流なん？

**デフォルトの名無しさん** · 2016/12/19(月) 12:46:04.24

水炊きごはん

**デフォルトの名無しさん** · 2016/12/26(月) 08:28:54.29

tortoisegit
とか初心者でも使いやすいんじゃないかね。

**デフォルトの名無しさん** · 2017/02/02(木) 00:11:38.54

↓のブログによると、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/

**デフォルトの名無しさん** · 2017/02/02(木) 02:19:43.40

不要なパッチを削除できるあたりdarcsのほうが好きだったのでうまく成長してほしい

**デフォルトの名無しさん** · 2017/02/02(木) 08:13:39.05

内部での保存方法はgitこそスナップショットでsvnは(逆方向の)patch-basedだろ？
少なくともgitがチェンジセット型ってこたーない。gitでの差分の見え方なんて後からオプション次第で変わるし

**デフォルトの名無しさん** · 2017/02/02(木) 12:54:35.84

うむ

**デフォルトの名無しさん** · 2017/02/07(火) 20:30:10.92

SVN脳の問題点というかSVN系統の人が怖がってるのは結局
SVN 系統では commit と push が同一になっているから
merge を極端に恐れてるってだけじゃないかと。

**デフォルトの名無しさん** · 2017/02/07(火) 20:57:37.50

svnだって、commitするときに他の人が先に変更を加えていたら
updateしてからcommitしなおす事になるし、このときローカルでちょこちょこ辻褄合わせをする作業は
git pull --rebaseと同じはずなんだけどな

**デフォルトの名無しさん** · 2017/02/08(水) 12:17:33.93

コミット時にコンフリクトする集中型の方が恐怖だけどな。
分散型は、いったんコミットした後で改めてマージするんで、
わけわからなくなっても、何度でもやり直せる。

**デフォルトの名無しさん** · 2017/02/08(水) 23:27:00.23

いやだからその svn での恐怖心を
なんだか知らんが git を使ってても引きづってるってことなんじゃないかと。

**デフォルトの名無しさん** · 2017/02/13(月) 15:12:37.22

一番の恐怖は、コンフリクトが判明するのが後のタイミングになるってことなんだよ
Excelとかマージできないバイナリ系ファイルも一緒に管理してるから……

**デフォルトの名無しさん** · 2017/02/13(月) 17:53:09.58

混ぜるな危険

**デフォルトの名無しさん** · 2017/02/26(日) 08:37:46.10

これヤバいな

https://arstechnica.com/security/2017/02/watershed-sha1-collision-just-broke-the-webkit-repository-others-may-follow/

**デフォルトの名無しさん** · 2017/03/09(木) 08:20:28.94

記事のコメントを見ると
WebKitのSVNリポジトリで、ハッシュ衝突したPDFがキャッシュ・ポイズニング攻撃に使えるかテストするために
ハッシュ衝突したPDFをコミットしたら
リポジトリがあぼ～んってなったと言う訳か

てかWebKitってまだSVN使ってたの？

**デフォルトの名無しさん** · 2017/03/09(木) 08:21:28.28

gitは仮に衝突しても大丈夫みたいな事言ってたけど
どんな感じなのかは知らない

**デフォルトの名無しさん** · 2017/03/09(木) 09:01:25.72

分散型は、一旦コミットした後でマージするから、
最悪マージ前の双方のバージョンは残ってるってことじゃないの？

**デフォルトの名無しさん** · 2017/03/09(木) 13:23:54.33

読んでないけどハッシュが衝突する奇跡が起きたらあぼーんしても不思議で無いね

**デフォルトの名無しさん** · 2017/03/09(木) 14:29:50.48

リーナス・トーバルズがハッシュ衝突について語ってるGoogle+の投稿
https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL

別のハッシュアルゴリズムを使う計画はあるらしい

Gitを修正してmitigation(緩和？)できるってのはどういう事だろう

実際は衝突する事なんてそんな無いってのはまあ分かる

**デフォルトの名無しさん** · 2017/03/09(木) 19:22:25.79

>>513
悪意を持った誰かが公開されているpdfをコミットしただけでぶっ壊せる
もしくはWebkitのように、システムの振る舞いを調べるテスト目的でコミットしても壊れる

**デフォルトの名無しさん** · 2017/03/09(木) 19:55:22.59

>>515
そのうち SHA-256 とかにするんじゃね

**デフォルトの名無しさん** · 2017/03/09(木) 21:07:54.65

切り替えは相当大変だろうな

**デフォルトの名無しさん** · 2017/03/09(木) 22:08:04.59

>>513
奇跡じゃないって話だろ

**デフォルトの名無しさん** · 2017/03/09(木) 23:11:06.25

>>517
旧バージョンでダンプして新バージョンでロードするだけでしょ
いままででもリポジトリのバージョン変わったらそうやってたし

**デフォルトの名無しさん** · 2017/03/20(月) 10:28:05.47

まあバージョン管理程度なら大した問題にはならんだろ。
ちょっとしたスクリプトを一枚かませばいいくらいの話。

**デフォルトの名無しさん** · 2017/03/22(水) 01:28:09.68

>>520
問題になったやん

**デフォルトの名無しさん** · 2017/03/23(木) 00:11:04.47

嫌がらせならハッシュ衝突なんて凝ったことしなくてもできる訳で
嫌がらせ以上のことが可能かといえばそういう話も無く

**デフォルトの名無しさん** · 2017/03/26(日) 09:54:40.33

>>487
未だに使ってるとこあるよ。あり得ないと思った

**デフォルトの名無しさん** · 2017/03/26(日) 10:18:41.36

未だにVSS使ってる魔境もあるぞ

**デフォルトの名無しさん** · 2017/03/26(日) 11:52:30.59

>>523
普通に使ってるけど？
git だとアクセス制限とかかけられなかったりするから会社では使えないケースもあるし

**デフォルトの名無しさん** · 2017/03/26(日) 12:27:51.46

>>525
かけられる。かける方法を知らないお前が馬鹿なだけ

**デフォルトの名無しさん** · 2017/03/26(日) 18:51:27.67

https://git-scm.com/book/ja/v1/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-Gitolite
のことを言ってるのかな？
それなら知ってるから無駄に煽るな

**デフォルトの名無しさん** · 2017/03/26(日) 19:12:03.88

東京電力の新会長に日立製作所の人間が就任

**デフォルトの名無しさん** · 2017/03/26(日) 20:40:16.26

>>526
馬鹿を晒した気分はどうよ？

**デフォルトの名無しさん** · 2017/03/26(日) 20:54:59.26

>>529
かけられたが？

**デフォルトの名無しさん** · 2017/03/27(月) 01:00:14.02

素人でスマンが、実際のところsubversionではできてgitではできないアクセス制限ってどんなのがあるの？

**デフォルトの名無しさん** · 2017/03/27(月) 11:09:36.85

>>531
リポジトリの一部を読み出し不可にすること

**デフォルトの名無しさん** · 2017/03/27(月) 11:20:28.28

>>532
svnだとリモートリポジトリを作るのが面倒（？）とかいう理由で
全てのプロジェクトを一つのリポジトリに入れるとかいう
アホな使い方をしている例をしていたけど、そういう話？

リポジトリの一部を読み出し不可にするのであれば
その部分だけ別リポジトリに分ければ良いと思うけど？
submoduleがあるからリポジトリの特定のディレクトリだけ
別リポジトリにするなんてことも簡単にできる

**デフォルトの名無しさん** · 2017/03/27(月) 11:21:50.59

それからsvnでリポジトリの一部を読み出し不可にするって
apacheの設定の話をしてる？

それapacheの機能だよね？

**デフォルトの名無しさん** · 2017/03/27(月) 12:23:49.25

横だがsubmoduleはアンチパターン的な扱いになってきてなかったっけ

**デフォルトの名無しさん** · 2017/03/27(月) 12:25:01.61

>>533-534
プロジェクトとかシステムの一部のソースは外注さんには公開しないと言うのは別に珍しい話ではない
アクセス制御のために別リポジトリにするのは本末転倒
あと Apache の機能で Subversion の機能じゃないじゃんとか子供みたいなこと言うのは恥ずかしくないのか？

**デフォルトの名無しさん** · 2017/03/27(月) 14:24:08.92

> あと Apache の機能で Subversion の機能じゃないじゃんとか子供みたいなこと言うのは恥ずかしくないのか？

いいや？ Apacheの機能を使ってもいいというのであれば
gitでも同じことはできる。

**デフォルトの名無しさん** · 2017/03/27(月) 14:27:12.05

> プロジェクトとかシステムの一部のソースは外注さんには公開しないと言うのは別に珍しい話ではない
公開するものだけを渡せばいいだけの話
公開しないものと公開するものを同じリポジトリに入れる必要がない。

> アクセス制御のために別リポジトリにするのは本末転倒
それこそ別リポジトリにするべきことだろう。

別リポジトリににすればいいだけなのに、
公開しないものを同じリポジトリに入れて
アクセス制御するほうが本末転倒だろう。

**デフォルトの名無しさん** · 2017/03/27(月) 15:01:35.22

プロジェクトで要求するような詳細な権限管理はGitHubみたいなアプリケーション側ですることでSCMの責務ではない
以上

**デフォルトの名無しさん** · 2017/03/27(月) 15:19:58.53

>>538
> > アクセス制御のために別リポジトリにするのは本末転倒
> それこそ別リポジトリにするべきことだろう。
時系列を考えないと。

最初は全て同一リポジトリで社内ユーザなら誰でも見られるようにする。
その後、一般公開したり、一部を外部に開発依頼することになったりするときに、全部を公開するのがまずいとなる。
そういうときに、権限管理があったら便利だよねってこと。

最初から、将来起こりえるだろう事象を見越して、リポジトリを分割管理する方が本末転倒だと思うけどね。

**デフォルトの名無しさん** · 2017/03/27(月) 16:41:44.76

最初は全て同一リポジトリで社内ユーザなら誰でも見られるようにする。
その後、一般公開したり、一部を外部に開発依頼することになったりするときに、
公開するものだけをまとめたほうがいいだろう？

アクセス禁止がデフォルト設定
公開したいところだけ、別リポジトリにまとめる

リポジトリをアクセス許可にして制限するというやり方では
ミスしやすい

**デフォルトの名無しさん** · 2017/03/27(月) 16:48:12.04

>>541
どちらがベターかはケースバイケースでしょう。
あなたがべき論でもって、権限管理方式を全否定しているからレスしただけ。

**デフォルトの名無しさん** · 2017/03/27(月) 16:48:57.03

もともと「社内だけで使えるリポジトリ」と思っていたわけで、
どこに何をおいても社内だけだから安全だと思ってしまう。

「社内だけで使えるリポジトリ」の一部を社外にも公開しますよと
通知した所で、忘れる可能性がある。
その一部に間違えて、公開してはいけない情報を入れてしまったら？

そうなるから「社内だけで使えるリポジトリ」を
あとから変更するというのはやってはいけない。

「社内だけで使えるリポジトリ」は将来に渡っても
社内だけにしておかないといけない。

そうすると当然、社外とも共有するリポジトリを作るという話になる。
もちろん最初に作るわけじゃない。
必要になった時点で作ればいいだけ。

必要になった時点で必要な権限で新しいリポジトリを作る。
最初から公開するものとして作っているのだから間違えることもない。
別リポジトリにすることは、安全に公開範囲を決める方法となる

いちいち、このディレクトリって、誰が見れるんだっけ？
などと気にする必要もなくなる。

**デフォルトの名無しさん** · 2017/03/27(月) 16:49:44.27

>>542
いずれのケースでもリポジトリを分けるほうがベター
subversionを使っていたとしてもリポジトリを分けたほうが良い

**デフォルトの名無しさん** · 2017/03/27(月) 16:55:09.24

>>543
そういうこと言い始めたら、ファイルシステム全体で権限管理しているLinuxなんて信用ならんってことになりませんかね。

**デフォルトの名無しさん** · 2017/03/27(月) 17:03:34.11

>>545
ならねーよ

**デフォルトの名無しさん** · 2017/03/27(月) 17:04:29.56

ならないな。

ユーザーごとにディレクトリ別れているわけだし

**デフォルトの名無しさん** · 2017/03/27(月) 17:09:35.26

そう、なりませんよね。

だったら、もしgitにも権限管理機能があったら、やはり同じように信頼できるやり方ができるんじゃないですかね。

**デフォルトの名無しさん** · 2017/03/27(月) 17:31:02.44

ソースコードの場合は、原則として
リポジトリの全てがないとビルドできないのだから
ディレクトリの一部が見れないという方式は取れない。

もし別々にビルドできるのであれば、
それは別のリポジトリにする方が良い
モジュールの独立性を高くできる。

モジュールの時点で独立しているので、
ソースコードの一部を隠すという発想よりも
安全に運用できる。

**デフォルトの名無しさん** · 2017/03/27(月) 18:24:55.49

>>537
使っていいからやり方教えて

>>538
アクセス権限の変更が必要になる度にリポジトリの構成を変えるの？
なかなか小学生らしい斬新な発想ですね w

>>539
github ならできるの？

**デフォルトの名無しさん** · 2017/03/27(月) 18:52:07.74

>>548
論理飛躍しすぎ。

**デフォルトの名無しさん** · 2017/03/27(月) 19:35:47.70

非公開の情報を間違ったディレクトリに突っ込む >>543 みたいな間抜けな奴は同じ情報を間違ったリポジトリにも突っ込むと思った方がいい
そもそもそう言う間抜けに書き込み権限を与えるなよ w

**デフォルトの名無しさん** · 2017/03/27(月) 21:23:26.89

alt gitまだー？

**デフォルトの名無しさん** · 2017/03/28(火) 11:09:32.22

>>549
> ソースコードの場合は、原則として
> リポジトリの全てがないとビルドできないのだから
そんなことない。
メインアプリ＋プラグイン/ライブラリ複数を一度のビルドでコンパイルするケースは結構ある。
出力されるのが、LM + .so複数みたいな。

**デフォルトの名無しさん** · 2017/03/28(火) 21:26:42.96

>>554
一部だけビルドできるってことは、別のリポジトリにできるということ。
ならば、そうすればいいだけの話

**デフォルトの名無しさん** · 2017/03/29(水) 10:34:46.63

>>555
> 一部だけビルドできるってことは、別のリポジトリにできるということ。
なるほど、ここに誤解があるのか。

「一部だけビルドできる」というのと「別のリポジトリにできる」というのはイコールじゃない場合が多い。
両者に依存関係がある場合ね。

簡単に分割できるのは、ビルドが不要な言語に多いんじゃないか？

**デフォルトの名無しさん** · 2017/03/29(水) 10:55:14.48

それは一部だけビルドできると言っていいのか…？
あとそれってsvnでアクセス権設定しても同じように困るんじゃないの？

**デフォルトの名無しさん** · 2017/03/29(水) 13:17:13.75

>>557
> それは一部だけビルドできると言っていいのか…？
まあ、こんな感じですかね。
foreach dir in subdirs
　cd dir; exec build_script
end

> あとそれってsvnでアクセス権設定しても同じように困るんじゃないの？
subdirのいくつかが欠けていても、それは単にビルドされないだけですね。
あと、svnでできるかどうかは知りません。

**デフォルトの名無しさん** · 2017/03/29(水) 13:25:46.88

とういか、別にそんな細かい話したいわけじゃなくて、リポジトリの一部をomitして提供、
あるいは一部のみ提供する必要があったとき、リポジトリを分割するだけが解じゃなくて、
権限設定機能があるならそれで済み場合もあるってこと。

なぜだか、それに強行に反対する人（たち？）がいるようで。

**デフォルトの名無しさん** · 2017/03/29(水) 16:15:13.03

>なぜだか、それに強行に反対する人（たち？）がいるようで。
逆じゃないの

gitじゃアクセス権出来ないから使えない状況がある(>>525)って所が発端で、リポジトリ分ければ良いじゃんって人とリポジトリ分けられないじゃんって人が言い合ってたのが今の流れでしょ

**デフォルトの名無しさん** · 2017/03/29(水) 16:35:56.60

>>560
> 逆じゃないの
そこも認識が違ってますね。
他の人はともかく、俺はSCM一般の話をしてたつもり。

> リポジトリ分けられないじゃん
いや、そんな人いないと思うけど･･･。

git固有の話をするなら、モジュールを分割してsubmoduleで扱う方式だと、そのリポジトリの
利用者全員に影響を与えてしまうというデメリットがあるね。

**デフォルトの名無しさん** · 2017/03/29(水) 17:51:38.84

リポジトリ分けたい人は分ければいい
俺はアクセス権のためにいちいちリポジトリ分けたりするのは本末転倒って思ってるからそんなことをしないだけ

**デフォルトの名無しさん** · 2017/03/29(水) 18:25:33.13

>>562
ですねぇ。

この話題ももう終わりだろうから、一つだけコメントしておこう。
>>533
> 全てのプロジェクトを一つのリポジトリに入れるとかいう
> アホな使い方
googleはそうしてますね。

**デフォルトの名無しさん** · 2017/03/29(水) 21:33:57.72

>>562
> 俺はアクセス権のためにいちいちリポジトリ分けたりするのは本末転倒

いや、どこが "本末" が "転倒" してるんだ？って話なんだが。

重要なのはアクセス権が違うのだから、きちんと役割を分けましょうということだろう？
リポジトリを分ければ、きちんと役割が分かれるのだから
本末は転倒してないだろ？

やり方が複数あるってだけだよ。

リポジトリごとに分ければ、誰がそこにアクセスできるのか明確になるし、
githubなんかの情報共有でもリポジトリが別れているから、
issueなどに書かれた見せてはいけない情報だって見れなくできる。

メリットのほうが大きいと思うが？

逆に聞きたいんだが、ファイルのアクセス権に対応したチケット管理ツールとかあるの？
このディレクトリに関するチケットは見せないみたいな

**デフォルトの名無しさん** · 2017/03/29(水) 21:50:59.15

>>559
たぶん、「権限設定機能」の設定が無駄に複雑な機能になる。

**デフォルトの名無しさん** · 2017/03/29(水) 21:56:32.41

（>>565の話にも関係してるけど）

それからsvnにあるのはアクセス権の機能じゃないからな。
svnにあるのはリポジトリの特定ディレクトリ以下のみをチェックアウトできる機能だけ
ユーザー登録をsvnに設定するわけじゃない。apacheなどの設定
バージョン管理ソフト自体にアクセス権の機能をつけたら無駄に複雑になる。

本末転倒というならば、むしろこっちの方だろう。
アクセス権を実現するためだけに、apacheなどと連携しなければいけない。
リポジトリそのものを分ければ、git単体でアクセス権を実現できるのに
アクセス権を実現するためだけに、ユーザー管理用のサーバーが必要になってしまう。

**デフォルトの名無しさん** · 2017/03/29(水) 21:57:43.60

ちなみに、
> svnにあるのはリポジトリの特定ディレクトリ以下のみをチェックアウトできる機能
があるために、svnではいちいちブランチ切るのに長いディレクトリ名を指定したりして
面倒になってしまっている。

**デフォルトの名無しさん** · 2017/03/29(水) 22:32:33.69

は?

**デフォルトの名無しさん** · 2017/03/29(水) 22:34:05.79

authzはsvnサーバーの設定じゃないというのか？

**デフォルトの名無しさん** · 2017/03/30(木) 08:15:34.48

>>564
> 重要なのはアクセス権が違うのだから、きちんと役割を分けましょうということだろう？
意味不明
役割とアクセス権は関連がある時もあるが基本的には別々の話

**デフォルトの名無しさん** · 2017/03/30(木) 08:19:51.08

>>566-567
何で話をループさせたがるんだろう？

> あと Apache の機能で Subversion の機能じゃないじゃんとか子供みたいなこと言うのは恥ずかしくないのか？

せめて

> >>537
> 使っていいからやり方教えて
> >>539
> github ならできるの？

に回答してからにしなよ

**デフォルトの名無しさん** · 2017/03/30(木) 10:39:36.78

まだ終わらないんですかね。

>>564
> やり方が複数あるってだけだよ。
「分けるべし」というべき論じゃないのなら、それで終了ですね。

> リポジトリを分ければ、きちんと役割が分かれるのだから
例えば、アクセス権がが違うユーザを登録する必要があるから、redmineを別サーバに建てて既存コンテンツを分割したりしますかと聞きたくなりますね。
本質的には、それと同じ事。

> たぶん、「権限設定機能」の設定が無駄に複雑な機能になる。
まぁ、gitをベースに考えるとそうかもしれませんね。
Perforceから入ったりすると、権限設定という概念の方が普通だと思うかも。

**デフォルトの名無しさん** · 2017/03/30(木) 10:44:30.88

ちなみに、Perforceはこんな感じです。

> 「メタデータのみ参照可」「ファイルの内容まで参照可」「ファイルの更新可」「ディポの更新可」
> 「システム管理用コマンドの実行可」等のアクセス制御を、ユーザ単位かつファイル単位に行う
> ことができます。
> ユーザの指定は、PERFORCEが独自に管理するグループの指定で行うことも可能ですし、
> ファイルに指定には "*" や "..." 等のワイルドカードも指定可能ですので、細かい設定も簡単に
> 実現できます。
http://www.toyo.co.jp/ss/faq/detail/id=7208

デフォルトが全アクセス可で、駄目な奴だけ禁止するブラックリスト方式も、
デフォルトが全アクセス不可で、いい奴だけ登録するホワイトリスト方式もとれます。

**デフォルトの名無しさん** · 2017/03/30(木) 21:39:34.19

>>573
svnだとどんな感じ？

**デフォルトの名無しさん** · 2017/03/31(金) 00:44:40.10

そんな設定するくらいならリポジトリ分けた方がよっぽど簡単じゃん。

**デフォルトの名無しさん** · 2017/03/31(金) 07:28:27.46

無限ループ命令が発行されました

**デフォルトの名無しさん** · 2017/03/31(金) 13:38:36.99

なんにでも終わりはあるよ

**デフォルトの名無しさん** · 2017/03/31(金) 23:50:54.07

という事にしたい模様

**デフォルトの名無しさん** · 2017/04/01(土) 01:39:47.54

for(;;)
{}

**デフォルトの名無しさん** · 2017/05/02(火) 18:53:02.76

外出先でもすぐに使用できる
1CDバージョン管理システム的なものないかな
USBブートができないマシンでもCDブートならできそうだから
リポジトリはUSBで

**デフォルトの名無しさん** · 2017/05/02(火) 19:10:30.69

git

**デフォルトの名無しさん** · 2017/05/02(火) 21:27:53.12

たとえば--prefix=/mnt/mygitでビルドしておいて、使うときはそこへmountすればいいんでない

**デフォルトの名無しさん** · 2017/07/28(金) 15:24:24.41

>>286
七割は言いすぎかと

**デフォルトの名無しさん** · 2017/07/28(金) 17:13:24.86

1.7光年の彼方から乙

**デフォルトの名無しさん** · 2017/07/28(金) 21:50:15.87

>>583
>>286の回りではってことだろ
井の中の蛙は自分の回りが平均だから

**デフォルトの名無しさん** · 2017/08/12(土) 04:35:46.26

バージンはいいよね

**デフォルトの名無しさん** · 2017/08/12(土) 08:18:32.99

バージン管理か

**デフォルトの名無しさん** · 2017/08/12(土) 20:27:01.13

童貞おじさん、バージンを語る。

**デフォルトの名無しさん** · 2017/09/16(土) 12:19:01.07

Pijul 0.8　が出た模様。

**デフォルトの名無しさん** · 2017/10/31(火) 14:53:54.70

Sourceforge.netでCVSのサポートが終了するらしいが
そもそもCVSってSourceForgeでまだ使えたんだ

https://sourceforge.net/blog/decommissioning-cvs-for-commits/