Subversion r15

**デフォルトの名無しさん** · 2014/08/02(土) 17:20:57.62

Subversionはフリーなオープンソースのバージョン管理システムです。

公式HP
Apache Subversion
http://subversion.apache.org/

ようこそSubversion.JPコミュニティへ
http://www.subversion.jp/

**デフォルトの名無しさん** · 2014/08/26(火) 15:53:13.50

>>201
> 大抵みんなやり方が同じようになってきてるから、

そうなの？
新機能の実装をtrunkでがんがんやる派とそうじゃない派で、まず大きく二つに分かれる気がするけど。

**デフォルトの名無しさん** · 2014/08/26(火) 17:28:20.40

俺は1本のままで保守モード移行と同時にそこまでの履歴丸ごとコピーで別リポジトリに追い出してた@decade ago
1.x/trunk---t-2.x/trunk---t-3.x/trunk---t-4.x/trunk---
　　　　　　　　L-1.x　　　　　　L-2.x

**デフォルトの名無しさん** · 2014/08/26(火) 18:04:37.65

>>202
えーっと、その前者の方法、それもありじゃないって思える？

**デフォルトの名無しさん** · 2014/08/26(火) 18:53:32.91

trunkで開発すすめて特定の所からリリースブランチ作るって
やり方もあるよね。

**デフォルトの名無しさん** · 2014/08/26(火) 22:25:51.51

>>199
一歩先なのは認める
ただ、trunk/tag/branch も何もないところに比べれば半歩は進んでいるわけで、その間の何があれば best practice と言えるのか？って話。

>>200 とか http://danielkummer.github.io/git-flow-cheatsheet/index.ja_JP.htm の言ってることはわかるけど、運用をより具体的に決めてるだけとも言える。

**デフォルトの名無しさん** · 2014/08/26(火) 22:42:03.56

>>206
ベストプラクティスの意味が分からないって言ってるんだろうか。
> 運用をより具体的に決めてるだけとも言える。

**デフォルトの名無しさん** · 2014/08/26(火) 22:47:19.91

ベストベストって開発規模やコミット粒度によって何がベストかは違うだろ
統一見解なんて求めるのは無意味

**デフォルトの名無しさん** · 2014/08/26(火) 22:49:23.21

>>207
ベストプラクティスにもレベルがあるって話。
0/1 でしか考えられないの？

**デフォルトの名無しさん** · 2014/08/26(火) 22:55:05.25

>>208
いや、それを言い出したらきりがない。
六割とか八割の人が便利に使えるならそれはそれでベストプラクティスでいいと思うよ。
ただ、ベストプラクティスはこれしか認めんとか言い出したら、それはおかしいよね。

**デフォルトの名無しさん** · 2014/08/27(水) 00:16:36.50

>>210
じゃあどうなればベストプラクティスなんだ？これは運用を決めてるだけじゃないかなんていう
ばかげたレスをしなければいいのに。

二転三転してんよ。

**デフォルトの名無しさん** · 2014/08/27(水) 00:20:37.72

>>208
多くの人が困った出来事に見舞われなくて済むように作られた集合知だから、
ある程度は統一されるよ。

>>202 の前者なんてのは痛い目を見て二度とするもんかと心に誓う手法でしかない。

**デフォルトの名無しさん** · 2014/08/27(水) 01:21:09.81

1.9で予定されていた機能の殆どは延期
減り続けるユーザー
MLへの投稿も減少の一途
Apacheからも邪魔者扱い

どうすんの？

**デフォルトの名無しさん** · 2014/08/27(水) 07:38:51.42

>>211
ひょっとして壊滅的に理解力がないとか？ w
俺は git flow も、trunk/tag/branch もレベルは違うが両方ともベストプラクティスだと言う立場だよ。
なので、>>194 に
> 確立されていない。
と言い切る理由を聞いてるだよ。

