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/02(土) 17:21:57.75

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

TortoiseSVN
http://tortoisesvn.net/

■文書
svnbook PDF版
http://psyto.s26.xrea.com/misc/svnbook/

CVSユーザのためのSubversionガイド(wakatonoさん)
http://slashdot.jp/journal.pl?op=display&;uid=12&id=200792

■Wiki
Subversionメモ
http://terai.xrea.jp/Subversion.html

■記事(ちょいと旧め)
http://www.atmarkit.co.jp/flinux/special/webdav/webdav03c.html
http://www.atmarkit.co.jp/flinux/special/webdav03/webdav02a.html
http://ukai.jp/Slides/2003/0521-lw2003/html/
http://ukai.jp/Articles/2003/uu-svn/

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

◆関連スレ
バージョン管理システムについて語るスレ10 [プログラム板]
http://peace.2ch.net/test/read.cgi/tech/1393147031/

CVS 1.3 [UNIX板]
http://peace.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ～ Rev.3 [プログラム板]
http://peace.2ch.net/test/read.cgi/tech/1113141518/

subversion バージョン管理【サブバージョン】 [Linux板]
http://maguro.2ch.net/test/read.cgi/linux/1154701996/
Git 10 [プログラム板]
http://peace.2ch.net/test/read.cgi/tech/1403426425/
【分散型バージョン管理】 Mercurial 2【hg】 [プログラム板]
http://peace.2ch.net/test/read.cgi/tech/1321109748/
【bzr】Bazaarでバージョン管理 Rev 4 [プログラム板]
http://peace.2ch.net/test/read.cgi/tech/1356521407/

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

■記事(最近)
「Apache Subversion 1.7.17」リリース
2014年5月20日16:15 末岡洋子
http://sourceforge.jp/magazine/14/05/20/161500

＞　1.9は第2四半期中にリリースを予定しており、

バージョン管理システム「Subversion 1.8」が登場、競合解決ツールや出力の改善など変更点多数
2013年6月19日15:15 末岡洋子
http://sourceforge.jp/magazine/13/06/19/151500

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

■Subversion の開発元
What's Next for Subversion?
https://www.youtube.com/watch?v=KjxcLHss-p8&;list=UU9xOkklmZFT3N2UtV2zy3ow

**デフォルトの名無しさん** · 2014/08/02(土) 18:22:49.13

>>5
> ― なぜ Git ではなく、SVN を使うのか？

ローカルコミットをサポートしてクレー

**デフォルトの名無しさん** · 2014/08/02(土) 18:40:46.96

subvertionがgitになるなら
もうgitを使ったほうがいい気がするがｗ

**デフォルトの名無しさん** · 2014/08/02(土) 19:36:38.97

http://www.buzzword.jp/img/face10.png

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

グロ

**デフォルトの名無しさん** · 2014/08/03(日) 00:10:47.82

subvertionから移行しやすいのは、gitでなくhg

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

その前にsubvertionて何ですのん

**デフォルトの名無しさん** · 2014/08/03(日) 00:53:58.50

アナル拡張器具

**デフォルトの名無しさん** · 2014/08/03(日) 07:20:51.74

hage?

**デフォルトの名無しさん** · 2014/08/03(日) 09:26:06.17

スケーラビリティが向上するんだよ

**デフォルトの名無しさん** · 2014/08/03(日) 12:30:11.92

subversion は良くも悪くも普通のバージョン管理ツールだけど
git って、パッチ管理（リモート、ローカル）＆マージ処理に特化したのが勝因だよなー

Linusとしては自分に必要な、Linuxのパッチ適用に必要な機能だけ
あればよいって言う考えでgitを設計したんだろうけど。

**デフォルトの名無しさん** · 2014/08/03(日) 12:43:18.82

subversionはソースコードを管理するツール
gitは機能単位でコミットを作るための開発ツール

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

フツーの業務システム開発ならsvnのtrunk一本でそれほど困らんけどね
複数人で同じソースをいじくりまわしてマージが大変なんてことは無いし

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

>>17
ぼっち開発者の俺はtrunkだけでほぼいける。
以前のバージョンに戻すこともめったにない。

ビルド出来ないとか、動作が不完全のような中途状態で取っておきたいときに
ブランチを作って、ＯＫになったらtrunkへマージする。
このブランチ側の作業を、ローカルリポジトリか何かで自動化できるとうれしい。
gitのリモート/ローカルってそういうものなんだろーなーと指を加えて見てる。

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

大改造する時にはブランチきるだろ JK

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

>>19
ぼっち開発ならそのまま trunk 上で開発もありだろ
どうしても途中で元のバージョンに修正入れたいなら、その時ブランチ切ればいいんだし

