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/23(土) 16:08:22.28

>>151
どう分ければ良いの？

**デフォルトの名無しさん** · 2014/08/23(土) 17:10:06.41

>>150
独立したそれぞれの理由を書いてるけど、どれもこれも分けないことによって生まれるデメリットに相当しないんだもの。

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

ソースコードのバージョン管理とプロダクトの構成管理は別物だしなぁ

**デフォルトの名無しさん** · 2014/08/23(土) 19:25:44.67

分けることで得られるメリットも同じ位薄弱だ

**デフォルトの名無しさん** · 2014/08/24(日) 00:45:17.64

この流れは何度も繰り返されているけれど、そのたびに分けなくていいという結論になってない？

**デフォルトの名無しさん** · 2014/08/24(日) 11:38:05.22

>>5
>バージョン管理システム Subversion にバージョン1.8 登場
>― なぜ Git ではなく、SVN を使うのか？
>Sean Michael Kerner
>2013年6月20日 / 19:30
>http://internetcom.jp/webtech/20130620/8.html

訳がおかしいから原文読んだけど、

http://www.developer.com/open/subversion-1.8-gits-new-features.html

1.9 を9か月のサイクルで出したいとか言ってたけど、無理みたいだな。

**デフォルトの名無しさん** · 2014/08/24(日) 12:46:27.42

これぐらいの速度で出して欲しい

2005年12月21日 - 1.0.0リリース
2006年1月9日 - 1.1.0リリース
2006年2月13日 - 1.2.0リリース
2006年4月19日 - 1.3.0リリース
2006年6月11日 - 1.4.0リリース
2007年2月14日 - 1.5.0リリース
2008年8月18日 - 1.6.0リリース
2010年2月13日 - 1.7.0リリース
2012年10月21日 - 1.8.0リリース
2014年2月14日 - 1.9.0リリース
2014年5月28日 - 2.0.0リリース
2014年8月15日 - 2.1.0リリース

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

gitの開発速度には敵わないでしょ

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

subversionにgit flowとかgithub flowみたいなのってある？
subversionを使ってどういうふうに運用するかを
決めた開発のフロー

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

あとどういう時にブランチ切ってる？
バグ修正用のブランチとか切っていい？

そうするとたとえばバグが100個あったら
100個ぐらいブランチ出来るんだけど
名前つける時どうしてる？

誰が作ったブランチかわからないから
頭に個人名のプレフィックスつけようかと思うんだけど
変なやり方じゃない？

要らなくなったブランチは削除していいよね？
ブランチは削除できるみたいだし。

**デフォルトの名無しさん** · 2014/08/24(日) 17:05:10.65

大抵のバグはブランチを作るほどじゃないなぁ。影響範囲も小さく、内容が明白であれば1コミットで済むでしょ。

オレオレブランチは大抵イマイチな命名だけど状況次第。
砂場として使うならアリ。バグフィックスのために個人名をつけるのは全力でナシ。

要らなくなったブランチはどんどん削除。

**デフォルトの名無しさん** · 2014/08/24(日) 18:53:31.85

> 大抵のバグはブランチを作るほどじゃないなぁ。影響範囲も小さく、内容が明白であれば1コミットで済むでしょ。

一人でやっていればいいけど、複数人でやってると
そうも行かないよね？

並列で複数の作業が発生するわけだしコードレビューも必要。

**デフォルトの名無しさん** · 2014/08/24(日) 19:49:07.75

>>163
> 一人でやっていればいいけど、複数人でやってると
> そうも行かないよね？

修正範囲が多岐に渡るでかい修正ならそうだけど、大抵の修正は一人でやってる範囲に収まるよ
でかい修正の時は修正方針決めた段階で関係者集めてレビューするから

**デフォルトの名無しさん** · 2014/08/24(日) 23:27:54.67

いや、書いたコードをレビューしないと、
修正方針通りでも、コードがダメな場合があるじゃないか
コピペされていたり、正しくない構造を指定たり。

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

それに複数人でやるっていうのは、修正する人が一人かどうかじゃなくて、
平行して、別々の開発があるじゃないかって話。

一つのプロジェクトの新規機能Aを担当する人、
同Bを担当する人、同C担当する人、バグ1を修正する人、以下略って。

そういう人が、それぞれtrunkにコミットしたらダメだろ？
だからブランチという機能があるんだが。

**デフォルトの名無しさん** · 2014/08/25(月) 00:39:19.30

そんなの現場次第。

**デフォルトの名無しさん** · 2014/08/25(月) 15:34:41.14

