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/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
> ちがうね。

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

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

こんなものは停滞し続けてもらわないと、
フォーマットが変わったから1からコミットし直しなんて
もう嫌だｗ

**デフォルトの名無しさん** · 2014/10/04(土) 13:39:10.20

>>302
何でそうなる？

**デフォルトの名無しさん** · 2014/10/04(土) 15:45:10.72

>>298
>>>272 を読んで適切なアドバイスが不可能な人は、今のところ >>277 以外にいない。

お前が適切なアドバイスとやらをしてみろ。ワ

**デフォルトの名無しさん** · 2014/10/06(月) 02:58:33.52

何で伸びてんのかと思ったら理解力がないものとそれを無駄にあおり続けるものの応酬だった。
2chでは良くあることだけどこのスレでそうなるとはね。

**デフォルトの名無しさん** · 2014/10/06(月) 03:22:18.69

２ちゃん中毒症状の進行
1.物騒な掲示板だなと印象を持つ
2.全部自演だと思い込む
3.自分で自演を始める
4.自分で自演してるのに他人の自演を叩く
5.自演じゃないと言い張る
6.他人のレスと自分のレスの区別が付かなくなる

**デフォルトの名無しさん** · 2014/10/06(月) 21:58:30.50

>>306
6番って、
他人へのレスと自分へのレスって事？
それとも、
自分が書いたレスを(自演だけど)本当に他人が書いたと思ってしまうって事？

前者は良くいるけど、後者は怖いよね…

**デフォルトの名無しさん** · 2014/10/06(月) 22:37:11.58

なんで伸びてるのかと思ったら、>>305 がヨタ話始めただけだった。
2chでは良くあることだけどこのスレでそうなるとはね。

**デフォルトの名無しさん** · 2014/10/07(火) 01:57:45.48

よくある流れ

**デフォルトの名無しさん** · 2014/11/18(火) 11:29:16.53

TortoiseSVNの「未コミット項目が残ったらコミットダイアログを再度開く」のオプションって
なんで無くなったのか分かる人いない？
一部だけコミットしてまたコミットダイアログ開くの面倒くさいよ

**デフォルトの名無しさん** · 2014/12/15(月) 20:56:02.95

svn logでそのレビジョンで変更があったファイル、フォルダを見れると思います
その際、削除されたフォルダの下の情報も取得するオプションはありますか？

たとえば
A(Folder)
- B(Folder)
-- C(Folder)
-- d.txt(File)

という階層があって、Bを削除された場合、そのレビジョンではBがdeletedだったと表示されると思うのですが、C,d.txtも表示させたいです

ご存知の方がいらっしゃいましたら、教えてください
よろしくお願いいたします

**デフォルトの名無しさん** · 2014/12/18(木) 02:07:41.51

Subversion 1.7 & TortoiseSVN 1.7 系の環境を　
Subversion 1.8 & TortoiseSVN 1.8.9 に移行して、気が付いたんだが、

コミット済みのファイルをTortoiseSVN でrename して再度コミットするとエラーになる。
同じ操作をしても1.7系だとコミット出来たのに、1.8系だとエラーになる。

回避するには、コミット済みのファイルをTortoiseSVN でrename した場合は、
一つ上のフォルダに移動して、そこでコミットすると、コミット出来る。

これって仕様なんだろうけど、使いにくくないか？

**デフォルトの名無しさん** · 2014/12/18(木) 02:11:07.69

>>312
Subversion の rename は copy&delete の２つの操作の組み合わせとしてコミットされる。
1.7 までは rename で発生した copy だけをコミットすることができていたが、それはたいていの場合
間違い。（リポジトリ上にリネーム前のファイルと後のファイルが両方存在する状態になる）

そういう間違いを防ぐため 1.8 でこれをエラーとするようにした。とても助かる。

**デフォルトの名無しさん** · 2014/12/18(木) 20:54:09.30

>>311
できるよ

**デフォルトの名無しさん** · 2014/12/19(金) 00:10:43.61

>>314
できないよ

**デフォルトの名無しさん** · 2014/12/19(金) 07:39:25.42

>>315
できるよ

**デフォルトの名無しさん** · 2014/12/19(金) 22:34:23.82

>>316
できないよ

**デフォルトの名無しさん** · 2014/12/20(土) 18:59:23.15

できるよ

**デフォルトの名無しさん** · 2014/12/21(日) 00:26:40.92

できないよ

**デフォルトの名無しさん** · 2014/12/21(日) 00:57:31.27

どっちだよ(´・ω・｀)

**デフォルトの名無しさん** · 2014/12/21(日) 13:28:53.87

svn.exeで色々とオプション試してみたが、無理だと思う
svn.exeではなく、subversionのDLL直叩きなら、なんか方法あるかもしれんが

>>318 >>316 >>314
本当に出来るなら、やり方教えて欲しい

**デフォルトの名無しさん** · 2014/12/21(日) 13:55:00.79

>>313
rename した後に同じフォルダーでcommit するとエラーで
上のフォルダーに移動してcommit するとＯＫってのが謎の仕様なんですけど、、

**デフォルトの名無しさん** · 2014/12/22(月) 00:43:12.72

>>321
ちょっと意地になって色々ためしたけど、無理っぽい
あと、質問なんだが、

＞subversionのDLL直叩き

これどういう意味？

**デフォルトの名無しさん** · 2014/12/22(月) 08:50:25.22

>>323
API 使えってことじゃね？

**デフォルトの名無しさん** · 2014/12/26(金) 20:56:52.95

すみません、何方かアドバイスをお願いします

メンバの一人が間違って登録されてるファイルを全部消すと言うミスをしてしまいました
このリビジョン（仮にrev100）における操作を完全に無かったことにしてrev99=HEADの状態
にするにはどうすればよいのでしょうか？

**デフォルトの名無しさん** · 2014/12/26(金) 21:08:51.98

>>325
↓こんな感じ？試してないけど。
svn cp -r99 ^/ ^/

**325** · 2014/12/26(金) 21:21:58.89

325です
自己解決しました

**デフォルトの名無しさん** · 2014/12/27(土) 03:53:42.69

>>326
普通は逆マージ。

**325** · 2014/12/27(土) 12:33:50.64

325です
履歴にも残さずに完全にロールバックしたかったので逆mergeやcopyと言う方法
は選べませんでした

**デフォルトの名無しさん** · 2014/12/31(水) 15:11:53.14

今年はsubversionの終わりが加速した感じだった。
dev-MLの投稿数は毎月200通以下が普通になったし、
1.9は全然収束しない。
しかも、1.9は機能を削りまくってる。
まともなrenameトラッキングは当分先みたいだし。
うちの会社もあちこちでgitに移行してるし。

**デフォルトの名無しさん** · 2014/12/31(水) 15:15:26.31

それは良かった

**デフォルトの名無しさん** · 2014/12/31(水) 15:35:26.41

このスレーってもうSubversion単体スレーである必要が全く完全に無いだろ
バージョン管理ツールスレーとかでいいんじゃないの？
>330 も言うようにどんどんgitへの移行も進んでるし、今更subversionで語る
ようなことも無いだろ

**デフォルトの名無しさん** · 2014/12/31(水) 16:36:32.17

人居ないからな
廃合は仕方ない