**デフォルトの名無しさん** · 2014/08/03(日) 22:45:35.77

git ⊃ SVN と思ったが違うのか

**デフォルトの名無しさん** · 2014/08/03(日) 22:51:10.95

>>21
コミットの考え方が違うね。
svnは単なる作業履歴って感じだけど、
gitはコミットを一つ一つに意味があって
大事にしている。

**デフォルトの名無しさん** · 2014/08/04(月) 00:09:08.40

Git、Eclipse.orgでCVS、SVNを超える
作者： Alex Blewitt , 翻訳者笹井崇司投稿日 2011年12月11日
http://www.infoq.com/jp/news/2011/12/eclipse-git

今から思えば、2010-2011に掛けて、Subversion からgitへ
ユーザーの移行が進んだな

Subversion 1.7以降は、日本語の記事も極端に減った感じがする

**デフォルトの名無しさん** · 2014/08/04(月) 00:42:58.11

gitは機能が多すぎ

**デフォルトの名無しさん** · 2014/08/04(月) 13:57:04.00

多いというか、整理されていないというか
かといって無いと不便というか
慣れるしかないというか

**デフォルトの名無しさん** · 2014/08/04(月) 14:03:00.85

新しく始めるときはgit使うようにしてるけど、慣れたらsvn使うの面倒くさく感じるようになってきた。

**デフォルトの名無しさん** · 2014/08/04(月) 14:51:04.10

うん
そうだね

**デフォルトの名無しさん** · 2014/08/04(月) 18:15:01.48

>>20
その運用するなら「元のバージョン」として扱うだろうと考えられるリビジョンでタグ打っときなよ

**デフォルトの名無しさん** · 2014/08/04(月) 20:40:49.84

>>25
> 整理されていないというか

ほんこれ
確かにあったらいいな～は、あるんだけど、なれるまでがちょい大変

>>28
ぼっち開発だとログもたいしたことないし...
まあ、リリース毎には外部バージョンでタグ打つけどね

**デフォルトの名無しさん** · 2014/08/04(月) 22:35:33.41

http://www.buzzword.jp/img/face10.png

**デフォルトの名無しさん** · 2014/08/04(月) 22:53:31.39

guro

**デフォルトの名無しさん** · 2014/08/04(月) 22:58:50.77

一人でやってると、コミットの扱いが雑にならね？

何か修正している時に、つい近くの
コードが気になって関係ないのに修正しちゃう。

で、コミットメッセージに○○の修正って書いてるのに、
無関係の修正が含まれてたり。

**デフォルトの名無しさん** · 2014/08/05(火) 02:53:09.46

あるある～

**デフォルトの名無しさん** · 2014/08/05(火) 03:20:24.50

狭く深くか、広く浅くかで分けて
広く浅い方は「後で絶対に戻さない」という信念を持ってコミットする

**デフォルトの名無しさん** · 2014/08/06(水) 23:28:00.45

> 広く浅い方は「後で絶対に戻さない」という信念を持ってコミットする

一つ一つに信念を持たないと
コミットできないなら疲れるってｗ

人間である以上、漏れっていうのは絶対にある。
こんな些細な事はあとから修正すればいい話でgitならそれができる。

**デフォルトの名無しさん** · 2014/08/07(木) 19:51:06.05

単に数日前に戻りたいだけとか、コミットにいちいち信念なんてうぜーとかなら、
別にわざわざscm使う必要なくね?
そういうやつはどうせコミットメッセージなんてロクにつけないんだろ?
このスレでいうのもなんだが、そういう使い方しかしないんなら、
nilfs2などのログファイルシステム使っとけば十分な気がするが。
webdavなクラウドストレージでもいいし。
無理してscm使う必要ないと思うけど。

**デフォルトの名無しさん** · 2014/08/07(木) 21:58:12.49

コミットの内容に気を使うか、
単なるバックアップとして使うかの
違いだよね。

バックアップとしてしか使ってない人は
ソースコードを管理しているわけじゃないというだけのこと。

**デフォルトの名無しさん** · 2014/08/08(金) 01:55:37.68

SVKって、なんで廃れたの？

**デフォルトの名無しさん** · 2014/08/08(金) 02:38:38.23

差分確認したいから使うわけだが

**デフォルトの名無しさん** · 2014/08/08(金) 02:54:36.69

その差分が、一日とかの時間単位の差分なのか
コミット＝機能単位の差分なのかで意味が違ってくるけどな。

しっかりコミットには機能を含ませないとダメだよ。
○機能のコミット、間を空けて、○機能のバグ修正とか
機能が複数のコミットに分断されたりすると、差分調べづらいからさ。

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