>>166
> 一つのプロジェクトの新規機能Aを担当する人、
> 同Bを担当する人、同C担当する人、バグ1を修正する人、以下略って。
>
> そういう人が、それぞれtrunkにコミットしたらダメだろ？
ん？それって10人で開発する場合、最低10個のbranch切って各人がそれぞれのbranchで開発するってこと？
それ、いつtrunkにマージするの？

**デフォルトの名無しさん** · 2014/08/25(月) 15:42:29.04

>>168
そりゃできた順（もしくはリリースする順）にマージだろ

**デフォルトの名無しさん** · 2014/08/25(月) 16:38:16.81

>>169
> そりゃできた順（もしくはリリースする順）にマージだろ
で、、マージ後branchは消すの？
消さないと、1リリース毎に見ると数百のbranchが残るよね。

**デフォルトの名無しさん** · 2014/08/25(月) 16:39:32.30

それとも、マージ後trunkの変更点をbranchに取り込んで、各人はそのbranchで作業を続行するのかな？
それだと、branchの意味あんまなさそう・・・。

**デフォルトの名無しさん** · 2014/08/25(月) 17:14:52.76

ブランチの利点が理解できてない人がいるとは思わなかったｗ

**デフォルトの名無しさん** · 2014/08/25(月) 17:19:00.91

そんなもんだろ。
subversionをバックアップとしてしか使ってない証拠。

まあ、普通はマージを日常的に使ってたら
subversionは使いづらくてしょうがないから
gitに移行するんだけどねｗ

**デフォルトの名無しさん** · 2014/08/25(月) 17:38:32.48

こりゃ面白い。急成長じゃないか。
明日にもgit叩きを始めそうな展開で胸が熱い。

>>161 ブランチどうやって切ればいいんですかね；；
>>163 トンチンカン
>>166 だからブランチという機能があるんだが。

**デフォルトの名無しさん** · 2014/08/25(月) 17:44:56.29

>>174
> >>161 ブランチどうやって切ればいいんですかね；；

質問は「どうやって切る」じゃなくて
「どういう時に切る？」だろ？

開発フローを効いてるだけだと思うが？

160 名前：デフォルトの名無しさん[sage] 投稿日：2014/08/24(日) 16:17:32.62 ID:1q09/hom
subversionにgit flowとかgithub flowみたいなのってある？
subversionを使ってどういうふうに運用するかを
決めた開発のフロー

**デフォルトの名無しさん** · 2014/08/25(月) 17:46:57.39

なんだ、じゃあどういうときに切るかはまだ分からないままか。
じゃあ >>162 のまま特に変える必要ないなぁ。

**デフォルトの名無しさん** · 2014/08/25(月) 17:53:04.86

>>176
並行開発はどうやってるの？

新規機能を幾つか平行して開発している場合。

**デフォルトの名無しさん** · 2014/08/25(月) 18:20:23.87

>>176
一人開発で使ってるだけで、そういう高度なことは
やってないから知らない。って答えてもいいんですよ？

**デフォルトの名無しさん** · 2014/08/25(月) 18:29:44.44

ID:W/mMJDzTはsubversion book読んで出直しなさい。
レベルが低過ぎて会話に追従出来てない。

**デフォルトの名無しさん** · 2014/08/25(月) 18:36:43.65

そう言えば俺svnでは一度もマージ使った事なかったな…
なんて事、trunk一本糞なオープンソースに関わりながら思い出した

**デフォルトの名無しさん** · 2014/08/25(月) 18:51:31.79

subversionの人にとってはsubversionは
バックアップツールなんだよ（笑）

http://www.amazon.co.jp/o/ASIN/4798013730

> 内容（「BOOK」データベースより）
> この本は、Subversionというバックアップのためのソフトについて説明したものです。
> 内容（「MARC」データベースより）
>
> Windows上で使えるバックアップツール「Subversion」の基礎知識から
> 具体的な使い方までをわかりやすく解説。テキストファイルも画像ファイルも、
> ファイルもフォルダも、好きなときにバックアップできる!

**デフォルトの名無しさん** · 2014/08/25(月) 20:23:33.02

>>177
ブランチ作るよ。普通に。
てか、バグフィクスでブランチを作るかどうかの話じゃないの

**デフォルトの名無しさん** · 2014/08/25(月) 20:33:53.30

>>168
人単位でブランチは作らない。
>>166が一機能一人みたいな書き方してるからアレだけど、
新規機能が10個あって、それらのリリースタイミングが同一であることが明らかではない場合、
個別にブランチを作る。

>>170-171
複数バージョンを並行してメンテする場合、リリースブランチとして運用をするために残すこともある。
大抵は、リリース時にタグを打っておいて、必要ならタグからブランチを作成してメンテするけれど。