まあ、
> >>202 の前者なんてのは痛い目を見て二度とするもんかと心に誓う手法でしかない。
とか言う人には、理解できないかな。

**デフォルトの名無しさん** · 2014/08/27(水) 07:42:25.58

>>213
別に今のまま使えばいいだけでしょ。
そのうちもっと便利なものが出てくれば移行すればいいだけだし。
>>213 が subversion の行く末を案じて、何とかしようと思ってるならがんばれーって応援するけどね。

**デフォルトの名無しさん** · 2014/08/27(水) 07:44:19.56

svnで言うtrunk/tag/branchはこう使ったらいいぜ！
ってのがgit-flowなんですけど…

**デフォルトの名無しさん** · 2014/08/27(水) 10:54:18.36

>>214
いやだから「git-flowのような」svnの運用方法はまだ確立されてないよねって話なんですけど。

**デフォルトの名無しさん** · 2014/08/27(水) 11:39:27.80

>>217
FreeBSDとか大きいプロジェクトならあるだろ。
お前が知らないだけ。

**デフォルトの名無しさん** · 2014/08/27(水) 12:17:18.99

だから「ような」ってなに？
何を満たせばお前さんが言う「git flow のような運用方法」になるんだ？
って話をしてるんだが。

**デフォルトの名無しさん** · 2014/08/27(水) 12:43:28.37

>>219
例えば、Subversionを初めて導入するチームが、とりあえずの指針として使えるような運用方法。
初めて導入する場合、trunk/branches/tagsを作るところまでは良いが、おそらくそこで途方に
暮れることになるだろう。
つか、git-flowとかGitHub Flow知ってる？

**デフォルトの名無しさん** · 2014/08/27(水) 13:47:44.30

>>217
新規開発ならまだしも、trunkで"新機能"開発を認めるような人って、
develop featureブランチを作らないことで何が起こるかしらない人かもしんない。
そうなら説明しても理解できないと思う。

git flowは使ったことないけど、ブランチ構成管理の図を見る限りsvnでも大抵同じ構成でやってるよ。
svnやgit、他のVCSひっくるめてブランチ管理のベストプラクティスってのはもうあって、
それをサポートするための実装の一つがgit flowなんじゃないかなぁと思うけど、gitユーザから見るとどうですかね。

**デフォルトの名無しさん** · 2014/08/27(水) 13:56:08.31

>>220
> おそらくそこで途方に暮れることになるだろう。

ハンドブックも読まないようなチームならそうだろうね。

http://svnbook.red-bean.com/en/1.7/svn.branchmerge.maint.html#svn.branchmerge.maint.layout

> つか、git-flowとかGitHub Flow知ってる？

>>206 のリンク先の内容では不足なのか？

**デフォルトの名無しさん** · 2014/08/27(水) 14:01:53.23

>>221
思い込みが激しすぎる
trunk で新機能開発してるところもあるし、それでちゃんと回ってる

**デフォルトの名無しさん** · 2014/08/27(水) 14:32:21.64

>>222
もう、どう言ったらいいのか・・・。

svnbookで説明されてるされてることを、実際にどう運用するのが良いのかの指針となるような
git-flowやGitHub Flowのような運用方針が、人口に膾炙された形でsvn界隈にあるのかって
ことで、それはまだないでしょということなんだけど、わかんないかな。

長年svnを使ってれば、そりゃ自分たちにフィットした運用方針があるだろうけど、他SCMから来た人とか
初めてのSCMとしてsvnを選んだ（選ばざるをえなかった）人たちが、どう運用を開始すれば良いのかの
情報ってそれほどないでしょ。
そういうのがあれば、>>160にこれを参考にするといいよってURLを示すだけで終了でしょ。

**デフォルトの名無しさん** · 2014/08/27(水) 15:01:37.11

>>222
よりによってそれを貼るって、レベルが違いすぎて話にならない。ヨチヨチじゃねえか。

>>223
ちゃんと回ってるうちはそれでいいと思うもんなんだよ。