>>40
一機能が数十ファイルに渡る数千行の変更になることが普通だから、機能毎のcommitは粒度が大きすぎる。

**デフォルトの名無しさん** · 2014/08/08(金) 23:37:02.98

粒度が小さくしようと思えば、
コミットの回数は必然的に多くなると思うけど、
そうすると大変にならね？

ちょっとしたミスでもしないように
心がけないといけないから、テストに時間が掛かる。

**デフォルトの名無しさん** · 2014/08/09(土) 15:03:48.49

>>42
昔、１つの障害直すのに機能修正用に一回コミットして、
その後ソースのインデント変更でもう一回コミットとかした事がある。

確かに細かくコミットした方が後で見るときに分かりやすいというのはある。

**デフォルトの名無しさん** · 2014/08/10(日) 09:00:39.40

http://www.buzzword.jp/img/face10.png

**デフォルトの名無しさん** · 2014/08/10(日) 18:07:16.07

>>40
ブランチ作ればいいんでないのと思うんだけど、それではだめなのかな。

>>42
粒度を小さくするってことは、固まったところからコミットしていくということなので
特にテストの手間は増えないよ。

>>43
気持ちは分かるんだけど、インデントに関してのみいえばdiffのオプションで
インデント変更を無視することができるので、分けなくても大丈夫。
むしろ、特定リビジョンにおいてインデントが崩れている状態を生み出したというのは
個人的にはあまりよろしくないと思う。

**デフォルトの名無しさん** · 2014/08/12(火) 07:18:30.56

1.8.10が出たのか
そろそろgitに移行するかなー

**デフォルトの名無しさん** · 2014/08/12(火) 18:02:50.52

>>45
> 粒度を小さくするってことは、固まったところからコミットしていくということなので
> 特にテストの手間は増えないよ。

固まった所からコミットするってどうやるの？
ファイルの一部分だけコミットとか出来ないよね？

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

あと固まった所からコミットというのは
作業が直列化してるんだよね。

ある機能を作ろうと思ったら、
・サブ処理A
・サブ処理B
・サブ処理C

みたいな感じで機能を作っていくでしょ？
その時サブ処理Aができたーと思って
B、Cを作っていくけど、その間に見逃しがあったり
問題が見つかって再設計が必要になる。

そういうときサブ処理Aのコミットを
修正できないのはキツイよね。

**デフォルトの名無しさん** · 2014/08/12(火) 18:22:27.64

>>48
> そういうときサブ処理Aのコミットを
> 修正できないのはキツイよね。

言ってる意味がわからないんだが・・・。
BあるいはCをきりのいいところでcommitして、Aを修正すればいいのでは・・・。

**デフォルトの名無しさん** · 2014/08/12(火) 18:48:27.03

>>49
そうすると、Aのコミットと
Aの修正のコミットの二つが出来るでしょ？

**デフォルトの名無しさん** · 2014/08/12(火) 22:05:50.34

うん。
そういうものを管理するためのツールだもの。

**デフォルトの名無しさん** · 2014/08/12(火) 22:20:13.12

>>51
意味を考えたことある？

Aのコミット＋Aの修正であれば、その二つを
まとめたコミットが一つだけあれば十分。

もちろんリリースした後なら別に分けたほうがいいけど、
一時間前に書いたコードのケアレスミスとか残す価値はない。

残しておけば、過去のコードを見る必要がある時
（見る必要があるから残すわけで）余計な手間がかかる。

コミットの内容を小さくすればするほど、無駄なコミットはなくそうと
考えるのが普通では無いかな？

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

>>52
確かにバグ修正のコミットは結果的に言えば無駄だね。
じゃあ、いつコミットできるの？
バグが一切存在しないコードを書けるクヌース先生みたいな人なのかな。

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

>>52
詭弁だね。
gitでもローカルではこまめにコミットするよ。
gitでは、みんな整えてからサーバーにプッシュしてくれるから、機能単位になるけどね。
SVNでそれは出来ないし、現状そういう使い方には向かない。

>>53
最も過ぎて感動した。

**デフォルトの名無しさん** · 2014/08/12(火) 23:31:31.61

>>53
ゼロにしろって話じゃない。
少なくしろって話。

**デフォルトの名無しさん** · 2014/08/12(火) 23:50:23.60

>>55
そうだね。むやみに細かなコミットはするべきじゃないよ。
それと、固まったところを切り出してコミットをするのをやめろって話とは矛盾しない。