**デフォルトの名無しさん** · 2014/08/25(月) 22:36:00.58

　　　　 |
　＼　　__　　／
　＿　（ｍ）　＿ﾋﾟｺｰﾝ
　　　　|ミ|
　／　.｀´　＼
　　　∧＿∧ 　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　（・∀・∩＜そうだ！subversion の開発は、git を使ってやればいいんだ
　　　（つ　　丿＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　⊂＿ノ
　　　　（＿）

**デフォルトの名無しさん** · 2014/08/25(月) 22:45:10.35

gitならば、gitならば問題ない
と言いたい人がいるようだけど、
どう問題ないのか是非聞かせていただきたい。

**デフォルトの名無しさん** · 2014/08/25(月) 23:20:37.21

>>160,161の質問でここまで紛糾する理由がワカランチン

> subversionにgit flowとかgithub flowみたいなのってある？

俺もあるのか知りたい

**デフォルトの名無しさん** · 2014/08/25(月) 23:30:46.07

別にブランチを避ける文化もあるってことでいいのでは。

**デフォルトの名無しさん** · 2014/08/25(月) 23:52:49.55

>>166
バグに対するブランチの話じゃないのか？
いつの間に複数の機能追加の話になったんだ？

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

>>186
>>160 で揉めてる訳じゃないでしょ
Subversion にはその手の機能はないと思う

ブランチ云々は宗教戦争ネタなので大抵揉める

**デフォルトの名無しさん** · 2014/08/26(火) 00:13:06.12

いや機能じゃないでしょ。。

**デフォルトの名無しさん** · 2014/08/26(火) 00:24:29.72

そ、そうなのか、gitには運用フロー機能があるのか。。

**デフォルトの名無しさん** · 2014/08/26(火) 00:58:42.64

>>190
ああ、git flow で使うフローと言うか、お約束について聞いてたんだな
そう言う意味なら trunk/tag/branch も一つのお約束だから、あるって言えなくもないかな

>>191
まあ、git flow は運用フローの支援機能ではある

**デフォルトの名無しさん** · 2014/08/26(火) 00:59:38.52

ないアルよ

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

>>192
> そう言う意味なら trunk/tag/branch も一つのお約束だから、あるって言えなくもないかな

trunk/tag/branchがある前提で、git flowのような運用をする方法がsvn界隈で確立されてるかって疑問だと思う。
そして、それは確立されていない。

**デフォルトの名無しさん** · 2014/08/26(火) 12:32:08.23

>>194
> そして、それは確立されていない。

どういう基準で確立されてないと言えるんだ？
されていないと言い切るんだから、明確に答えられるよね？

**デフォルトの名無しさん** · 2014/08/26(火) 12:39:00.35

広く(一般に)知られた手法は無い。って事だろ。アスペ。

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

>>195
某かのbest practiceがあるなら、教えて欲しい。
確立されたbest practiceなら、多分それには名前が付いているはずで、ググれば少なくとも数千はヒットすると思われる。
そういうのある？

**デフォルトの名無しさん** · 2014/08/26(火) 13:30:57.85

>>197
trunk/tag/branch を切ると言うのも運用だろ？
そして、各々にどんなものを入れるかを決めるのも運用だよね。
逆に言うと何ができてたら、best practice って言えるんだ？

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

git flowってさ、trunk,brances,tagsっていうお約束より更に一つ上の層のお話だとボク思うんだ

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

>>198
いやだからgit-flowとかGitHub Flowのようなものがsvnにはあるの？って話なんだけど。

まず最初にtrunk/tabs/branchesを作りましょうというところまではsvnbookでも推奨されていて、
ほとんどの人がそれに従ってると思われる。

ただ、どういうときにどういうbranchを切るかとか、いつ誰がどのbranchにマージするのかとか、
メインとなるbranchのマージ先はtrunkなのかそれともhoge-branchなのかとか、リリースは
どこからやるのかとか、リリース後はどうすべきかとか、bugfix時の運用とか、そういう運用の
お手本となるようなbest practiceってあるのか、そういうこと。

まぁ大体の所はオレオレ運用じゃないのかなぁと思ってるんだけど。
ちなみにうちは、Redmineの1チケットがtrunkへの1コミットとなるよう、必要ならbranch切れ、くらいで運用してる。

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

ベストプラクティスに名前をつけるという行為はさほど一般的じゃないと思うけど、
どのベストプラクティスがベストなんだ？という面倒なことを避けるために名前をつけるのはひとつの方法なのかなぁ。

大抵みんなやり方が同じようになってきてるから、こういうときどうすればいいのって聞けばいいんじゃないかな。

**デフォルトの名無しさん** · 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ぐれしたわ