**デフォルトの名無しさん** · 2014/08/27(水) 18:44:05.74

>>224
svnbook に書いてなくて git flow で決められてる方針とやらを書けばいいだけでしょ？
具体的に何も示さずに svnbook 見てもわからんけど、git flow なら方針書いてあると言われてもね。
なお、情報ソースは >>225 がレベルの高い奴を示してくれるらしいから、それでもいいよ (w

**デフォルトの名無しさん** · 2014/08/27(水) 19:55:48.72

今になってtrunk/branches/tagsもベストプラクティス、がじわじわきだした

**デフォルトの名無しさん** · 2014/08/28(木) 09:57:20.57

>>226
> 具体的に何も示さずに
って、俺はそんなもの（確立された運用方針）なんかないって言ってるんだから、示すも糞もないよ。
あるんだったら、お前がURL示せ。

**デフォルトの名無しさん** · 2014/08/28(木) 12:31:06.51

>>228
はあ？
git flow にはあるんじゃないのか？
両方ないと言うなら、それでもいいけど。

**デフォルトの名無しさん** · 2014/08/28(木) 12:54:49.24

>>229
一体何の話をしてるんだ？
gitにはgit-flowやGitHub Flowのような開発フローがあるが、svnにはそれに類するものがあるのか
というのが最初の疑問(>>160)。
で、そういうのは残念ながら無いというのが俺の主張。

「svnbook に書いてなくて git flow で決められてる方針とやらを書」いたものなんてどこにも無いよ。

**デフォルトの名無しさん** · 2014/08/28(木) 18:46:05.74

>>230
だから、
> gitにはgit-flowやGitHub Flowのような開発フロー
の具体的な内容を書いてくれればいいだけ。
svnbook には、典型例としてソフトウェアリリースや（特定機能の）開発におけるブランチの使い方が書いてあるけど、君は git flow はそんなもんじゃなくて、もっと色々決められてるって言うんでしょ？
それを教えて。
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.release

**デフォルトの名無しさん** · 2014/08/28(木) 23:21:36.65

わかった上でわざとずれたこと書いて荒らしてるんじゃないかという気がしてきた。

**デフォルトの名無しさん** · 2014/08/29(金) 00:00:57.86

ぐぐれば図はでてくるんだけどこれじゃ理解できないってことなのかなぁ。
http://image.itmedia.co.jp/ait/articles/1311/18/gitflow01_1.jpg

そのやり方はsvnbookを見れば同じようなことが書いてあるとでも言い出すんだろうか。

**デフォルトの名無しさん** · 2014/08/29(金) 00:07:08.18

まぁベストプラクティスおじさんも
>>160が欲しがるURLに辿り着けたようだし
この辺でもういいんじゃないの？

**デフォルトの名無しさん** · 2014/08/29(金) 07:21:09.31

>>233
> そのやり方はsvnbookを見れば同じようなことが書いてあるとでも言い出すんだろうか。

そんなご託は、違いを説明してから言えば？

**デフォルトの名無しさん** · 2014/08/29(金) 10:15:23.47

へえ、svnbookでは、こんなことが推奨されてるのか。

> Developers commit all new work to the trunk. Day-to-day changes are committed to /trunk: new features, bug fixes, and so on.

**デフォルトの名無しさん** · 2014/08/29(金) 12:52:13.11

>>236
小規模なチームならそのやり方でいいだろうし、もう少し複雑な開発なら次の節にも目を通しておいた方がいい

**デフォルトの名無しさん** · 2014/08/29(金) 14:34:17.02

>>235ってID:KL0wurV3？

**デフォルトの名無しさん** · 2014/08/31(日) 10:27:47.17

SVN1.6を使ってるプロジェクトで仕事をしている不幸な俺が来ましたよ。
今のプロジェクト資産をSVN1.8 に移行させたいんだが、dump してload でOKですか？

**デフォルトの名無しさん** · 2014/08/31(日) 12:37:14.01

>>239
この際gitに移行しろｗ

そうすりゃsvnなんて、できたものをアップするだけの
単なる中央サーバーにしておける。古くても全然問題なし。

**デフォルトの名無しさん** · 2014/08/31(日) 13:03:00.35

>>240
全くその通りで、git に移行出来ればベストなんだが、
うちのプロジェクトの連中はSVN1.6に何の疑問も感じない管理職だの外注さんだのから
構成されていて、git 入れるとか言ったらそれだけでひと悶着ありそうな気配なので、
SVN以外は無理な感じ。

**デフォルトの名無しさん** · 2014/08/31(日) 13:22:54.88

>>241
違う違う。自分一人でgit使えばいいの。
ローカルだけで。

自分だけはgitで楽をする。
他の人は成長しないままｗ

**デフォルトの名無しさん** · 2014/08/31(日) 13:55:19.31

タイムスタンプですね
わかります

**デフォルトの名無しさん** · 2014/08/31(日) 14:13:58.95

今更人に聞けない。
「ぎっちょ」って呼んで良いんだよな

**デフォルトの名無しさん** · 2014/08/31(日) 14:43:01.38

まわりが徐々に移行しているときに同じようにやっておかないと
いつの間にか直接移行できなくなるほどバージョンに差ができていたりするよなｗ

**デフォルトの名無しさん** · 2014/08/31(日) 14:45:12.60

わざわざgitに変更するメリットあるの？

**デフォルトの名無しさん** · 2014/08/31(日) 15:11:36.05

>>239
dump load いらないよ。
http://subversion.apache.org/docs/release-notes/1.7.html
http://subversion.apache.org/docs/release-notes/1.8.html

**デフォルトの名無しさん** · 2014/08/31(日) 15:15:09.72

>>242
何という裏ワザ

>>245
そう思いますよ。駄目なプロジェクトってずっと同じもの使ったりするんで
何とかして欲しいです。

>>247
dump load しなくても大丈夫なのかな、、

**デフォルトの名無しさん** · 2014/08/31(日) 16:08:57.38

>>248
？

> There is no need to dump and reload your repositories. Subversion 1.7 servers can read and write to repositories created by earlier versions.
> To upgrade an existing server installation, just install the newest libraries and binaries on top of the older ones.

**デフォルトの名無しさん** · 2014/08/31(日) 16:45:43.70

>>249
なるほど

**デフォルトの名無しさん** · 2014/08/31(日) 17:57:57.45

先月だかまで1.6だたけどbackportsに1.8来てたからうpぐれしたわ

**デフォルトの名無しさん** · 2014/08/31(日) 18:39:37.01

俺なんかなー
レポジトリを1.7にした一週間後くらいに1.8が出て涙目で1.8に上げたわ

**デフォルトの名無しさん** · 2014/08/31(日) 19:21:08.74

互換性を調べられないような人にまで
駄目と言われるプロジェクトか
よっぽど駄目なんだろうな

**デフォルトの名無しさん** · 2014/08/31(日) 19:27:26.51

「gitに移行するのがベストだから移行したい」ってこの人が言い出したら、俺だって反対する。
お願いだから何もしないでくれの裏返しで。

**デフォルトの名無しさん** · 2014/08/31(日) 23:19:55.78

>>254
反対の理由は？

**デフォルトの名無しさん** · 2014/08/31(日) 23:29:23.88

>>255
gitに移行すること自体は別に反対じゃない。
ただ、検証能力の低い人が移行したいと言い出すことについては反対。

**デフォルトの名無しさん** · 2014/09/01(月) 00:21:24.59

>>256
なんで条件つけるんだよｗ

検証能力が低い人が決めたことは
全部反対ってことで、git関係ないじゃないか。

**デフォルトの名無しさん** · 2014/09/01(月) 00:29:29.14

>>257
そうだよ。git関係ないよ。そう書いたつもりだけど。
なぜgitがベストだと判断したか、説得させる力がないのを、
あの人は疑問も持たず使ってるだとか、だめなプロジェクトを何とかしてほしいだとかいう人だよ？
アップグレードに関する知識も、答えが載ってるページを貼ったにもかかわらず理解できなかった人だよ？

そういう流れがあった上で、>>254では「この人」が言い出したらとなってるんだ。

**デフォルトの名無しさん** · 2014/09/01(月) 00:33:17.89

ちなみに、業務でやってるわけじゃないのならこういう言い方はしなかったと思うよ。
ただただ、業務上ソース管理の管理者的な立場にいるような人があのザマだったからで。

**デフォルトの名無しさん** · 2014/09/01(月) 00:42:08.42

その前にさ、subversionが別とベストだと
判断した理由がなければ、比較できないよね？

どうせsubversionは惰性で使ってるだけなんだろ？

gitに理由を求めるのであれば、
subversionに理由を求めてもいいはずだ。

**デフォルトの名無しさん** · 2014/09/01(月) 00:46:31.35

>>260
向きを変えてもいいよ。
現状gitを使っていて、管理者としての知識が欠けている人が、
svnのほうが便利らしいからsvnにしたいんですって言い出したらどうする？

よしんば知識が欠けていなかったとしても、なぜ？って話をするのが通常でしょ？

**デフォルトの名無しさん** · 2014/09/01(月) 01:18:17.28

>>261
あぁ、管理者が馬鹿なのか。
なら馬鹿な管理者よりも
有名な人が使っている人が
選んでいるものを使いますね。

**デフォルトの名無しさん** · 2014/09/01(月) 14:02:43.92

>>258
うぜぇ

**デフォルトの名無しさん** · 2014/09/01(月) 17:14:42.01

頭が悪くて反論できないならgitスレに帰りなよｗ

**デフォルトの名無しさん** · 2014/09/01(月) 17:17:31.52

頭が悪くてスレ違いだってことがわかんないんでしょうか

**デフォルトの名無しさん** · 2014/09/01(月) 20:32:46.44

で git flow がーとか騒いでた奴は、結局 >>233 で終わりだったの？

**デフォルトの名無しさん** · 2014/09/02(火) 15:03:57.57

あんなに元気だったのにな。
突然静かになると逆に心配ですらある

**デフォルトの名無しさん** · 2014/09/02(火) 15:35:21.67

svnbookがbest practice

**デフォルトの名無しさん** · 2014/09/13(土) 16:12:11.13

質問させて下さい。
svn logで削除されてしまったファイルの履歴を見ることは可能ですか？
最新版で削除されている場合、エラーになってしまいます
pathではなくURL指定にしてみたり、-rでまだ削除されていないrevisionを指定してみたりしましたが、ダメでした

なにか、方法があれば教えてください
よろしくお願いいたします

**デフォルトの名無しさん** · 2014/09/13(土) 19:13:36.13

svn log -rrev url@revでわ?

**デフォルトの名無しさん** · 2014/09/23(火) 00:08:53.77

>>270
URL後に@revで出来ました！
ありがとうございます！！

でも、そもそもrevいくつで消されたのかわからないと、この方法も厳しいですね
やっぱり、消されていない上位のフォルダ取ってフィルタとかかっこ悪い方法しかないですかね

いずれにせよ、ありがとうございました

**デフォルトの名無しさん** · 2014/10/01(水) 21:51:38.36

すみません。
情報いただきたいのですが、ユーザが二人いて、両者が同じバージョンの同じファイルをupdateしたとします。
そのうち片方がdelete、commitを行いファイルをサーバから削除したとします。
その状態でもう片方がそのファイルを編集して、その後、サーバでファイルが削除されていることに気がついてupdateをしたら何が起こりますか？
ファイルがワーキングコピーから削除されることを期待しているのですが、うまく動きません。
コンフリクトの解決でなにか必要なオプションがあるのですか？

**デフォルトの名無しさん** · 2014/10/01(水) 22:34:23.68

>>272
> updateをしたら何が起こりますか？

コンフリクトするんじゃね？

> ファイルがワーキングコピーから削除されることを期待している

編集中の内容がなくなるような動作はしないはず。

> うまく動きません。

なんでどうなるのか書かないんだ？
普通の板ならいざ知らず、ここはム板なんだよ。

**デフォルトの名無しさん** · 2014/10/01(水) 22:43:39.38

>>272
コンフリクトが起こる
コンフリクトを解決するのはユーザの仕事
コンフリクトを起こしてしまった人間が、自分の仕事を破棄しても良いと判断するなら、revertすれば良いのでは？

**デフォルトの名無しさん** · 2014/10/01(水) 22:46:51.36

>>273
お前…偉いな
他意は無いよ
素直にそう思った

> なんでどうなるのか書かないんだ？
> 普通の板ならいざ知らず、ここはム板なんだよ。

これ重要だよな

**デフォルトの名無しさん** · 2014/10/02(木) 01:46:05.51

どうなってるかぐらい読めるだろ。

> ファイルがワーキングコピーから削除されることを期待しているのですが、うまく動きません。
うまく動かない = 期待通りの動作をしない = ワーキングコピーに残ったままになる

> コンフリクトの解決でなにか必要なオプションがあるのですか？
コンフリクトが発生している

**デフォルトの名無しさん** · 2014/10/02(木) 09:46:38.27

アホはうまくいかない場合に高い確率で予想もつかない操作をしている。
したがって現在の状況は激しく不明。適切なアドバイスは不可能。

**デフォルトの名無しさん** · 2014/10/02(木) 09:52:19.05

馬鹿には無理

**デフォルトの名無しさん** · 2014/10/02(木) 10:04:16.90

俺らの常識を超えるのはよくあることだが
予想もつかないと認めてしまうともはや転職するしかない

**デフォルトの名無しさん** · 2014/10/02(木) 12:35:56.17

>>272
もう答えが出てるも同然なんだけど、親切ぶって書いておくと

＞コンフリクトの解決でなにか必要なオプションがあるのですか？

コンフリクトの解決として、ローカルにあるファイルを生かすのか、削除するのかは
ユーザーが選ぶ必要がある。

その選択がすでに決まっている(今回の場合はリポジトリ優先)なら update / resolve のオプションで
--accept theirs-conflict か theirs-full が使えるかもしれない。

**デフォルトの名無しさん** · 2014/10/02(木) 22:44:40.53

>>279
> 予想もつかないと認めてしまうともはや転職するしかない

自社製品（ソフトウェア）のサポートしたことあるけど、色々ヒアリングしたら結局インストールしてないとかはまだかわいいもので、全く関係のない他社製品のクレームいれてきて、すぐ直せとか、予測なんてとても無理 w

**デフォルトの名無しさん** · 2014/10/03(金) 00:13:17.34

予想できる範囲の予想を放棄することについて言ってんでしょ。
理解力のなさが致命的じゃないか。そんなのでサポートできるのかどうか疑問だが、
過去形だからもうサポートはしてないんだよね。賢明だと思う。

**デフォルトの名無しさん** · 2014/10/03(金) 07:31:53.97

>>282
なんかアホが絡んできたぞ
まあ、これぐらいは予想できてたけど w

**デフォルトの名無しさん** · 2014/10/03(金) 08:15:06.89

予測でサポートは愚の骨頂
状況をヒアリングする → サポートデータベースを引き、それに合ったアクションをとる
システム化されたユーザーサポートには予測など入る余地はない

**デフォルトの名無しさん** · 2014/10/03(金) 08:30:51.96

他社製品のクレームぐらい事例にありそうだけど

**デフォルトの名無しさん** · 2014/10/03(金) 09:21:34.28

ヒアリングせず他社製品のクレームだと予想してそれへの対応するのか?
死んだ方が良いぞ、お前。

**デフォルトの名無しさん** · 2014/10/03(金) 10:11:59.67

お前のレスは読み飛ばしたからお前に対するレスじゃないんだ

**デフォルトの名無しさん** · 2014/10/03(金) 16:32:03.89

残念ながら「事例」が出てきてるのは、お前が読み飛ばしたはずのオレのレスなんだ。
頭悪いぞ、お前。

**デフォルトの名無しさん** · 2014/10/03(金) 17:16:24.75

おまえは>>281か?

**デフォルトの名無しさん** · 2014/10/03(金) 17:39:13.94

お互い予測できてない会話の例

**デフォルトの名無しさん** · 2014/10/03(金) 17:49:28.71

>>283 書いてからしばらくたって ID変えてまで >>284 書くから別人かと思った

～を聞いてみて～という返事が返って来たら、他社製品の○○のせいだからお引取り願う
なんて事例は結構あるかと思ったけど

**デフォルトの名無しさん** · 2014/10/03(金) 18:00:02.33

２ちゃんで他人か自演かを議論しても殆ど意味は無い

**デフォルトの名無しさん** · 2014/10/03(金) 18:14:35.26

>>291
> ～を聞いてみて～という返事が返って来たら、他社製品の○○のせいだからお引取り願う

そんなやわな例ならわざわざ書かないよ
>>281 で書いたのは、うちの製品が全く関係ない例
具体的な製品名は出せないけど、例えばプリンタで印刷がおかしいというクレーム受けたから、色々ヒアリングしたら最終的に他社の製品だったというオチ
最初に型番ぐらい確認しろよ、とか言うだろうけどそんなものにまともに答えるような奴はそもそもこんなアホなクレームつけてこない
下手に無理やり型番聞こうとすると、そんなもんはどうでもいいからすぐ来て直せとかよけいに激昂して泥沼に入るだけ

**デフォルトの名無しさん** · 2014/10/03(金) 18:22:03.69

Subversionスレで何やってんですか

**デフォルトの名無しさん** · 2014/10/03(金) 21:31:07.10

マニュアル対応しかできないからこんな会話になるんだろw

**デフォルトの名無しさん** · 2014/10/03(金) 21:57:20.10

次にお前はこう言う
「俺が予測出来ないのでは無い。相手がアスペなんだ」
「はっ？！」

**デフォルトの名無しさん** · 2014/10/03(金) 23:34:16.78

Subversionが停滞しているのではない。
gitが前進しているのである。

**デフォルトの名無しさん** · 2014/10/04(土) 05:03:15.68

>>293
あなたの経験はどうでもいいんだけど、今回の話の基点になってるのは >>272 に対する >>277 だよね。
>>272 を読んで適切なアドバイスが不可能な人は、今のところ >>277 以外にいない。

**デフォルトの名無しさん** · 2014/10/04(土) 05:55:20.32

>>298
あなたは >>272 なの？
適切なアドバイスかどうかは >>272 でないとわからない
>>280 みたいな具体的なコマンドラインオプションを知りたかったのかもしれないし、>>297 が正しいなら git へ go が適切だったかもしれない
あと、アドバイスができない奴でレスしない奴がいないことをどうやって確認したの？

**デフォルトの名無しさん** · 2014/10/04(土) 07:03:31.85

>>299
>>272じゃないよ。ところで>>299は>>293なの？

> >>280 みたいな具体的なコマンドラインオプションを知りたかったのかもしれないし、
ちがうね。期待していた動作に近い挙動をさせる方法を知りたかっただろう。

> >>297 が正しいなら git へ go が適切だったかもしれない
まさかｗ

**デフォルトの名無しさん** · 2014/10/04(土) 07:12:58.07

>>300
> ちがうね。

本人でもないのに断言
アホ過ぎ