開発の概念的なステップにおいて不可分なものについて、一部を切り出してコミットするという話ではないし、
逆に>>48でいうところの3つのサブ処理が互いに疎ではないのであれば、Aのみをコミットするのはどうかと思う。

分けるべきことと分けてはいけないことを把握できてるなら、たぶん考えてることは同じだと思う。

**デフォルトの名無しさん** · 2014/08/12(火) 23:51:26.61

s/をするのをやめろ/したほうがいい/

**デフォルトの名無しさん** · 2014/08/12(火) 23:52:57.40

なんかこう、>52は根本的なところでVCSを理解できていないか
それとも何かの教条主義に陥っているのか。
いずれにしても、tagやコミットログを使いこなせていないのだろう。

**デフォルトの名無しさん** · 2014/08/13(水) 00:05:50.29

経験則でいうと、手当たり次第に手をつけながら改修を行うような人にはVCSは向かないと思う。
それはひとえにコミット単位が大きくなりすぎるからという理由。
この手の人は大抵コンフリクトに頭を抱え、VCSに対して文句を言う羽目になってる。

時がたち、コミット単位をうまくまとめられるようになったころには、
手当たり次第に改修するというスタイルは矯正されてると思う。

**デフォルトの名無しさん** · 2014/08/13(水) 00:07:16.21

そもそもツールに問題があるとは考えないのか？

gitではできるが
subversionではできないんだよ。

**デフォルトの名無しさん** · 2014/08/13(水) 00:09:19.27

>>59
> 経験則でいうと、手当たり次第に手をつけながら改修を行うような人にはVCSは向かないと思う。

それは違うな。

>>53が言っているように、
> じゃあ、いつコミットできるの？
> バグが一切存在しないコードを書けるクヌース先生みたいな人なのかな。

バグが一切存在しないことはない。
だから手当たり次第にコミットすしたのと同じことになる。

だからこそgitではそれを後から修正できるようにした。

subversionというツールに問題があるんですよ。

**53=59** · 2014/08/13(水) 00:11:57.89

だめだこりゃ。

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

個人的には、意味のある単位であれば、コミットは細い程良いと思ってる。
その、程々の粒度のコミット単位を見つけられるかが経験なのかもしれないけどね。
俺も経験上の話をすると、でかいコミットをカマス奴は信用できないヤツが多い。
しかも、不具合やリファクタリングを指摘しても、何だかんだで直してくれない。
(その理由の一つが、履歴が汚れるからとか、おかしいだろ…)

**デフォルトの名無しさん** · 2014/08/13(水) 03:17:33.31

とりあえずgit-svn使っとけばいいんじゃね

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

>>63
あるある
所詮開発ツールのログにすぎないのに、そのログの保守が目的になっちゃう人
極端に偏るのはウザいし、業務遂行の妨げだよね～
程々でいいんだよ、何事もバランスが大切

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

>>48
A, B, C 用にブランチ切って各々単体テストまで完了してからコミットすれば？

**デフォルトの名無しさん** · 2014/08/13(水) 10:50:51.37

>>56
> 逆に>>48でいうところの3つのサブ処理が互いに疎ではないのであれば、Aのみをコミットするのはどうかと思う。
つか、互いに疎になるように分割しないと駄目なのでは？

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

ま、手段と目的が逆転している感はあるな

**デフォルトの名無しさん** · 2014/08/13(水) 11:45:42.27

まあ、「ある機能」の規模感が人によってさまざまで、だから意見が食い違ってる気がする。
俺の場合は、「機能」で分割した場合、コードの行数は500～3000行くらいで、500行の場合でも
クラスを3つ、メソッドそれぞれ10～30行とかで、メソッド一つ～数個ごとにコミットする感じ。

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

1.9　って、ＤＢ機能の強化がメインなのか？

バックグランドの機能強化とか誰得なんだ？

**デフォルトの名無しさん** · 2014/08/14(木) 02:24:10.10

http://svn.apache.org/repos/asf/subversion/tags/1.8.10/CHANGES

**デフォルトの名無しさん** · 2014/08/14(木) 08:47:18.57

>>71
これ、なんだ？
Developer-visible changes: - General:
* support generating VS 2013 and later project files.

**デフォルトの名無しさん** · 2014/08/14(木) 11:27:09.25

大規模CI環境になるとsvnが性能ネックになりうるので
バックエンドの強化は地味ながら効果的

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

データベースを強化しないと機能追加が難しい。急がば回れ。
OSS関係はgitが主流になったんで開発を急ぐ必要も無いから

**デフォルトの名無しさん** · 2014/08/16(土) 15:29:40.52

http://www.buzzword.jp/img/face10.png

**デフォルトの名無しさん** · 2014/08/16(土) 15:33:06.06

