TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
【実験台】 Python 3.0 のお勉強 Part 1 【非互換】
【PHP】下らねぇ質問はここに 9
Java入門・初心者質問スレ Part.10
くだすれDelphi(超初心者用)その57
次世代が造った言語 blawn
【O3D】HTML5用 3D API WebGL 【Canvas:3D】
コメント研究すれ。
日本語プログラミング言語Mind
[RPA]PC自動化技術総合スレ[効率化] Part.6
MATLABプログラミング 質問箱 その4
Subversion r15
- 1 ：2014/08/02 〜 最終レス ：2019/12/13
- Subversionはフリーなオープンソースのバージョン管理システムです。
公式HP
Apache Subversion
http://subversion.apache.org/
ようこそSubversion.JPコミュニティへ
http://www.subversion.jp/
- 2 ：
- 前スレ
r14 http://peace.2ch.sc/test/read.cgi/tech/1326806859/
r13 http://toro.2ch.sc/test/read.cgi/tech/1286654542/
r12 http://hibari.2ch.sc/test/read.cgi/tech/1254838551/
r11 http://pc12.2ch.sc/test/read.cgi/tech/1230488758/
r10 http://pc11.2ch.sc/test/read.cgi/tech/1215565366/
r9 http://pc11.2ch.sc/test/read.cgi/tech/1202086238/
r8 http://pc11.2ch.sc/test/read.cgi/tech/1192864879/
r7 http://pc11.2ch.sc/test/read.cgi/tech/1180858500/
06 http://pc11.2ch.sc/test/read.cgi/tech/1165892754/
05 http://pc8.2ch.sc/test/read.cgi/tech/1145841405/
04 http://pc8.2ch.sc/test/read.cgi/tech/1129642894/
03 http://pc8.2ch.sc/test/read.cgi/linux/1100622362/
02 http://pc5.2ch.sc/test/read.cgi/linux/1078609142/
01 http://pc.2ch.sc/test/read.cgi/linux/1002355536/
- 3 ：
- 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/
- 4 ：
- ◆関連スレ
バージョン管理システムについて語るスレ10 [プログラム板]
http://peace.2ch.sc/test/read.cgi/tech/1393147031/
CVS 1.3 [UNIX板]
http://peace.2ch.sc/test/read.cgi/unix/1093611448/
CVS導入スレ〜 Rev.3 [プログラム板]
http://peace.2ch.sc/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://maguro.2ch.sc/test/read.cgi/linux/1154701996/
Git 10 [プログラム板]
http://peace.2ch.sc/test/read.cgi/tech/1403426425/
【分散型バージョン管理】 Mercurial 2【hg】 [プログラム板]
http://peace.2ch.sc/test/read.cgi/tech/1321109748/
【bzr】Bazaarでバージョン管理 Rev 4 [プログラム板]
http://peace.2ch.sc/test/read.cgi/tech/1356521407/
- 5 ：
- ■記事(最近)
「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
- 6 ：
- >>5
> ― なぜ Git ではなく、SVN を使うのか？
ローカルコミットをサポートしてクレー
- 7 ：
- subvertionがgitになるなら
もうgitを使ったほうがいい気がするがｗ
- 8 ：
- http://www.buzzword.jp/img/face10.png
- 9 ：
- グロ
- 10 ：
- subvertionから移行しやすいのは、gitでなくhg
- 11 ：
- その前にsubvertionて何ですのん
- 12 ：
- アナル拡張器具
- 13 ：
- hage?
- 14 ：
- スケーラビリティが向上するんだよ
- 15 ：
- subversion は良くも悪くも普通のバージョン管理ツールだけど
git って、パッチ管理（リモート、ローカル）＆マージ処理に特化したのが勝因だよなー
Linusとしては自分に必要な、Linuxのパッチ適用に必要な機能だけ
あればよいって言う考えでgitを設計したんだろうけど。
- 16 ：
- subversionはソースコードを管理するツール
gitは機能単位でコミットを作るための開発ツール
- 17 ：
- フツーの業務システム開発ならsvnのtrunk一本でそれほど困らんけどね
複数人で同じソースをいじくりまわしてマージが大変なんてことは無いし
- 18 ：
- >>17
ぼっち開発者の俺はtrunkだけでほぼいける。
以前のバージョンに戻すこともめったにない。
ビルド出来ないとか、動作が不完全のような中途状態で取っておきたいときに
ブランチを作って、ＯＫになったらtrunkへマージする。
このブランチ側の作業を、ローカルリポジトリか何かで自動化できるとうれしい。
gitのリモート/ローカルってそういうものなんだろーなーと指を加えて見てる。
- 19 ：
- 大改造する時にはブランチきるだろ JK
- 20 ：
- >>19
ぼっち開発ならそのまま trunk 上で開発もありだろ
どうしても途中で元のバージョンに修正入れたいなら、その時ブランチ切ればいいんだし
- 21 ：
- git ⊃ SVN と思ったが違うのか
- 22 ：
- >>21
コミットの考え方が違うね。
svnは単なる作業履歴って感じだけど、
gitはコミットを一つ一つに意味があって
大事にしている。
- 23 ：
- 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以降は、日本語の記事も極端に減った感じがする
- 24 ：
- gitは機能が多すぎ
- 25 ：
- 多いというか、整理されていないというか
かといって無いと不便というか
慣れるしかないというか
- 26 ：
- 新しく始めるときはgit使うようにしてるけど、慣れたらsvn使うの面倒くさく感じるようになってきた。
- 27 ：
- うん
そうだね
- 28 ：
- >>20
その運用するなら「元のバージョン」として扱うだろうと考えられるリビジョンでタグ打っときなよ
- 29 ：
- >>25
> 整理されていないというか
ほんこれ
確かにあったらいいな〜は、あるんだけど、なれるまでがちょい大変
>>28
ぼっち開発だとログもたいしたことないし...
まあ、リリース毎には外部バージョンでタグ打つけどね
- 30 ：
- http://www.buzzword.jp/img/face10.png
- 31 ：
- guro
- 32 ：
- 一人でやってると、コミットの扱いが雑にならね？
何か修正している時に、つい近くの
コードが気になって関係ないのに修正しちゃう。
で、コミットメッセージに○○の修正って書いてるのに、
無関係の修正が含まれてたり。
- 33 ：
- あるある〜
- 34 ：
- 狭く深くか、広く浅くかで分けて
広く浅い方は「後で絶対に戻さない」という信念を持ってコミットする
- 35 ：
- > 広く浅い方は「後で絶対に戻さない」という信念を持ってコミットする
一つ一つに信念を持たないと
コミットできないなら疲れるってｗ
人間である以上、漏れっていうのは絶対にある。
こんな些細な事はあとから修正すればいい話でgitならそれができる。
- 36 ：
- 単に数日前に戻りたいだけとか、コミットにいちいち信念なんてうぜーとかなら、
別にわざわざscm使う必要なくね?
そういうやつはどうせコミットメッセージなんてロクにつけないんだろ?
このスレでいうのもなんだが、そういう使い方しかしないんなら、
nilfs2などのログファイルシステム使っとけば十分な気がするが。
webdavなクラウドストレージでもいいし。
無理してscm使う必要ないと思うけど。
- 37 ：
- コミットの内容に気を使うか、
単なるバックアップとして使うかの
違いだよね。
バックアップとしてしか使ってない人は
ソースコードを管理しているわけじゃないというだけのこと。
- 38 ：
- SVKって、なんで廃れたの？
- 39 ：
- 差分確認したいから使うわけだが
- 40 ：
- その差分が、一日とかの時間単位の差分なのか
コミット＝機能 単位の差分なのかで意味が違ってくるけどな。
しっかりコミットには機能を含ませないとダメだよ。
○機能のコミット、間を空けて、○機能のバグ修正とか
機能が複数のコミットに分断されたりすると、差分調べづらいからさ。
- 41 ：
- >>40
一機能が数十ファイルに渡る数千行の変更になることが普通だから、機能毎のcommitは粒度が大きすぎる。
- 42 ：
- 粒度が小さくしようと思えば、
コミットの回数は必然的に多くなると思うけど、
そうすると大変にならね？
ちょっとしたミスでもしないように
心がけないといけないから、テストに時間が掛かる。
- 43 ：
- >>42
昔、１つの障害直すのに機能修正用に一回コミットして、
その後ソースのインデント変更でもう一回コミットとかした事がある。
確かに細かくコミットした方が後で見るときに分かりやすいというのはある。
- 44 ：
- http://www.buzzword.jp/img/face10.png
- 45 ：
- >>40
ブランチ作ればいいんでないのと思うんだけど、それではだめなのかな。
>>42
粒度を小さくするってことは、固まったところからコミットしていくということなので
特にテストの手間は増えないよ。
>>43
気持ちは分かるんだけど、インデントに関してのみいえばdiffのオプションで
インデント変更を無視することができるので、分けなくても大丈夫。
むしろ、特定リビジョンにおいてインデントが崩れている状態を生み出したというのは
個人的にはあまりよろしくないと思う。
- 46 ：
- 1.8.10が出たのか
そろそろgitに移行するかなー
- 47 ：
- >>45
> 粒度を小さくするってことは、固まったところからコミットしていくということなので
> 特にテストの手間は増えないよ。
固まった所からコミットするってどうやるの？
ファイルの一部分だけコミットとか出来ないよね？
- 48 ：
- あと固まった所からコミットというのは
作業が直列化してるんだよね。
ある機能を作ろうと思ったら、
・サブ処理A
・サブ処理B
・サブ処理C
みたいな感じで機能を作っていくでしょ？
その時サブ処理Aができたーと思って
B、Cを作っていくけど、その間に見逃しがあったり
問題が見つかって再設計が必要になる。
そういうときサブ処理Aのコミットを
修正できないのはキツイよね。
- 49 ：
- >>48
> そういうときサブ処理Aのコミットを
> 修正できないのはキツイよね。
言ってる意味がわからないんだが・・・。
BあるいはCをきりのいいところでcommitして、Aを修正すればいいのでは・・・。
- 50 ：
- >>49
そうすると、Aのコミットと
Aの修正のコミットの二つが出来るでしょ？
- 51 ：
- うん。
そういうものを管理するためのツールだもの。
- 52 ：
- >>51
意味を考えたことある？
Aのコミット＋Aの修正であれば、その二つを
まとめたコミットが一つだけあれば十分。
もちろんリリースした後なら別に分けたほうがいいけど、
一時間前に書いたコードのケアレスミスとか残す価値はない。
残しておけば、過去のコードを見る必要がある時
（見る必要があるから残すわけで）余計な手間がかかる。
コミットの内容を小さくすればするほど、無駄なコミットはなくそうと
考えるのが普通では無いかな？
- 53 ：
- >>52
確かにバグ修正のコミットは結果的に言えば無駄だね。
じゃあ、いつコミットできるの？
バグが一切存在しないコードを書けるクヌース先生みたいな人なのかな。
- 54 ：
- >>52
詭弁だね。
gitでもローカルではこまめにコミットするよ。
gitでは、みんな整えてからサーバーにプッシュしてくれるから、機能単位になるけどね。
SVNでそれは出来ないし、現状そういう使い方には向かない。
>>53
最も過ぎて感動した。
- 55 ：
- >>53
ゼロにしろって話じゃない。
少なくしろって話。
- 56 ：
- >>55
そうだね。むやみに細かなコミットはするべきじゃないよ。
それと、固まったところを切り出してコミットをするのをやめろって話とは矛盾しない。
開発の概念的なステップにおいて不可分なものについて、一部を切り出してコミットするという話ではないし、
逆に>>48でいうところの3つのサブ処理が互いに疎ではないのであれば、Aのみをコミットするのはどうかと思う。
分けるべきことと分けてはいけないことを把握できてるなら、たぶん考えてることは同じだと思う。
- 57 ：
- s/をするのをやめろ/したほうがいい/
- 58 ：
- なんかこう、>52は根本的なところでVCSを理解できていないか
それとも何かの教条主義に陥っているのか。
いずれにしても、tagやコミットログを使いこなせていないのだろう。
- 59 ：
- 経験則でいうと、手当たり次第に手をつけながら改修を行うような人にはVCSは向かないと思う。
それはひとえにコミット単位が大きくなりすぎるからという理由。
この手の人は大抵コンフリクトに頭を抱え、VCSに対して文句を言う羽目になってる。
時がたち、コミット単位をうまくまとめられるようになったころには、
手当たり次第に改修するというスタイルは矯正されてると思う。
- 60 ：
- そもそもツールに問題があるとは考えないのか？
gitではできるが
subversionではできないんだよ。
- 61 ：
- >>59
> 経験則でいうと、手当たり次第に手をつけながら改修を行うような人にはVCSは向かないと思う。
それは違うな。
>>53が言っているように、
> じゃあ、いつコミットできるの？
> バグが一切存在しないコードを書けるクヌース先生みたいな人なのかな。
バグが一切存在しないことはない。
だから手当たり次第にコミットすしたのと同じことになる。
だからこそgitではそれを後から修正できるようにした。
subversionというツールに問題があるんですよ。
- 62 ：
- だめだこりゃ。
- 63 ：
- 個人的には、意味のある単位であれば、コミットは細い程良いと思ってる。
その、程々の粒度のコミット単位を見つけられるかが経験なのかもしれないけどね。
俺も経験上の話をすると、でかいコミットをカマス奴は信用できないヤツが多い。
しかも、不具合やリファクタリングを指摘しても、何だかんだで直してくれない。
(その理由の一つが、履歴が汚れるからとか、おかしいだろ…)
- 64 ：
- とりあえずgit-svn使っとけばいいんじゃね
- 65 ：
- >>63
あるある
所詮開発ツールのログにすぎないのに、そのログの保守が目的になっちゃう人
極端に偏るのはウザいし、業務遂行の妨げだよね〜
程々でいいんだよ、何事もバランスが大切
- 66 ：
- >>48
A, B, C 用にブランチ切って各々単体テストまで完了してからコミットすれば？
- 67 ：
- >>56
> 逆に>>48でいうところの3つのサブ処理が互いに疎ではないのであれば、Aのみをコミットするのはどうかと思う。
つか、互いに疎になるように分割しないと駄目なのでは？
- 68 ：
- ま、手段と目的が逆転している感はあるな
- 69 ：
- まあ、「ある機能」の規模感が人によってさまざまで、だから意見が食い違ってる気がする。
俺の場合は、「機能」で分割した場合、コードの行数は500〜3000行くらいで、500行の場合でも
クラスを3つ、メソッドそれぞれ10〜30行とかで、メソッド一つ〜数個ごとにコミットする感じ。
- 70 ：
- 1.9 って、ＤＢ機能の強化がメインなのか？
バックグランドの機能強化とか誰得なんだ？
- 71 ：
- http://svn.apache.org/repos/asf/subversion/tags/1.8.10/CHANGES
- 72 ：
- >>71
これ、なんだ？
Developer-visible changes: - General:
* support generating VS 2013 and later project files.
- 73 ：
- 大規模CI環境になるとsvnが性能ネックになりうるので
バックエンドの強化は地味ながら効果的
- 74 ：
- データベースを強化しないと機能追加が難しい。急がば回れ。
OSS関係はgitが主流になったんで開発を急ぐ必要も無いから
- 75 ：
- http://www.buzzword.jp/img/face10.png
- 76 ：
- ぐろ
- 77 ：
- Git 対 Subversion：長引く争い
http://readwrite.jp/archives/4492
- 78 ：
- >>77
subversionにもメリットがあって、
gitとsubversionのどちらがいいか戦ってるって
話かと思ったら、
Subversionの呪縛から抜だしてGitへ移行する戦い・・・が長引いてるって
って話でワロタｗ
タイトルの訳間違ってるだろｗｗｗ
- 79 ：
- みんなそんなにSVNに困ってるの？
- 80 ：
- gitに移行した方がいいプロジェクトも確かにあるけど、
プログラマー以外の職種が多い場合や、
巨大なデータを扱うのがメインだと難しいね
- 81 ：
- >>77
すでにコメントで指摘されてるけど、下二つのグラフが同じだな
おぼちゃんじゃないけど、こういうミスがある記事はあまり信頼できない
- 82 ：
- 適材適所という言葉が奴らの辞書には載ってないんだよ
- 83 ：
- 適材適所？ 中央リポジトリには
subversionが適してると思ってる？
残念。中央リポジトリにしか使えないんだよ。
rebaseできないからな。
- 84 ：
- >>79
うん。困りまくり。
小さくコミットが出来ない。
コミットした後で並び替えできない。
ブランチ切り替えに時間かかる。
そもそも、ブランチ切るのが大変
Subversionじゃ気軽に何十個もブランチ切れない。
こんなの使えないよ。
- 85 ：
- 自分中心でしか語れないクズは去っていいよ
- 86 ：
- 他人のことを考えたとしても、
できることは多いほうがいいよ？
- 87 ：
- >>86
> できることは多いほうがいいよ？
多機能家電に憧れちゃう人？ w
git はもう少し機能を整理した方がいいと思う。
- 88 ：
- VCSに何を求めるか人それぞれなんだから意見が合うはずがない
ほっとけよ
- 89 ：
- gitはログ追うのも難儀するからな
- 90 ：
- NEATe68i
- 91 ：
- >>88
VCSにrebaseを求めない人がいるのが信じられないんだけど。
だって普通開発してたらケアレスミスするじゃん？
コミットした後で気づくってよくある話だと思うけど。
ケアレスミスじゃなくても単にバグとかさ。
- 92 ：
- そんなのは普通に直して普通にコミットすればよろしい。
rebeaseだのはVCS的には邪道。
うっかりだろうとケアレスミスだろうと、それすらも履歴として残すことに
本来的な意味がある。
- 93 ：
- わからないな。
ミスさえしなければ、本来できるはずがなかったコミットを
残す理由って何よ？
- 94 ：
- もちろん単なる履歴だ。それ以外に特別な意味はない。
すべてのコミットが単なる履歴なのだから、強いて言えば「こんな馬鹿な奴が
いました。次のプロジェクトからは外した方がいいですよ〜」という証拠でもある。
- 95 ：
- >>94
じゃあ、そのコミットに価値はないって認めるわけだね？
- 96 ：
- コミットの価値を理解しないとダメだよ。
コミットというのは、その一つを取り込んだり取り外したり
どこで問題が入ったかを調べたりするもの。
そういう風に利用できなければコミットにする理由がない。
それができるためには、1つのコミットが意味のある単位に
なっていなければいけない。
意味のある単位をむやみに分割したりとか
複数の単位をまとめてしまったら、コミットが使えなくなる。
- 97 ：
- rebase出来るということは潜在的に「履歴を間違えて消してしまう」リスクを背負う事になっちゃうからね。
ま、ローカルでのrebaseであれば作業者の責任範囲なのでウェルカムこの上ないんだけど。
人間だから、コードにバグ入れるのも当たり前、コミットミスするのも当たり前、同様にrebaseミスするのも当たり前だということ。
この中で一番ミスった時のリスクが高いのがrebaseなので、不要と考える人の気持ちもわかる。
- 98 ：
- rebaseでミスっても、簡単に元に戻せるから
問題ないのでは？
- 99 ：
- もちろんすぐに気付けばreflogとかでやり直せばいいと思うし、ローカルでやってくれる分には別に気にしないよ。
共有リポジトリに対してやられたりして、更に何らかのミスていることに気づかないで放置されると後々面倒だなーと。
人のコミットまでrebaseできちゃうわけだし。
- 100 ：
- 勿論欲しい事は欲しいんだけど、集中型のsvnには、「まだ」時期尚早な機能じゃね？
100〜のスレッドの続きを読む
MVVMについて語ろう
くだすれFORTRAN（超初心者用）その6
Microsoft Silverlight その9
多言語でforループを列挙していくスレ
Excel VBA 質問スレ Part53
DarkGDK Part.4
結局開発で最も大切なのはテーブルの正規化と制約
【統計分析】機械学習・データマイニング20
いまだにVC6から離れられない奴の数→
コメント研究すれ。
--------------------
国際結婚のズレ
ダイソーの下着を語るスレ
接地棒に生まれ変わりたい
【総合】FF6スレNo.167 〜必殺技、キー入力ミス！〜
【芸能】＜渡部の妻・佐々木希＞更新のインスタに心配の声！」「何があっても、秋田の人はみんな希ちゃんの味方だよ」 [Egg★]
日経先物２万割れ [805596214]
【薄荷】ミントについて語りませんか？Part15
【悲報】武豊さん1番人気を馬券外に飛ばしまくっていたｗｗｗｗｗｗｗｗｗｗｗ
西野七瀬「カンペ棒読みロボット」日テレ『歌唱王』のクソ司会に不快感「もう出るな」
Sony VAIO Fit Part7
知ってる？千葉市川署長杉田義弘◎長崎ストーカー２
【共同通信】北朝鮮、非武装地帯への軍進出警告 [6/16] [新種のホケモン★]
【悲報】左翼とリベラルになるような人にはもともと、脳に障害があると判明【やっぱり・・・】 part2
☆森高千里★統一スレ【69】
中京地区のアニメ事情 出張版 19
【上田慎一郎】カメラを止めるな！16テイク目
なまいきシャルロット
トップスポット Part11
死刑賛成派｢死刑が嫌なら悪い事するな｣→宅間守｢死刑になる為にやった｣加藤智大｢死刑になる為にやった｣小島一郎｢死刑になる為にやった｣ [659425117]
愛知県精神医療センター（旧・愛知県立城山病院）
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