ぐろ

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

Git 対 Subversion：長引く争い
http://readwrite.jp/archives/4492

**デフォルトの名無しさん** · 2014/08/18(月) 21:10:12.16

>>77
subversionにもメリットがあって、
gitとsubversionのどちらがいいか戦ってるって
話かと思ったら、

Subversionの呪縛から抜だしてGitへ移行する戦い・・・が長引いてるって
って話でワロタｗ

タイトルの訳間違ってるだろｗｗｗ

**デフォルトの名無しさん** · 2014/08/18(月) 21:38:25.14

みんなそんなにSVNに困ってるの？

**デフォルトの名無しさん** · 2014/08/18(月) 21:44:14.15

gitに移行した方がいいプロジェクトも確かにあるけど、
プログラマー以外の職種が多い場合や、
巨大なデータを扱うのがメインだと難しいね

**デフォルトの名無しさん** · 2014/08/18(月) 23:28:18.45

>>77
すでにコメントで指摘されてるけど、下二つのグラフが同じだな
おぼちゃんじゃないけど、こういうミスがある記事はあまり信頼できない

**デフォルトの名無しさん** · 2014/08/18(月) 23:59:55.48

適材適所という言葉が奴らの辞書には載ってないんだよ

**デフォルトの名無しさん** · 2014/08/19(火) 01:07:57.99

適材適所？中央リポジトリには
subversionが適してると思ってる？

残念。中央リポジトリにしか使えないんだよ。
rebaseできないからな。

**デフォルトの名無しさん** · 2014/08/19(火) 01:10:04.56

>>79
うん。困りまくり。

小さくコミットが出来ない。
コミットした後で並び替えできない。

ブランチ切り替えに時間かかる。
そもそも、ブランチ切るのが大変
Subversionじゃ気軽に何十個もブランチ切れない。

こんなの使えないよ。

**デフォルトの名無しさん** · 2014/08/19(火) 01:15:51.90

自分中心でしか語れないクズは去っていいよ

**デフォルトの名無しさん** · 2014/08/19(火) 01:57:10.27

他人のことを考えたとしても、
できることは多いほうがいいよ？

**デフォルトの名無しさん** · 2014/08/19(火) 11:28:17.07

>>86
> できることは多いほうがいいよ？

多機能家電に憧れちゃう人？ w
git はもう少し機能を整理した方がいいと思う。

**デフォルトの名無しさん** · 2014/08/19(火) 11:41:44.97

VCSに何を求めるか人それぞれなんだから意見が合うはずがない
ほっとけよ

**デフォルトの名無しさん** · 2014/08/19(火) 20:56:55.78

gitはログ追うのも難儀するからな

**デフォルトの名無しさん** · 2014/08/19(火) 20:57:40.71

NEATe68i

**デフォルトの名無しさん** · 2014/08/19(火) 21:34:51.65

>>88
VCSにrebaseを求めない人がいるのが信じられないんだけど。
だって普通開発してたらケアレスミスするじゃん？
コミットした後で気づくってよくある話だと思うけど。
ケアレスミスじゃなくても単にバグとかさ。

**デフォルトの名無しさん** · 2014/08/19(火) 21:46:10.76

そんなのは普通に直して普通にコミットすればよろしい。
rebeaseだのはVCS的には邪道。
うっかりだろうとケアレスミスだろうと、それすらも履歴として残すことに
本来的な意味がある。

**デフォルトの名無しさん** · 2014/08/19(火) 21:59:43.08

わからないな。
ミスさえしなければ、本来できるはずがなかったコミットを
残す理由って何よ？

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

もちろん単なる履歴だ。それ以外に特別な意味はない。
すべてのコミットが単なる履歴なのだから、強いて言えば「こんな馬鹿な奴が
いました。次のプロジェクトからは外した方がいいですよ～」という証拠でもある。

**デフォルトの名無しさん** · 2014/08/19(火) 22:10:09.40

>>94
じゃあ、そのコミットに価値はないって認めるわけだね？

**デフォルトの名無しさん** · 2014/08/19(火) 22:15:43.48

コミットの価値を理解しないとダメだよ。

コミットというのは、その一つを取り込んだり取り外したり
どこで問題が入ったかを調べたりするもの。
そういう風に利用できなければコミットにする理由がない。

それができるためには、1つのコミットが意味のある単位に
なっていなければいけない。

意味のある単位をむやみに分割したりとか
複数の単位をまとめてしまったら、コミットが使えなくなる。

**デフォルトの名無しさん** · 2014/08/19(火) 22:17:29.06

rebase出来るということは潜在的に「履歴を間違えて消してしまう」リスクを背負う事になっちゃうからね。
ま、ローカルでのrebaseであれば作業者の責任範囲なのでウェルカムこの上ないんだけど。

人間だから、コードにバグ入れるのも当たり前、コミットミスするのも当たり前、同様にrebaseミスするのも当たり前だということ。
この中で一番ミスった時のリスクが高いのがrebaseなので、不要と考える人の気持ちもわかる。

**デフォルトの名無しさん** · 2014/08/19(火) 22:18:32.84

rebaseでミスっても、簡単に元に戻せるから
問題ないのでは？

**デフォルトの名無しさん** · 2014/08/19(火) 22:35:26.02

もちろんすぐに気付けばreflogとかでやり直せばいいと思うし、ローカルでやってくれる分には別に気にしないよ。
共有リポジトリに対してやられたりして、更に何らかのミスていることに気づかないで放置されると後々面倒だなーと。
人のコミットまでrebaseできちゃうわけだし。

**デフォルトの名無しさん** · 2014/08/19(火) 22:38:27.65

勿論欲しい事は欲しいんだけど、集中型のsvnには、「まだ」時期尚早な機能じゃね？

**デフォルトの名無しさん** · 2014/08/19(火) 22:40:19.87

やっとわかった。自分勝手な基準で「意味のあるコミット」だとか
「意味のないコミット」だとか、そういうものが存在するという幻想を
抱いてるレベルなのか…
できればVCSを使わないで欲しいな、そんな奴には…

逆なんだよ、「コミットする事に意味がある」んだって分かって欲しいね。

**デフォルトの名無しさん** · 2014/08/19(火) 22:43:40.49

>>99
> 人のコミットまでrebaseできちゃうわけだし。

人のコミットって言っても、それローカルじゃないでしょ？
”人のコミット”といえば、ローカルの話だと思うんだけど？

ローカル（つまり自分のhome以下）にあるものは普通
ディレクトリ共有しないのだからそれは勝手にrebaseできないよな。

で、サーバーにあるものは勝手にrebaseされたとしても気づく。
（ローカルと食い違ってるのでちゃんと知らせてくれる）

そもそもローカルにある自分のコミットがオリジナルで
そっちは無事なので何の問題もないけど。

**デフォルトの名無しさん** · 2014/08/19(火) 22:44:18.54

>>101
おいｗせめて何か言い返せよｗ

**デフォルトの名無しさん** · 2014/08/19(火) 22:45:12.28

目的と手段が入れ替わってるんだろうな。
コミットすることが目的になっちゃってる。

コミットを使わないと
何の意味もないのに。

**デフォルトの名無しさん** · 2014/08/19(火) 22:48:07.47

>>101
直線履歴が基本のsvnだと確かに全ての作業ログを残して欲しくなるね。
でも、ブランチと機能コミットが基本の分散型だと、すごーく履歴がカオスになるので、rebaseで直線化して欲しくなる気持ちもわかるよ。

**デフォルトの名無しさん** · 2014/08/19(火) 22:50:06.96

あぁ、作業ログ。そうかsubversionは
単なる作業ログなんだ。

コミットを使うという発想がないんだね。
オープンソースの開発なんかだと
コミットを送ったりするわけだけど、

そうか単なる作業ログか。

**デフォルトの名無しさん** · 2014/08/19(火) 22:50:38.55

>>102
話変わるけど、svn使ったことある?

**デフォルトの名無しさん** · 2014/08/19(火) 22:54:40.94

>>106
アオリたいだけなら、俺はもう引っ込むね。
そんなやり合いには何の実もないから。
適材適所なんだから、そういう突っかかり方するのもどうかと思うよ。

**デフォルトの名無しさん** · 2014/08/19(火) 22:54:49.52

>>107
あるけどそれが？

svn使っている時から苦痛だったよ。
コードレビューしやすいように
したかったのだが無理だった。

git使ってから、ツールが悪かったんだなって
わかった。

**デフォルトの名無しさん** · 2014/08/19(火) 22:56:33.30

>>108
だって作業ログなんでしょ？

コミットする事に意味があるだっけ？
コミットすることが目的だみたいなこと言ってるし。

言いたいことがあるのなら言い返せばいいのに
それもできないでいるしさ。

**デフォルトの名無しさん** · 2014/08/19(火) 22:58:42.34

社内の仕事だったら、適当な作業ログでいいかもしれないけどさ、
これが赤の他人に提出するパッチだったら
コードはちゃんとレビューできるようになってないとダメだよ。
赤の他人のコードなんて信用出来ない。

コミットがきちんと理解できるように
意味のある単位に分かれていなければ、
受け取ってもらえない。

**デフォルトの名無しさん** · 2014/08/19(火) 23:07:57.10

>>111
何だ、適材適所という事をわかってるじゃないか。
それなのに何でそこまで君の正義を主張したがる？

君の言うことは正しい。
でもそれが全てじゃない。

**デフォルトの名無しさん** · 2014/08/19(火) 23:34:01.17

>>101
変な状態でコミットされてもなー

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

バカには無理

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

>>77
>>81
読んだ感じでは、俺が感じていたのと殆ど同じなので、違和感が無い。

2010年頃から、雪崩のようにsvnからgitへ人が移動していったと感じていたけど
記事を見て、自分の思っていた通りだったと確信した。

SVNに関する需要が0になる事は無いと思うからどこかで、下げ止まると思うけど

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

svnを使う理由は「今更やめられない」か
「新しいものを覚えたくない」だけになりそうだね。

**デフォルトの名無しさん** · 2014/08/20(水) 02:23:43.02

機能で言えばgit > svnなんだよな

gitはsvnの代わりに使えるが、
svnはgitの代わりにはならない。

**デフォルトの名無しさん** · 2014/08/20(水) 03:17:17.30

svnは一部のcoできるけどgitは・・

**デフォルトの名無しさん** · 2014/08/20(水) 03:34:47.62

svnはコミット単体でが何というブランチになされたものかわかるけど、gitは…

**デフォルトの名無しさん** · 2014/08/20(水) 04:37:57.36

>>118-119
でもそれって、できても役に立たないですよね？

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

一部coは明らかに有用。

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

巨大プロジェクト全体のcloneなんて無駄なことしたくないからね

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

gitがoss向きなのは明らかだね。
自然集約と自然淘汰を本質とするossの性質に良くマッチしている。
一方、統制を基本とする企業という枠組みの中では必ずしもマッチするものではないと思う。
ただ、企業と言ってもこれまた多種多様で、ソフトウェア実装専門であればgitが適していると思う。
gitは良くも悪くもテキストに特化したツールだから、他の文書や成果物を合わせて管理するには向いていない。

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

ソースコードだけ対象で、計画的な開発体制が出来てるならgitの方がいいと思う
そうでない場合、subversionがいい場合もある

**デフォルトの名無しさん** · 2014/08/21(木) 02:22:10.31

>>122
巨大プロジェクトってたとえばどんなの？

もしかして無関係のものまで
一つのリポジトリに入れちゃったりしない？

だめだよ。プロジェクトごとに
リポジトリは分けなきゃ。

**デフォルトの名無しさん** · 2014/08/21(木) 02:27:08.87

大手自動車メーカの走行テレメトリーデータ

**デフォルトの名無しさん** · 2014/08/21(木) 02:39:29.35

ん？またソースコードを管理するから
ソースコード管理ツールに
データ入れてるって話？

**デフォルトの名無しさん** · 2014/08/21(木) 03:55:04.90

ソースコード管理ツールﾜﾛﾀ

**デフォルトの名無しさん** · 2014/08/21(木) 04:52:59.29

>>125
> だめだよ。プロジェクトごとに
> リポジトリは分けなきゃ。
なぜ？

**デフォルトの名無しさん** · 2014/08/21(木) 09:40:57.19

伸びてると思ったら案の定こんな話か

**デフォルトの名無しさん** · 2014/08/21(木) 10:18:28.92

>>125のように頭の悪い奴が支持してるのがgit

**デフォルトの名無しさん** · 2014/08/21(木) 10:50:44.47

>>129
dump, restoreが重すぎる。リポジトリが大きくなるともうだめぽ。

**デフォルトの名無しさん** · 2014/08/21(木) 12:39:31.40

だがヘボが管理するとプロジェクトごとのバージョン合わせに無駄な手間が

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

「プロジェクト」の定義は？

**デフォルトの名無しさん** · 2014/08/21(木) 22:13:47.40

おれも問題はそこだと思う。

実行ファイルにコンパイルされるソース一式と仮定すると、
たとえばひとつの実行ファイルだけで完結してしまって、
他の実行ファイルとの関係など全くないような
小さなモノしか扱ったことのないやつにとっては、きっと
(実行ファイル) = (プロジェクト) = (リポジトリ)
という頭しかないんだろ。

**デフォルトの名無しさん** · 2014/08/21(木) 22:37:19.35

>>134
> 「プロジェクト」の定義は？
プロジェクトっていうか
プロダクトかな。

プログラマなら疎結合にする重要性は知っていると思うが、
プロジェクト定義は別々にリリースしても問題ない単位でいいんじゃないかな
または別々のバージョン番号をつけている単位でもいいかも
ようするに商品として独立していること。

**デフォルトの名無しさん** · 2014/08/21(木) 22:40:07.04

>>135
プロジェクトには複数の実行ファイルがあるわけだけど、、
当たり前だけど、それでも全部を一つのリポジトリに入れたらダメだよね。
無関係のものもあるわけだし。

プロジェクトごとにリポジトリを分ける。
一つのプロジェクト（リポジトリ）には複数の実行ファイルが入ってる。
これが理想だろうね。

**デフォルトの名無しさん** · 2014/08/21(木) 22:43:54.55

使いやすいように使えばいい、理想なんかねーよ。ハゲ。

**デフォルトの名無しさん** · 2014/08/21(木) 22:47:31.02

全部一つにまとめると。一部だけ移動したりする時とかに
使いにくくなるんだよな。

特定のプロジェクトにはアクセス制限かけるとかさ。

（使いにくいから）一つのプロジェクトに
まとめるなという話をしてる。

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

>>139
使いにくくなるのは、おめーが使い方知らないだけ。

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

>>137
関連する実行ファイルのソースはすべてひとつのリポジトリに揃ってないと、
各実行ファイル間の関係を追跡できなくなってしまう。
プロジェクトが「プロダクト(製品)」の意味ととらえても、
おれのところではひとつの製品の中に無関係のものなんてないし、
ひとつのソース一式が複数の製品で利用されてたりもするから、
それらが全部同じリポジトリにないと管理ができなくなる。

また、ひとつの製品は過去のバージョンとの連続性もあるが、
過去の経緯によってもモジュール間の依存関係は変わってくる。
無関係のものをその時点の状況だけで別のリポジトリに分けてたら収集がつかない。

パッケージ商品の開発では、ひとつの部署で開発した成果物はひとつのリポジトリに納めてる。
特定の顧客から発注された開発では専用のリポジトリを作ることもあるけど、
パッケージ商品の一部成果物を利用して工数を削減したりするので、
パッケージと同じリポジトリにブランチを切ってそこに突っ込むことが多い。
でないと、パッケージ商品に含まれてる標準のものと
特定顧客向けに一部修正したものとの履歴の違いがわからなくなる。

結局、おれのところでは基本的にライセンスや使用許諾条件によってリポジトリを分けてるかな。
異なるライセンスのソースが同じリポジトリにあっちゃマズイから。

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

関連する実行ファイルのソースはすべてひとつのリポジトリに揃ってないと、
各実行ファイル間の関係を追跡できなくなってしまう。

逆に言えば、関連しなければ何の問題もない。

これ以上の話はする必要がないとおもう

**デフォルトの名無しさん** · 2014/08/22(金) 09:02:34.71

急に禅問答になった。

**デフォルトの名無しさん** · 2014/08/22(金) 13:37:43.59

リポジトリは分けた上で、リビジョン指定のsvn:externalsで関連付けたらいいのでは

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

やり方は沢山あって、それなりに一長一短ある。
> オレ様のやり方が一番良い。オレ様のやり方でやるべき。
と言い出すバカは死んでくれ。

**デフォルトの名無しさん** · 2014/08/22(金) 19:01:58.40

まあこの辺りを読んどけって言う話だわな
http://svnbook.red-bean.com/en/1.7/svn.reposadmin.planning.html

**デフォルトの名無しさん** · 2014/08/23(土) 00:06:04.33

雑多なファイル、資料を扱うときに部分チェックアウトは凄く便利だよな

**デフォルトの名無しさん** · 2014/08/23(土) 00:43:59.83

>>142
むやみにひとつのリポジトリで運用すべきではないという主張になってると思うんだけど、
当初はdump restoreが重過ぎるからひとつにするなといっていたよね。

言葉を変えると、
むやみにリポジトリを分けてしまうと追跡できないものが生まれうるというところに異論は無いと思うんだけど、
dump restoreが重いという理由以外にひとつにまとめるべきではないという理由は何かあるの？

ちなみにdump restoreの重さが気になる頻度でそれを行っているのなら、そこを改めるべきだと思う。

**デフォルトの名無しさん** · 2014/08/23(土) 00:48:28.44

開発元がひとつにまとめてる時点でないだろ

**デフォルトの名無しさん** · 2014/08/23(土) 06:47:22.27

>>148
当初はじゃなくて独立した理由だろ。アホウ。

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

パッケージ管理とバージョン管理の区別が付いてないと
悲惨なリポジトリになる

**デフォルトの名無しさん** · 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切れ、くらいで運用してる。