14/08/02 17:20:57.62 Pbzuc8Bb.net
Subversionはフリーなオープンソースのバージョン管理システムです。
公式HP
Apache Subversion
URLﾘﾝｸ(subversion.apache.org)
ようこそSubversion.JPコミュニティへ
URLﾘﾝｸ(www.subversion.jp)
2:デフォルトの名無しさん
14/08/02 17:21:57.75 Pbzuc8Bb.net
前スレ
r14 ｽﾚﾘﾝｸ(tech板)
r13 ｽﾚﾘﾝｸ(tech板)
r12 ｽﾚﾘﾝｸ(tech板)
r11 ｽﾚﾘﾝｸ(tech板)
r10 ｽﾚﾘﾝｸ(tech板)
r9 ｽﾚﾘﾝｸ(tech板)
r8 ｽﾚﾘﾝｸ(tech板)
r7 ｽﾚﾘﾝｸ(tech板)
06 ｽﾚﾘﾝｸ(tech板)
05 ｽﾚﾘﾝｸ(tech板)
04 ｽﾚﾘﾝｸ(tech板)
03 ｽﾚﾘﾝｸ(linux板)
02 ｽﾚﾘﾝｸ(linux板)
01 ｽﾚﾘﾝｸ(linux板)
3:デフォルトの名無しさん
14/08/02 17:22:45.55 Pbzuc8Bb.net
TortoiseSVN
URLﾘﾝｸ(tortoisesvn.net)
■文書
svnbook PDF版
URLﾘﾝｸ(psyto.s26.xrea.com)
CVSユーザのためのSubversionガイド(wakatonoさん)
URLﾘﾝｸ(slashdot.jp)
■Wiki
Subversionメモ
URLﾘﾝｸ(terai.xrea.jp)
■記事(ちょいと旧め)
URLﾘﾝｸ(www.atmarkit.co.jp)
URLﾘﾝｸ(www.atmarkit.co.jp)
URLﾘﾝｸ(ukai.jp)
URLﾘﾝｸ(ukai.jp)
4:デフォルトの名無しさん
14/08/02 17:23:32.96 Pbzuc8Bb.net
◆関連スレ
バージョン管理システムについて語るスレ10 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
CVS 1.3 [UNIX板]
ｽﾚﾘﾝｸ(unix板)
CVS導入スレ～ Rev.3 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
subversion バージョン管理【サブバージョン】 [Linux板]
ｽﾚﾘﾝｸ(linux板)
Git 10 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
【分散型バージョン管理】 Mercurial 2【hg】 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
【bzr】Bazaarでバージョン管理 Rev 4 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
5:デフォルトの名無しさん
14/08/02 17:26:54.04 Pbzuc8Bb.net
■記事(最近)
「Apache Subversion 1.7.17」リリース
2014年5月20日16:15 末岡洋子
URLﾘﾝｸ(sourceforge.jp)
＞ 1.9は第2四半期中にリリースを予定しており、
バージョン管理システム「Subversion 1.8」が登場、競合解決ツールや出力の改善など変更点多数
2013年6月19日15:15 末岡洋子
URLﾘﾝｸ(sourceforge.jp)
バージョン管理システム Subversion にバージョン1.8 登場
― なぜ Git ではなく、SVN を使うのか？
Sean Michael Kerner
2013年6月20日 / 19:30
URLﾘﾝｸ(internetcom.jp)
■Subversion の開発元
What's Next for Subversion?
URLﾘﾝｸ(www.youtube.com)
6:デフォルトの名無しさん
14/08/02 18:22:49.13 Mk2uM7ds.net
>>5
> ― なぜ Git ではなく、SVN を使うのか？
ローカルコミットをサポートしてクレー
7:デフォルトの名無しさん
14/08/02 18:40:46.96 DmU4GxTK.net
subvertionがgitになるなら
もうgitを使ったほうがいい気がするがｗ
8:デフォルトの名無しさん
14/08/02 19:36:38.97 B8TVS7ae.net
URLﾘﾝｸ(www.buzzword.jp)
9:デフォルトの名無しさん
14/08/02 20:12:35.61 0kTV0vzL.net
グロ
10:デフォルトの名無しさん
14/08/03 00:10:47.82 oEZJtdrX.net
subvertionから移行しやすいのは、gitでなくhg
11:デフォルトの名無しさん
14/08/03 00:15:01.01 g3w/WXUa.net
その前にsubvertionて何ですのん
12:デフォルトの名無しさん
14/08/03 00:53:58.50 LtVhC9Ww.net
アナル拡張器具
13:デフォルトの名無しさん
14/08/03 07:20:51.74 Lh4tYBtX.net
hage?
14:デフォルトの名無しさん
14/08/03 09:26:06.17 Qqzbedo3.net
スケーラビリティが向上するんだよ
15:デフォルトの名無しさん
14/08/03 12:30:11.92 tNPEJw6R.net
subversion は良くも悪くも普通のバージョン管理ツールだけど
git って、パッチ管理（リモート、ローカル）＆マージ処理に特化したのが勝因だよなー
Linusとしては自分に必要な、Linuxのパッチ適用に必要な機能だけ
あればよいって言う考えでgitを設計したんだろうけど。
16:デフォルトの名無しさん
14/08/03 12:43:18.82 vDYlVj70.net
subversionはソースコードを管理するツール
gitは機能単位でコミットを作るための開発ツール
17:デフォルトの名無しさん
14/08/03 13:24:33.93 hQ3yR5lB.net
フツーの業務システム開発ならsvnのtrunk一本でそれほど困らんけどね
複数人で同じソースをいじくりまわしてマージが大変なんてことは無いし
18:デフォルトの名無しさん
14/08/03 13:33:31.75 m8NxcudO.net
>>17
ぼっち開発者の俺はtrunkだけでほぼいける。
以前のバージョンに戻すこともめったにない。
ビルド出来ないとか、動作が不完全のような中途状態で取っておきたいときに
ブランチを作って、ＯＫになったらtrunkへマージする。
このブランチ側の作業を、ローカルリポジトリか何かで自動化できるとうれしい。
gitのリモート/ローカルってそういうものなんだろーなーと指を加えて見てる。
19:デフォルトの名無しさん
14/08/03 13:43:03.41 eFW9hWaw.net
大改造する時にはブランチきるだろ JK
20:デフォルトの名無しさん
14/08/03 13:47:16.84 EYCCS+tk.net
>>19
ぼっち開発ならそのまま trunk 上で開発もありだろ
どうしても途中で元のバージョンに修正入れたいなら、その時ブランチ切ればいいんだし
21:デフォルトの名無しさん
14/08/03 22:45:35.77 H3a6nHDk.net
git ⊃ SVN と思ったが違うのか
22:デフォルトの名無しさん
14/08/03 22:51:10.95 vDYlVj70.net
>>21
コミットの考え方が違うね。
svnは単なる作業履歴って感じだけど、
gitはコミットを一つ一つに意味があって
大事にしている。
23:デフォルトの名無しさん
14/08/04 00:09:08.40 Q4DpUAES.net
Git、Eclipse.orgでCVS、SVNを超える
作者： Alex Blewitt , 翻訳者 笹井 崇司 投稿日 2011年12月11日
URLﾘﾝｸ(www.infoq.com)
今から思えば、2010-2011に掛けて、Subversion からgitへ
ユーザーの移行が進んだな
Subversion 1.7以降は、日本語の記事も極端に減った感じがする
24:デフォルトの名無しさん
14/08/04 00:42:58.11 HYQsVMPc.net
gitは機能が多すぎ
25:デフォルトの名無しさん
14/08/04 13:57:04.00 c5xHxkCU.net
多いというか、整理されていないというか
かといって無いと不便というか
慣れるしかないというか
26:デフォルトの名無しさん
14/08/04 14:03:00.85 XttId4/U.net
新しく始めるときはgit使うようにしてるけど、慣れたらsvn使うの面倒くさく感じるようになってきた。
27:デフォルトの名無しさん
14/08/04 14:51:04.10 vzBGIwJJ.net
うん
そうだね
28:デフォルトの名無しさん
14/08/04 18:15:01.48 Ov9EQrbF.net
>>20
その運用するなら「元のバージョン」として扱うだろうと考えられるリビジョンでタグ打っときなよ
29:デフォルトの名無しさん
14/08/04 20:40:49.84 UAhHAw7M.net
>>25
> 整理されていないというか
ほんこれ
確かにあったらいいな～は、あるんだけど、なれるまでがちょい大変
>>28
ぼっち開発だとログもたいしたことないし...
まあ、リリース毎には外部バージョンでタグ打つけどね
30:デフォルトの名無しさん
14/08/04 22:35:33.41 eWAxusEw.net
URLﾘﾝｸ(www.buzzword.jp)
31:デフォルトの名無しさん
14/08/04 22:53:31.39 gDpcXLgO.net
guro
32:デフォルトの名無しさん
14/08/04 22:58:50.77 O7gnQe0p.net
一人でやってると、コミットの扱いが雑にならね？
何か修正している時に、つい近くの
コードが気になって関係ないのに修正しちゃう。
で、コミットメッセージに○○の修正って書いてるのに、
無関係の修正が含まれてたり。
33:デフォルトの名無しさん
14/08/05 02:53:09.46 JklbpSFc.net
あるある～
34:デフォルトの名無しさん
14/08/05 03:20:24.50 YIevQOQe.net
狭く深くか、広く浅くかで分けて
広く浅い方は「後で絶対に戻さない」という信念を持ってコミットする
35:デフォルトの名無しさん
14/08/06 23:28:00.45 Rv/16L6Z.net
> 広く浅い方は「後で絶対に戻さない」という信念を持ってコミットする
一つ一つに信念を持たないと
コミットできないなら疲れるってｗ
人間である以上、漏れっていうのは絶対にある。
こんな些細な事はあとから修正すればいい話でgitならそれができる。
36:デフォルトの名無しさん
14/08/07 19:51:06.05 2eVL32He.net
単に数日前に戻りたいだけとか、コミットにいちいち信念なんてうぜーとかなら、
別にわざわざscm使う必要なくね?
そういうやつはどうせコミットメッセージなんてロクにつけないんだろ?
このスレでいうのもなんだが、そういう使い方しかしないんなら、
nilfs2などのログファイルシステム使っとけば十分な気がするが。
webdavなクラウドストレージでもいいし。
無理してscm使う必要ないと思うけど。
37:デフォルトの名無しさん
14/08/07 21:58:12.49 KOv3T7TP.net
コミットの内容に気を使うか、
単なるバックアップとして使うかの
違いだよね。
バックアップとしてしか使ってない人は
ソースコードを管理しているわけじゃないというだけのこと。
38:デフォルトの名無しさん
14/08/08 01:55:37.68 h6ijPVt8.net
SVKって、なんで廃れたの？
39:デフォルトの名無しさん
14/08/08 02:38:38.23 pWDxpd5M.net
差分確認したいから使うわけだが
40:デフォルトの名無しさん
14/08/08 02:54:36.69 9Z/dDvz0.net
その差分が、一日とかの時間単位の差分なのか
コミット＝機能 単位の差分なのかで意味が違ってくるけどな。
しっかりコミットには機能を含ませないとダメだよ。
○機能のコミット、間を空けて、○機能のバグ修正とか
機能が複数のコミットに分断されたりすると、差分調べづらいからさ。
41:デフォルトの名無しさん
14/08/08 10:14:49.47 U3aQnjb8.net
>>40
一機能が数十ファイルに渡る数千行の変更になることが普通だから、機能毎のcommitは粒度が大きすぎる。
42:デフォルトの名無しさん
14/08/08 23:37:02.98 7OE7NDSB.net
粒度が小さくしようと思えば、
コミットの回数は必然的に多くなると思うけど、
そうすると大変にならね？
ちょっとしたミスでもしないように
心がけないといけないから、テストに時間が掛かる。
43:デフォルトの名無しさん
14/08/09 15:03:48.49 tAcYV70i.net
>>42
昔、１つの障害直すのに機能修正用に一回コミットして、
その後ソースのインデント変更でもう一回コミットとかした事がある。
確かに細かくコミットした方が後で見るときに分かりやすいというのはある。
44:デフォルトの名無しさん
14/08/10 09:00:39.40 aTEKyeJh.net
URLﾘﾝｸ(www.buzzword.jp)
45:デフォルトの名無しさん
14/08/10 18:07:16.07 on/xxl87.net
>>40
ブランチ作ればいいんでないのと思うんだけど、それではだめなのかな。
>>42
粒度を小さくするってことは、固まったところからコミットしていくということなので
特にテストの手間は増えないよ。
>>43
気持ちは分かるんだけど、インデントに関してのみいえばdiffのオプションで
インデント変更を無視することができるので、分けなくても大丈夫。
むしろ、特定リビジョンにおいてインデントが崩れている状態を生み出したというのは
個人的にはあまりよろしくないと思う。
46:デフォルトの名無しさん
14/08/12 07:18:30.56 iJ1eXffk.net
1.8.10が出たのか
そろそろgitに移行するかなー
47:デフォルトの名無しさん
14/08/12 18:02:50.52 v1nubPFA.net
>>45
> 粒度を小さくするってことは、固まったところからコミットしていくということなので
> 特にテストの手間は増えないよ。
固まった所からコミットするってどうやるの？
ファイルの一部分だけコミットとか出来ないよね？
48:デフォルトの名無しさん
14/08/12 18:08:45.21 v1nubPFA.net
あと固まった所からコミットというのは
作業が直列化してるんだよね。
ある機能を作ろうと思ったら、
・サブ処理A
・サブ処理B
・サブ処理C
みたいな感じで機能を作っていくでしょ？
その時サブ処理Aができたーと思って
B、Cを作っていくけど、その間に見逃しがあったり
問題が見つかって再設計が必要になる。
そういうときサブ処理Aのコミットを
修正できないのはキツイよね。
49:デフォルトの名無しさん
14/08/12 18:22:27.64 DPsvz0Xi.net
>>48
> そういうときサブ処理Aのコミットを
> 修正できないのはキツイよね。
言ってる意味がわからないんだが・・・。
BあるいはCをきりのいいところでcommitして、Aを修正すればいいのでは・・・。
50:デフォルトの名無しさん
14/08/12 18:48:27.03 v1nubPFA.net
>>49
そうすると、Aのコミットと
Aの修正のコミットの二つが出来るでしょ？
51:デフォルトの名無しさん
14/08/12 22:05:50.34 EY85siFi.net
うん。
そういうものを管理するためのツールだもの。
52:デフォルトの名無しさん
14/08/12 22:20:13.12 v1nubPFA.net
>>51
意味を考えたことある？
Aのコミット＋Aの修正であれば、その二つを
まとめたコミットが一つだけあれば十分。
もちろんリリースした後なら別に分けたほうがいいけど、
一時間前に書いたコードのケアレスミスとか残す価値はない。
残しておけば、過去のコードを見る必要がある時
（見る必要があるから残すわけで）余計な手間がかかる。
コミットの内容を小さくすればするほど、無駄なコミットはなくそうと
考えるのが普通では無いかな？
53:デフォルトの名無しさん
14/08/12 22:42:52.85 9cOXUK+K.net
>>52
確かにバグ修正のコミットは結果的に言えば無駄だね。
じゃあ、いつコミットできるの？
バグが一切存在しないコードを書けるクヌース先生みたいな人なのかな。
54:デフォルトの名無しさん
14/08/12 22:49:43.95 lQ8v3e0D.net
>>52
詭弁だね。
gitでもローカルではこまめにコミットするよ。
gitでは、みんな整えてからサーバーにプッシュしてくれるから、機能単位になるけどね。
SVNでそれは出来ないし、現状そういう使い方には向かない。
>>53
最も過ぎて感動した。
55:デフォルトの名無しさん
14/08/12 23:31:31.61 v1nubPFA.net
>>53
ゼロにしろって話じゃない。
少なくしろって話。
56:デフォルトの名無しさん
14/08/12 23:50:23.60 9cOXUK+K.net
>>55
そうだね。むやみに細かなコミットはするべきじゃないよ。
それと、固まったところを切り出してコミットをするのをやめろって話とは矛盾しない。
開発の概念的なステップにおいて不可分なものについて、一部を切り出してコミットするという話ではないし、
逆に>>48でいうところの3つのサブ処理が互いに疎ではないのであれば、Aのみをコミットするのはどうかと思う。
分けるべきことと分けてはいけないことを把握できてるなら、たぶん考えてることは同じだと思う。
57:デフォルトの名無しさん
14/08/12 23:51:26.61 9cOXUK+K.net
s/をするのをやめろ/したほうがいい/
58:デフォルトの名無しさん
14/08/12 23:52:57.40 +KZZ7y/Q.net
なんかこう、>52は根本的なところでVCSを理解できていないか
それとも何かの教条主義に陥っているのか。
いずれにしても、tagやコミットログを使いこなせていないのだろう。
59:デフォルトの名無しさん
14/08/13 00:05:50.29 sMkXwa1N.net
経験則でいうと、手当たり次第に手をつけながら改修を行うような人にはVCSは向かないと思う。
それはひとえにコミット単位が大きくなりすぎるからという理由。
この手の人は大抵コンフリクトに頭を抱え、VCSに対して文句を言う羽目になってる。
時がたち、コミット単位をうまくまとめられるようになったころには、
手当たり次第に改修するというスタイルは矯正されてると思う。
60:デフォルトの名無しさん
14/08/13 00:07:16.21 NDCsqVwr.net
そもそもツールに問題があるとは考えないのか？
gitではできるが
subversionではできないんだよ。
61:デフォルトの名無しさん
14/08/13 00:09:19.27 NDCsqVwr.net
>>59
> 経験則でいうと、手当たり次第に手をつけながら改修を行うような人にはVCSは向かないと思う。
それは違うな。
>>53が言っているように、
> じゃあ、いつコミットできるの？
> バグが一切存在しないコードを書けるクヌース先生みたいな人なのかな。
バグが一切存在しないことはない。
だから手当たり次第にコミットすしたのと同じことになる。
だからこそgitではそれを後から修正できるようにした。
subversionというツールに問題があるんですよ。
62:53=59
14/08/13 00:11:57.89 sMkXwa1N.net
だめだこりゃ。
63:デフォルトの名無しさん
14/08/13 00:13:50.98 BorG/OEI.net
個人的には、意味のある単位であれば、コミットは細い程良いと思ってる。
その、程々の粒度のコミット単位を見つけられるかが経験なのかもしれないけどね。
俺も経験上の話をすると、でかいコミットをカマス奴は信用できないヤツが多い。
しかも、不具合やリファクタリングを指摘しても、何だかんだで直してくれない。
(その理由の一つが、履歴が汚れるからとか、おかしいだろ…)
64:デフォルトの名無しさん
14/08/13 03:17:33.31 u7WpCg+2.net
とりあえずgit-svn使っとけばいいんじゃね
65:デフォルトの名無しさん
14/08/13 08:16:22.09 O9MT/Amg.net
>>63
あるある
所詮開発ツールのログにすぎないのに、そのログの保守が目的になっちゃう人
極端に偏るのはウザいし、業務遂行の妨げだよね～
程々でいいんだよ、何事もバランスが大切
66:デフォルトの名無しさん
14/08/13 08:26:41.64 DJCgQYDb.net
>>48
A, B, C 用にブランチ切って各々単体テストまで完了してからコミットすれば？
67:デフォルトの名無しさん
14/08/13 10:50:51.37 jXoiUBxz.net
>>56
> 逆に>>48でいうところの3つのサブ処理が互いに疎ではないのであれば、Aのみをコミットするのはどうかと思う。
つか、互いに疎になるように分割しないと駄目なのでは？
68:デフォルトの名無しさん
14/08/13 11:13:14.94 prMs9a0D.net
ま、手段と目的が逆転している感はあるな
69:デフォルトの名無しさん
14/08/13 11:45:42.27 jXoiUBxz.net
まあ、「ある機能」の規模感が人によってさまざまで、だから意見が食い違ってる気がする。
俺の場合は、「機能」で分割した場合、コードの行数は500～3000行くらいで、500行の場合でも
クラスを3つ、メソッドそれぞれ10～30行とかで、メソッド一つ～数個ごとにコミットする感じ。
70:デフォルトの名無しさん
14/08/14 01:01:10.16 pDOsDmj5.net
1.9 って、ＤＢ機能の強化がメインなのか？
バックグランドの機能強化とか誰得なんだ？
71:デフォルトの名無しさん
14/08/14 02:24:10.10 HJ0p3ltx.net
URLﾘﾝｸ(svn.apache.org)
72:デフォルトの名無しさん
14/08/14 08:47:18.57 UKa3zRV/.net
>>71
これ、なんだ？
Developer-visible changes: - General:
* support generating VS 2013 and later project files.
73:デフォルトの名無しさん
14/08/14 11:27:09.25 vzBa7P/6.net
大規模CI環境になるとsvnが性能ネックになりうるので
バックエンドの強化は地味ながら効果的
74:デフォルトの名無しさん
14/08/15 18:15:50.03 NhRsvWgL.net
データベースを強化しないと機能追加が難しい。急がば回れ。
OSS関係はgitが主流になったんで開発を急ぐ必要も無いから
75:デフォルトの名無しさん
14/08/16 15:29:40.52 HLPR753i.net
URLﾘﾝｸ(www.buzzword.jp)
76:デフォルトの名無しさん
14/08/16 15:33:06.06 HaTedOVs.net
ぐろ
77:デフォルトの名無しさん
14/08/18 20:45:04.19 S1QfPa+c.net
Git 対 Subversion：長引く争い
URLﾘﾝｸ(readwrite.jp)
78:デフォルトの名無しさん
14/08/18 21:10:12.16 qllk6aou.net
>>77
subversionに
79:もメリットがあって、 gitとsubversionのどちらがいいか戦ってるって 話かと思ったら、 Subversionの呪縛から抜だしてGitへ移行する戦い・・・が長引いてるって って話でワロタｗ タイトルの訳間違ってるだろｗｗｗ
80:デフォルトの名無しさん
14/08/18 21:38:25.14 XfPgTp0v.net
みんなそんなにSVNに困ってるの？
81:デフォルトの名無しさん
14/08/18 21:44:14.15 RwGMDQAu.net
gitに移行した方がいいプロジェクトも確かにあるけど、
プログラマー以外の職種が多い場合や、
巨大なデータを扱うのがメインだと難しいね
82:デフォルトの名無しさん
14/08/18 23:28:18.45 5QD9Cwn1.net
>>77
すでにコメントで指摘されてるけど、下二つのグラフが同じだな
おぼちゃんじゃないけど、こういうミスがある記事はあまり信頼できない
83:デフォルトの名無しさん
14/08/18 23:59:55.48 KXo4EPQU.net
適材適所という言葉が奴らの辞書には載ってないんだよ
84:デフォルトの名無しさん
14/08/19 01:07:57.99 hZ1y1Bcl.net
適材適所？ 中央リポジトリには
subversionが適してると思ってる？
残念。中央リポジトリにしか使えないんだよ。
rebaseできないからな。
85:デフォルトの名無しさん
14/08/19 01:10:04.56 hZ1y1Bcl.net
>>79
うん。困りまくり。
小さくコミットが出来ない。
コミットした後で並び替えできない。
ブランチ切り替えに時間かかる。
そもそも、ブランチ切るのが大変
Subversionじゃ気軽に何十個もブランチ切れない。
こんなの使えないよ。
86:デフォルトの名無しさん
14/08/19 01:15:51.90 c3qx/Qrl.net
自分中心でしか語れないクズは去っていいよ
87:デフォルトの名無しさん
14/08/19 01:57:10.27 hZ1y1Bcl.net
他人のことを考えたとしても、
できることは多いほうがいいよ？
88:デフォルトの名無しさん
14/08/19 11:28:17.07 tg7i16ue.net
>>86
> できることは多いほうがいいよ？
多機能家電に憧れちゃう人？ w
git はもう少し機能を整理した方がいいと思う。
89:デフォルトの名無しさん
14/08/19 11:41:44.97 VxtC/3Yq.net
VCSに何を求めるか人それぞれなんだから意見が合うはずがない
ほっとけよ
90:デフォルトの名無しさん
14/08/19 20:56:55.78 NEeA6T8i.net
gitはログ追うのも難儀するからな
91:デフォルトの名無しさん
14/08/19 20:57:40.71 NEeA6T8i.net
NEATe68i
92:デフォルトの名無しさん
14/08/19 21:34:51.65 wZ/va0+J.net
>>88
VCSにrebaseを求めない人がいるのが信じられないんだけど。
だって普通開発してたらケアレスミスするじゃん？
コミットした後で気づくってよくある話だと思うけど。
ケアレスミスじゃなくても単にバグとかさ。
93:デフォルトの名無しさん
14/08/19 21:46:10.76 mxmpwOEU.net
そんなのは普通に直して普通にコミットすればよろしい。
rebeaseだのはVCS的には邪道。
うっかりだろうとケアレスミスだろうと、それすらも履歴として残すことに
本来的な意味がある。
94:デフォルトの名無しさん
14/08/19 21:59:43.08 wZ/va0+J.net
わからないな。
ミスさえしなければ、本来できるはずがなかったコミットを
残す理由って何よ？
95:デフォルトの名無しさん
14/08/19 22:08:41.41 mxmpwOEU.net
もちろん単なる履歴だ。それ以外に特別な意味はない。
すべてのコミットが単なる履歴なのだから、強いて言えば「こんな馬鹿な奴が
いました。次のプロジェクトからは外した方がいいですよ～」という証拠でもある。
96:デフォルトの名無しさん
14/08/19 22:10:09.40 wZ/va0+J.net
>>94
じゃあ、そのコミットに価値はないって認めるわけだね？
97:デフォルトの名無しさん
14/08/19 22:15:43.48 wZ/va0+J.net
コミットの価値を理解しないとダメだよ。
コミットというのは、その一つを取り込んだり取り外したり
どこで問題が入ったかを調べたりするもの。
そういう風に利用できなければコミットにする理由がない。
それができるためには、1つのコミットが意味のある単位に
なっていなければいけない。
意味のある単位をむやみに分割したりとか
複数の単位をまとめてしまったら、コミットが使えなくなる。
98:デフォルトの名無しさん
14/08/19 22:17:29.06 hIkjmM2M.net
rebase出来るということは潜在的に「履歴を間違えて消してしまう」リスクを背負う事になっちゃうからね。
ま、ローカルでのrebaseであれば作業者の責任範囲なのでウェルカムこの上ないんだけど。
人間だから、コードにバグ入れるのも当たり前、コミットミスするのも当たり前、同様にrebaseミスするのも当たり前だということ。
この中で一番ミスった時のリスクが高いのがrebaseなので、不要と考える人の気持ちもわかる。
99:デフォルトの名無しさん
14/08/19 22:18:32.84 wZ/va0+J.net
rebaseでミスっても、簡単に元に戻せるから
問題ないのでは？
100:デフォルトの名無しさん
14/08/19 22:35:26.02 hIkjmM2M.net
もちろんすぐに気付けばreflogとかでやり直せばいいと思うし、ローカルでやってくれる分には別に気にしないよ。
共有リポジトリに対してやられたりして、更に何らかのミスていることに気づかないで放置されると後々面倒だなーと。
人のコミットまでrebaseできちゃうわけだし。
101:デフォルトの名無しさん
14/08/19 22:38:27.65 hIkjmM2M.net
勿論欲しい事は欲しいんだけど、集中型のsvnには、「まだ」時期尚早な機能じゃね？
102:デフォルトの名無しさん
14/08/19 22:40:19.87 mxmpwOEU.net
やっとわかった。自分勝手な基準で「意味のあるコミット」だとか
「意味のないコミット」だとか、そういうものが存在するという幻想を
抱いてるレベルなのか…
できればVCSを使わないで欲しいな、そんな奴には…
逆なんだよ、「コミットする事に意味がある」んだって分かって欲しいね。
103:デフォルトの名無しさん
14/08/19 22:43:40.49 wZ/va0+J.net
>>99
> 人のコミットまでrebaseできちゃうわけだし。
人のコミットって言っても、それローカルじゃないでしょ？
”人のコミット”といえば、ローカルの話だと思うんだけど？
ローカル（つまり自分のhome以下）にあるものは普通
ディレクトリ共有しないのだからそれは勝手にrebaseできないよな。
で、サーバーにあるものは勝手にrebaseされたとしても気づく。
（ローカルと食い違ってるのでちゃんと知らせてくれる）
そもそもローカルにある自分のコミットがオリジナルで
そっちは無事なので何の問題もないけど。
104:デフォルトの名無しさん
14/08/19 22:44:18.54 wZ/va0+J.net
>>101
おいｗ せめて何か言い返せよｗ
105:デフォルトの名無しさん
14/08/19 22:45:12.28 wZ/va0+J.net
目的と手段が入れ替わってるんだろうな。
コミットすることが目的になっちゃってる。
コミットを使わないと
何の意味もないのに。
106:デフォルトの名無しさん
14/08/19 22:48:07.47 hIkjmM2M.net
>>101
直線履歴が基本のsvnだと確かに全ての作業ログを残して欲しくなるね。
でも、ブランチと機能コミットが基本の分散型だと、すごーく履歴がカオスになるので、rebaseで直線化して欲しくなる気持ちもわかるよ。
107:デフォルトの名無しさん
14/08/19 22:50:06.96 wZ/va0+J.net
あぁ、作業ログ。そうかsubversionは
単なる作業ログなんだ。
コミットを使うという発想がないんだね。
オープンソースの開発なんかだと
コミットを送ったりするわけだけど、
そうか単なる作業ログか。
108:デフォルトの名無しさん
14/08/19 22:50:38.55 hIkjmM2M.net
>>102
話変わるけど、svn使ったことある?
109:デフォルトの名無しさん
14/08/19 22:54:40.94 hIkjmM2M.net
>>106
アオリたいだけなら、俺はもう引っ込むね。
そんなやり合いには何の実もないから。
適材適所なんだから、そういう突っかかり方するのもどうかと思うよ。
110:デフォルトの名無しさん
14/08/19 22:54:49.52 wZ/va0+J.net
>>107
あるけどそれが？
svn使っている時から苦痛だったよ。
コードレビューしやすいように
したかったのだが無理だった。
git使ってから、ツールが悪かったんだなって
わかった。
111:デフォルトの名無しさん
14/08/19 22:56:33.30 wZ/va0+J.net
>>108
だって作業ログなんでしょ？
コミットする事に意味があるだっけ？
コミットすることが目的だみたいなこと言ってるし。
言いたいことがあるのなら言い返せばいいのに
それもできないでいるしさ。
112:デフォルトの名無しさん
14/08/19 22:58:42.34 wZ/va0+J.net
社内の仕事だったら、適当な作業ログでいいかもしれないけどさ、
これが赤の他人に提出するパッチだったら
コードはちゃんとレビューできるようになってないとダメだよ。
赤の他人のコードなんて信用出来ない。
コミットがきちんと理解できるように
意味のある単位に分かれていなければ、
受け取ってもらえない。
113:デフォルトの名無しさん
14/08/19 23:07:57.10 hIkjmM2M.net
>>111
何だ、適材適所という事をわかってるじゃないか。
それなのに何でそこまで君の正義を主張したがる？
君の言うことは正しい。
でもそれが全てじゃない。
114:デフォルトの名無しさん
14/08/19 23:34:01.17 X6oZU2h0.net
>>101
変な状態でコミットされてもなー
115:デフォルトの名無しさん
14/08/20 00:00:03.80 f3yS32aL.net
バカには無理
116:デフォルトの名無しさん
14/08/20 00:53:26.19 a44PmGri.net
>>77
>>81
読んだ感じでは、俺が感じていたのと殆ど同じなので、違和感が無い。
2010年頃から、雪崩のようにsvnからgitへ人が移動していったと感じていたけど
記事を見て、自分の思っていた通りだったと確信した。
SVNに関する需要が0になる事は無いと思うからどこかで、下げ止まると思うけど
117:デフォルトの名無しさん
14/08/20 02:20:29.54 tVPQaqWC.net
svnを使う理由は「今更やめられない」か
「新しいものを覚えたくない」だけになりそうだね。
118:デフォルトの名無しさん
14/08/20 02:23:43.02 tVPQaqWC.net
機能で言えばgit > svnなんだよな
gitはsvnの代わりに使えるが、
svnはgitの代わりにはならない。
119:デフォルトの名無しさん
14/08/20 03:17:17.30 f3yS32aL.net
svnは一部のcoできるけどgitは・・
120:デフォルトの名無しさん
14/08/20 03:34:47.62 ZA48Lhll.net
svnはコミット単体でが何というブランチになされたものかわかるけど、gitは…
121:デフォルトの名無しさん
14/08/20 04:37:57.36 tVPQaqWC.net
>>118-119
でもそれって、できても役に立たないですよね？
122:デフォルトの名無しさん
14/08/20 07:44:27.64 VDbLT/q5.net
一部coは明らかに有用。
123:デフォルトの名無しさん
14/08/20 08:18:04.87 f3yS32aL.net
巨大プロジェクト全体のcloneなんて無駄なことしたくないからね
124:デフォルトの名無しさん
14/08/20 08:28:54.10 ywmZeMUB.net
gitがoss向きなのは明らかだね。
自然集約と自然淘汰を本質とするossの性質に良くマッチしている。
一方、統制を基本とする企業という枠組みの中では必ずしもマッチするものではないと思う。
ただ、企業と言ってもこれまた多種多様で、ソフトウェア実装専門であればgitが適していると思う。
gitは良くも悪くもテキストに特化したツールだから、他の文書や成果物を合わせて管理するには向いていない。
125:デフォルトの名無しさん
14/08/20 08:30:54.38 Dj5PYAlQ.net
ソースコードだけ対象で、計画的な開発体制が出来てるならgitの方がいいと思う
そうでない場合、subversionがいい場合もある
126:デフォルトの名無しさん
14/08/21 02:22:10.31 W/oig19k.net
>>122
巨大プロジェクトってたとえばどんなの？
もしかして無関係のものまで
一つのリポジトリに入れちゃったりしない？
だめだよ。プロジェクトごとに
リポジトリは分けなきゃ。
127:デフォルトの名無しさん
14/08/21 02:27:08.87 Yce5CEFd.net
大手自動車メーカの走行テレメトリーデータ
128:デフォルトの名無しさん
14/08/21 02:39:29.35 W/oig19k.net
ん？ またソースコードを管理するから
ソースコード管理ツールに
データ入れてるって話？
129:デフォルトの名無しさん
14/08/21 03:55:04.90 PN+RgdpI.net
ソースコード管理ツールﾜﾛﾀ
130:デフォルトの名無しさん
14/08/21 04:52:59.29 /QX5bJTQ.net
>>125
> だめだよ。プロジェクトごとに
> リポジトリは分けなきゃ。
なぜ？
131:デフォルトの名無しさん
14/08/21 09:40:57.19 rUYfHbxl.net
伸びてると思ったら案の定こんな話か
132:デフォルトの名無しさん
14/08/21 10:18:28.92 7zFpfveR.net
>>125のように頭の悪い奴が支持してるのがgit
133:デフォルトの名無しさん
14/08/21 10:50:44.47 Ob17d+jm.net
>>129
dump, restoreが重すぎる。リポジトリが大きくなるともうだめぽ。
134:デフォルトの名無しさん
14/08/21 12:39:31.40 npCrOf/M.net
だがヘボが管理するとプロジェクトごとのバージョン合わせに無駄な手間が
135:デフォルトの名無しさん
14/08/21 21:33:19.38 aOXOtjT0.net
「プロジェクト」の定義は？
136:デフォルトの名無しさん
14/08/21 22:13:47.40 xeZNqCr5.net
おれも問題はそこだと思う。
実行ファイルにコンパイルされるソース一式と仮定すると、
たとえばひとつの実行ファイルだけで完結してしまって、
他の実行ファイルとの関係など全くないような
小さなモノしか扱ったことのないやつにとっては、きっと
(実行ファイル) = (プロジェクト) = (リポジトリ)
という頭しかないんだろ。
137:デフォルトの名無しさん
14/08/21 22:37:19.35 W/oig19k.net
>>134
> 「プロジェクト」の定義は？
プロジェクトっていうか
プロダクトかな。
プログラマなら疎結合にする重要性は知っていると思うが、
プロジェクト定義は別々にリリースしても問題ない単位でいいんじゃないかな
または別々のバージョン番号をつけている単位でもいいかも
ようするに商品として独立していること。
138:デフォルトの名無しさん
14/08/21 22:40:07.04 W/oig19k.net
>>135
プロジェクトには複数の実行ファイルがあるわけだけど、、
当たり前だけど、それでも全部を一つのリポジトリに入れたらダメだよね。
無関係のものもあるわけだし。
プロジェクトごとにリポジトリを分ける。
一つのプロジェクト（リポジトリ）には複数の実行ファイルが入ってる。
これが理想だろうね。
139:デフォルトの名無しさん
14/08/21 22:43:54.55 Ob17d+jm.net
使いやすいように使えばいい、理想なんかねーよ。ハゲ。
140:デフォルトの名無しさん
14/08/21 22:47:31.02 W/oig19k.net
全部一つにまとめると。一部だけ移動したりする時とかに
使いにくくなるんだよな。
特定のプロジェクトにはアクセス制限かけるとかさ。
（使いにくいから）一つのプロジェクトに
まとめるなという話をしてる。
141:デフォルトの名無しさん
14/08/21 23:19:36.49 Ob17d+jm.net
>>139
使いにくくなるのは、おめーが使い方知らないだけ。
142:デフォルトの名無しさん
14/08/21 23:34:08.49 xeZNqCr5.net
>>137
関連する実行ファイルのソースはすべてひとつのリポジトリに揃ってないと、
各実行ファイル間の関係を追跡できなくなってしまう。
プロジェクトが「プロダクト(製品)」の意味ととらえても、
おれのところではひとつの製品の中に無関係のものなんてないし、
ひとつのソース一式が複数の製品で利用されてたりもするから、
それらが全部同じリポジトリにないと管理ができなくなる。
また、ひとつの製品は過去のバージョンとの連続性もあるが、
過去の経緯によってもモジュール間の依存関係は変わってくる。
無関係のものをその時点の状況だけで別のリポジトリに分けてたら収集がつかない。
パッケージ商品の開発では、ひとつの部署で開発した成果物はひとつのリポジトリに納めてる。
特定の顧客から発注された開発では専用のリポジトリを作ることもあるけど、
パッケージ商品の一部成果物を利用して工数を削減したりするので、
パッケージと同じリポジトリにブランチを切ってそこに突っ込むことが多い。
でないと、パッケージ商品に含まれてる標準のものと
特定顧客向けに一部修正したものとの履歴の違いがわからなくなる。
結局、おれのところでは基本的にライセンスや使用許諾条件によってリポジトリを分けてるかな。
異なるライセンスのソースが同じリポジトリにあっちゃマズイから。
143:デフォルトの名無しさん
14/08/21 23:59:09.62 W/oig19k.net
関連する実行ファイルのソースはすべてひとつのリポジトリに揃ってないと、
各実行ファイル間の関係を追跡できなくなってしまう。
逆に言えば、関連しなければ何の問題もない。
これ以上の話はする必要がないとおもう
144:デフォルトの名無しさん
14/08/22 09:02:34.71 vd34DDnl.net
急に禅問答になった。
145:デフォルトの名無しさん
14/08/22 13:37:43.59 p2QF+4Sq.net
リポジトリは分けた上で、リビジョン指定のsvn:externalsで関連付けたらいいのでは
146:デフォルトの名無しさん
14/08/22 14:14:15.25 mvEiVivf.net
やり方は沢山あって、それなりに一長一短ある。
> オレ様のやり方が一番良い。オレ様のやり方でやるべき。
と言い出すバカは死んでくれ。
147:デフォルトの名無しさん
14/08/22 19:01:58.40 x+8C73Wg.net
まあこの辺りを読ん�
148:ﾇけって言う話だわな http://svnbook.red-bean.com/en/1.7/svn.reposadmin.planning.html
149:デフォルトの名無しさん
14/08/23 00:06:04.33 tn55FLZ4.net
雑多なファイル、資料を扱うときに部分チェックアウトは凄く便利だよな
150:デフォルトの名無しさん
14/08/23 00:43:59.83 UlvkZmqF.net
>>142
むやみにひとつのリポジトリで運用すべきではないという主張になってると思うんだけど、
当初はdump restoreが重過ぎるからひとつにするなといっていたよね。
言葉を変えると、
むやみにリポジトリを分けてしまうと追跡できないものが生まれうるというところに異論は無いと思うんだけど、
dump restoreが重いという理由以外にひとつにまとめるべきではないという理由は何かあるの？
ちなみにdump restoreの重さが気になる頻度でそれを行っているのなら、そこを改めるべきだと思う。
151:デフォルトの名無しさん
14/08/23 00:48:28.44 j4ngjv2t.net
開発元がひとつにまとめてる時点でないだろ
152:デフォルトの名無しさん
14/08/23 06:47:22.27 akTuwZSl.net
>>148
当初はじゃなくて独立した理由だろ。アホウ。
153:デフォルトの名無しさん
14/08/23 13:22:14.44 ONwlfWFe.net
パッケージ管理とバージョン管理の区別が付いてないと
悲惨なリポジトリになる
154:デフォルトの名無しさん
14/08/23 16:08:22.28 VUWj8PF8.net
>>151
どう分ければ良いの？
155:デフォルトの名無しさん
14/08/23 17:10:06.41 UlvkZmqF.net
>>150
独立したそれぞれの理由を書いてるけど、どれもこれも分けないことによって生まれるデメリットに相当しないんだもの。
156:デフォルトの名無しさん
14/08/23 19:13:33.30 kSrKTw7a.net
ソースコードのバージョン管理とプロダクトの構成管理は別物だしなぁ
157:デフォルトの名無しさん
14/08/23 19:25:44.67 akTuwZSl.net
分けることで得られるメリットも同じ位薄弱だ
158:デフォルトの名無しさん
14/08/24 00:45:17.64 cxV5Zamh.net
この流れは何度も繰り返されているけれど、そのたびに分けなくていいという結論になってない？
159:デフォルトの名無しさん
14/08/24 11:38:05.22 tjUQeC3v.net
>>5
>バージョン管理システム Subversion にバージョン1.8 登場
>― なぜ Git ではなく、SVN を使うのか？
>Sean Michael Kerner
>2013年6月20日 / 19:30
>URLﾘﾝｸ(internetcom.jp)
訳がおかしいから原文読んだけど、
URLﾘﾝｸ(www.developer.com)
1.9 を9か月のサイクルで出したいとか言ってたけど、無理みたいだな。
160:デフォルトの名無しさん
14/08/24 12:46:27.42 04V5n05d.net
これぐらいの速度で出して欲しい
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リリース
161:デフォルトの名無しさん
14/08/24 16:01:04.94 tjUQeC3v.net
gitの開発速度には敵わないでしょ
162:デフォルトの名無しさん
14/08/24 16:17:32.62 1q09/hom.net
subversionにgit flowとかgithub flowみたいなのってある？
subversionを使ってどういうふうに運用するかを
決めた開発のフロー
163:デフォルトの名無しさん
14/08/24 16:22:50.54 1q09/hom.net
あとどういう時にブランチ切ってる？
バグ修正用のブランチとか切っていい？
そうするとたとえばバグが100個あったら
100個ぐらいブランチ出来るんだけど
名前つける時どうしてる？
誰が作ったブランチかわからないから
頭に個人名のプレフィックスつけようかと思うんだけど
変なやり方じゃない？
要らなくなったブランチは削除していいよね？
ブランチは削除できるみたいだし。
164:デフォルトの名無しさん
14/08/24 17:05:10.65 cxV5Zamh.net
大抵のバグはブランチを作るほどじゃないなぁ。影響範囲も小さく、内容が明白であれば1コミットで済むでしょ。
オレオレブランチは大抵イマイチな命名だけど状況次第。
砂場として使うならアリ。バグフィックスのために個人名をつけるのは全力でナシ。
要らなくなったブランチはどんどん削除。
165:デフォルトの名無しさん
14/08/24 18:53:31.85 1q09/hom.net
> 大抵のバグはブランチを作るほどじゃないなぁ。影響範囲も小さく、内容が明白であれば1コミットで済むでしょ。
一人でやっていればいいけど、複数人でやってると
そうも行かないよね？
並列で複数の作業が発生するわけだしコードレビューも必要。
166:デフォルトの名無しさん
14/08/24 19:49:07.75 9zqGicGe.net
>>163
> 一人でやっていればいいけど、複数人でやってると
> そうも行かないよね？
修正範囲が多岐に渡るでかい修正ならそうだけど、大抵の修正は一人でやってる範囲に収まるよ
でかい修正の時は修正方針決めた段階で関係者集めてレビューするから
167:デフォルトの名無しさん
14/08/24 23:27:54.67 1q09/hom.net
いや、書いたコードをレビューしないと、
修正方針通りでも、コードがダメな場合があるじゃないか
コピペされていたり、正しくない構造を指定たり。
168:デフォルトの名無しさん
14/08/24 23:29:50.41 1q09/hom.net
それに複数人でやるっていうのは、修正する人が一人かどうかじゃなくて、
平行して、別々の開発があるじゃないかって話。
一つのプロジェクトの新規機能Aを担当する人、
同Bを担当する人、同C担当する人、バグ1を修正する人、以下略って。
そういう人が、それぞれtrunkにコミットしたらダメだろ？
だからブランチという機能があるんだが。
169:デフォルトの名無しさん
14/08/25 00:39:19.30 nKRJ5J1t.net
そんなの現場次第。
170:デフォルトの名無しさん
14/08/25 15:34:41.14 W/mMJDzT.net
>>166
> 一つのプロジェクトの新規機能Aを担当する人、
> 同Bを担当する人、同C担当する人、バグ1を修正する人、以下略って。
>
> そういう人が、それぞれtrunkにコミットしたらダメだろ？
ん？それって10人で開発する場合、最低10個のbranch切って各人がそれぞれのbranchで開発するってこと？
それ、いつtrunkにマージするの？
171:デフォルトの名無しさん
14/08/25 15:42:29.04 V08rwKRx.net
>>168
そりゃできた順（もしくはリリースする順）にマージだろ
172:デフォルトの名無しさん
14/08/25 16:38:16.81 W/mMJDzT.net
>>169
> そりゃできた順（もしくはリリースする順）にマージだろ
で、、マージ後branchは消すの？
消さないと、1リリース毎に見ると数百のbranchが残るよね。
173:デフォルトの名無しさん
14/08/25 16:39:32.30 W/mMJDzT.net
それとも、マージ後trunkの変更点をbranchに取り込んで、各人はそのbranchで作業を続行するのかな？
それだと、branchの意味あんまなさそう・・・。
174:デフォルトの名無しさん
14/08/25 17:14:52.76 wFnHFJpO.net
ブランチの利点が理解できてない人がいるとは思わなかったｗ
175:デフォルトの名無しさん
14/08/25 17:19:00.91 n6MYI6xH.net
そんなもんだろ。
subversionをバックアップとしてしか使ってない証拠。
まあ、普通はマージを日常的に使ってたら
subversionは使いづらくてしょうがないから
gitに移行するんだけどねｗ
176:デフォルトの名無しさん
14/08/25 17:38:32.48 uT4xDhJR.net
こりゃ面白い。急成長じゃないか。
明日にもgit叩きを始めそうな展開で胸が熱い。
>>161 ブランチどうやって切ればいいんですかね；；
>>163 トンチンカン
>>166 だからブランチという機能があるんだが。
177:デフォルトの名無しさん
14/08/25 17:44:56.29 Q6cKsmaN.net
>>174
> >>161 ブランチどうやって切ればいいんですかね；；
質問は「どうやって切る」じゃなくて
「どういう時に切る？」だろ？
開発フローを効いてるだけだと思うが？
160 名前：デフォルトの名無しさん[sage] 投稿日：2014/08/24(日) 16:17:32.62 ID:1q09/hom
subversionにgit flowとかgithub flowみたいなのってある？
subversionを使ってどういうふうに運用するかを
決めた開発のフロー
178:デフォルトの名無しさん
14/08/25 17:46:57.39 uT4xDhJR.net
なんだ、じゃあどういうときに切るかはまだ分からないままか。
じゃあ >>162 のまま特に変える必要ないなぁ。
179:デフォルトの名無しさん
14/08/25 17:53:04.86 9I6muac3.net
>>176
並行開発はどうやってるの？
新規機能を幾つか平行して開発している場合。
180:デフォルトの名無しさん
14/08/25 18:20:23.87 9I6muac3.net
>>176
一人開発で使ってるだけで、そういう高度なことは
やってないから知らない。って答えてもいいんですよ？
181:デフォルトの名無しさん
14/08/25 18:29:44.44 t3eJagh2.net
182:ID:W/mMJDzTはsubversion book読んで出直しなさい。 レベルが低過ぎて会話に追従出来てない。
183:デフォルトの名無しさん
14/08/25 18:36:43.65 dIutByqY.net
そう言えば俺svnでは一度もマージ使った事なかったな…
なんて事、trunk一本糞なオープンソースに関わりながら思い出した
184:デフォルトの名無しさん
14/08/25 18:51:31.79 fQ2cskxs.net
subversionの人にとってはsubversionは
バックアップツールなんだよ（笑）
URLﾘﾝｸ(www.amazon.co.jp)
> 内容（「BOOK」データベースより）
> この本は、Subversionというバックアップのためのソフトについて説明したものです。
> 内容（「MARC」データベースより）
>
> Windows上で使えるバックアップツール「Subversion」の基礎知識から
> 具体的な使い方までをわかりやすく解説。テキストファイルも画像ファイルも、
> ファイルもフォルダも、好きなときにバックアップできる!
185:デフォルトの名無しさん
14/08/25 20:23:33.02 uT4xDhJR.net
>>177
ブランチ作るよ。普通に。
てか、バグフィクスでブランチを作るかどうかの話じゃないの
186:デフォルトの名無しさん
14/08/25 20:33:53.30 uT4xDhJR.net
>>168
人単位でブランチは作らない。
>>166が一機能一人みたいな書き方してるからアレだけど、
新規機能が10個あって、それらのリリースタイミングが同一であることが明らかではない場合、
個別にブランチを作る。
>>170-171
複数バージョンを並行してメンテする場合、リリースブランチとして運用をするために残すこともある。
大抵は、リリース時にタグを打っておいて、必要ならタグからブランチを作成してメンテするけれど。
187:デフォルトの名無しさん
14/08/25 22:36:00.58 U7wi69h2.net
|
＼ __ ／
＿ （ｍ） ＿ﾋﾟｺｰﾝ
|ミ|
／ .｀´ ＼
∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
（・∀・∩＜そうだ！subversion の開発は、git を使ってやればいいんだ
（つ 丿 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
⊂＿ ノ
（＿）
188:デフォルトの名無しさん
14/08/25 22:45:10.35 2hV0rF99.net
gitならば、gitならば問題ない
と言いたい人がいるようだけど、
どう問題ないのか是非聞かせていただきたい。
189:デフォルトの名無しさん
14/08/25 23:20:37.21 dIutByqY.net
>>160,161の質問でここまで紛糾する理由がワカランチン
> subversionにgit flowとかgithub flowみたいなのってある？
俺もあるのか知りたい
190:デフォルトの名無しさん
14/08/25 23:30:46.07 GZsp8R0a.net
別にブランチを避ける文化もあるってことでいいのでは。
191:デフォルトの名無しさん
14/08/25 23:52:49.55 tCaIl0Ur.net
>>166
バグに対するブランチの話じゃないのか？
いつの間に複数の機能追加の話になったんだ？
192:デフォルトの名無しさん
14/08/26 00:09:07.68 cOpcHFf6.net
>>186
>>160 で揉めてる訳じゃないでしょ
Subversion にはその手の機能はないと思う
ブランチ云々は宗教戦争ネタなので大抵揉める
193:デフォルトの名無しさん
14/08/26 00:13:06.12 wWUBoWT7.net
いや機能じゃないでしょ。。
194:デフォルトの名無しさん
14/08/26 00:24:29.72 dFxdDibp.net
そ、そうなのか、gitには運用フロー機能があるのか。。
195:デフォルトの名無しさん
14/08/26 00:58:42.64 VaQvEhwE.net
>>190
ああ、git flow で使うフローと言うか、お約束について聞いてたんだな
そう言う意味なら trunk/tag/branch も一つのお約束だから、あるって言えなくもないかな
>>191
まあ、git flow は運用フローの支援機能ではある
196:デフォルトの名無しさん
14/08/26 00:59:38.52 03rKZRQN.net
ないアルよ
197:デフォルトの名無しさん
14/08/26 11:25:57.07 HxwOhsx5.net
>>192
> そう言う意味なら trunk/tag/branch も一つのお約束だから、あるって言えなくもないかな
trunk/tag/branchがある前提で、git flowのような運用をする方法がsvn界隈で確立されてるかって疑問だと思う。
そして、それは確立されていない。
198:デフォルトの名無しさん
14/08/26 12:32:08.23 naQUKVyS.net
>>194
> そして、それは確立されていない。
どういう基準で確立されてないと言えるんだ？
されていないと言い切るんだから、明確に答えられるよね？
199:デフォルトの名無しさん
14/08/26 12:39:00.35 aWey4WbF.net
広く(一般に)知られた手法は無い。って事だろ。アスペ。
200:デフォルトの名無しさん
14/08/26 13:04:39.81 HxwOhsx5.net
>>195
某かのbest practiceがあるなら、教えて欲しい。
確立されたbest practiceなら、多分それには名前が付いているはずで、ググれば少なくとも数千はヒットすると思われる。
そういうのある？
201:デフォルトの名無しさん
14/08/26 13:30:57.85 naQUKVyS.net
>>197
trunk/tag/branch を切ると言うのも運用だろ？
そして、各々にどんなものを入れるかを決めるのも運用だよね。
逆に言うと何ができてたら、best practice って言えるんだ？
202:デフォルトの名無しさん
14/08/26 14:53:02.80 03rKZRQN.net
git flowってさ、trunk,brances,tagsっていうお約束より更に一つ上の層のお話だとボク思うんだ
203:デフォルトの名無しさん
14/08/26 15:07:10.76 HxwOhsx5.net
>>198
いやだからgit-flowとかGitHub Flowのようなものがsvnにはあるの？って話なんだけど。
まず最初にtrunk/tabs/branchesを作りましょうというところまではsvnbookでも推奨されていて、
ほとんどの人がそれに従ってると思われる。
ただ、どういうときにどういうbranchを切るかとか、いつ誰がどのbranchにマージするのかとか、
メインとなるbranchのマージ先はtrunkなのかそれともhoge-branchなのかとか、リリースは
どこからやるのかとか、リリース後はどうすべきかとか、bugfix時の運用とか、そういう運用の
お手本となるようなbest practiceってあるのか、そういうこと。
まぁ大体の所はオレオレ運用じゃないのかなぁと思ってるんだけど。
ちなみにうちは、Redmineの1チケットがtrunkへの1コミットとなるよう、必要ならbranch切れ、くらいで運用してる。
204:デフォルトの名無しさん
14/08/26 15:10:21.15 dFxdDibp.net
ベストプラクティスに名前をつけるという行為はさほど一般的じゃないと思うけど、
どのベストプラクティスがベストなんだ？という面倒なことを避けるために名前をつけるのはひとつの方法なのかなぁ。
大抵みんなやり方が同じようになってきてるから、こういうときどうすればいいのって聞けばいいんじゃないかな。
205:デフォルトの名無しさん
14/08/26 15:53:13.50 HxwOhsx5.net
>>201
> 大抵みんなやり方が同じようになってきてるから、
そうなの？
新機能の実装をtrunkでがんがんやる派とそうじゃない派で、まず大きく二つに分かれる気がするけど。
206:デフォルトの名無しさん
14/08/26 17:28:20.40 NSwC5k+Z.net
俺は1本のままで保守モード移行と同時にそこまでの履歴丸ごとコピーで別リポジトリに追い出してた@decade ago
1.x/trunk---t-2.x/trunk---t-3.x/trunk---t-4.x/trunk---
L-1.x L-2.x
207:デフォルトの名無しさん
14/08/26 18:04:37.65 dFxdDibp.net
>>202
えーっと、その前者の方法、それもありじゃないって思える？
208:デフォルトの名無しさん
14/08/26 18:53:32.91 IPwBXJgH.net
trunkで開発すすめて特定の所からリリースブランチ作るって
やり方もあるよね。
209:デフォルトの名無しさん
14/08/26 22:25:51.51 naQUKVyS.net
>>199
一歩先なのは認める
ただ、trunk/tag/branch も何もないところに比べれば半歩は進んでいるわけで、その間の何があれば best practice と言えるのか？ って話。
>>200 とか URLﾘﾝｸ(danielkummer.github.io) の言ってることはわかるけど、運用をより具体的に決めてるだけとも言える。
210:デフォルトの名無しさん
14/08/26 22:42:03.56 dFxdDibp.net
>>206
ベストプラクティスの意味が分からないって言ってるんだろうか。
> 運用をより具体的に決めてるだけとも言える。
211:デフォルトの名無しさん
14/08/26 22:47:19.91 0QshLCvc.net
ベストベストって開発規模やコミット粒度によって何がベストかは違うだろ
統一見解なんて求めるのは無意味
212:デフォルトの名無しさん
14/08/26 22:49:23.21 naQUKVyS.net
>>207
ベストプラクティスにもレベルがあるって話。
0/1 でしか考えられないの？
213:デフォルトの名無しさん
14/08/26 22:55:05.25 naQUKVyS.net
>>208
いや、それを言い出したらきりがない。
六割とか八割の人が便利に使えるならそれはそれで ベストプラクティス でいいと思うよ。
ただ、ベストプラクティスはこれしか認めんとか言い出したら、それはおかしいよね。
214:デフォルトの名無しさん
14/08/27 00:16:36.50 UFd+PdSa.net
>>210
じゃあどうなればベストプラクティスなんだ？これは運用を決めてるだけじゃないかなんていう
ばかげたレスをしなければいいのに。
二転三転してんよ。
215:デフォルトの名無しさん
14/08/27 00:20:37.72 UFd+PdSa.net
>>208
多くの人が困った出来事に見舞われなくて済むように作られた集合知だから、
ある程度は統一されるよ。
>>202 の前者なんてのは痛い目を見て二度とするもんかと心に誓う手法でしかない。
216:デフォルトの名無しさん
14/08/27 01:21:09.81 1NXBn9Ay.net
1.9で予定されていた機能の殆どは延期
減り続けるユーザー
MLへの投稿も減少の一途
Apacheからも邪魔者扱い
どうすんの？
217:デフォルトの名無しさん
14/08/27 07:38:51.42 KL0wurV3.net
>>211
ひょっとして壊滅的に理解力がないとか？ w
俺は git flow も、trunk/tag/branch もレベルは違うが両方ともベストプラクティスだと言う立場だよ。
なので、>>194 に
> 確立されていない。
と言い切る理由を聞いてるだよ。
まあ、
> >>202 の前者なんてのは痛い目を見て二度とするもんかと心に誓う手法でしかない。
とか言う人には、理解できないかな。
218:デフォルトの名無しさん
14/08/27 07:42:25.58 KL0wurV3.net
>>213
別に今のまま使えばいいだけでしょ。
そのうちもっと便利なものが出てくれば移行すればいいだけだし。
>>213 が subversion の行く末を案じて、何とかしようと思ってるならがんばれーって応援するけどね。
219:デフォルトの名無しさん
14/08/27 07:44:19.56 W2qyiycm.net
svnで言うtrunk/tag/branchはこう使ったらいいぜ！
ってのがgit-flowなんですけど…
220:デフォルトの名無しさん
14/08/27 10:54:18.36 JjSOikWD.net
>>214
いやだから「git-flowのような」svnの運用方法はまだ確立されてないよねって話なんですけど。
221:デフォルトの名無しさん
14/08/27 11:39:27.80 p0VoVO4w.net
>>217
FreeBSDとか大きいプロジェクトならあるだろ。
お前が知らないだけ。
222:デフォルトの名無しさん
14/08/27 12:17:18.99 KL0wurV3.net
だから「ような」ってなに？
何を満たせばお前さんが言う「git flow のような運用方法」になるんだ？
って話をしてるんだが。
223:デフォルトの名無しさん
14/08/27 12:43:28.37 JjSOikWD.net
>>219
例えば、Subversionを初めて導入するチームが、とりあえずの指針として使えるような運用方法。
初めて導入する場合、trunk/branches/tagsを作るところまでは良いが、おそらくそこで途方に
暮れることになるだろう。
つか、git-flowとかGitHub Flow知ってる？
224:デフォルトの名無しさん
14/08/27 13:47:44.30 UFd+PdSa.net
>>217
新規開発ならまだしも、trunkで"新機能"開発を認めるような人って、
develop featureブランチを作らないことで何が起こるかしらない人かもしんない。
そうなら説明しても理解できないと思う。
git flowは使ったことないけど、ブランチ構成管理の図を見る限りsvnでも大抵同じ構成でやってるよ。
svnやgit、他のVCSひっくるめてブランチ管理のベストプラクティスってのはもうあって、
それをサポートするための実装の一つがgit flowなんじゃないかなぁと思うけど、gitユーザから見るとどうですかね。
225:デフォルトの名無しさん
14/08/27 13:56:08.31 KL0wurV3.net
>>220
> おそらくそこで途方に暮れることになるだろう。
ハンドブックも読まないようなチームならそうだろうね。
URLﾘﾝｸ(svnbook.red-bean.com)
> つか、git-flowとかGitHub Flow知ってる？
>>206 のリンク先の内容では不足なのか？
226:デフォルトの名無しさん
14/08/27 14:01:53.23 KL0wurV3.net
>>221
思い込みが激しすぎる
trunk で新機能開発してるところもあるし、それでちゃんと回ってる
227:デフォルトの名無しさん
14/08/27 14:32:21.64 JjSOikWD.net
>>222
もう、どう言ったらいいのか・・・。
svnbookで説明されてるされてることを、実際にどう運用するのが良いのかの指針となるような
git-flowやGitHub Flowのような運用方針が、人口に膾炙された形でsvn界隈にあるのかって
ことで、それはまだないでしょということなんだけど、わかんないかな。
長年svnを使ってれば、そりゃ自分たちにフィットした運用方針があるだろうけど、他SCMから来た人とか
初めてのSCMとしてsvnを選んだ（選ばざるをえなかった）人たちが、どう運用を開始すれば良いのかの
情報ってそれほどないでしょ。
そういうのがあれば、>>160にこれを参考にするといいよってURLを示すだけで終了でしょ。
228:デフォルトの名無しさん
14/08/27 15:01:37.11 UFd+PdSa.net
>>222
よりによってそれを貼るって、レベルが違いすぎて話にならない。ヨチヨチじゃねえか。
>>223
ちゃんと回ってるうちはそれでいいと思うもんなんだよ。
229:デフォルトの名無しさん
14/08/27 18:44:05.74 KL0wurV3.net
>>224
svnbook に書いてなくて git flow で決められてる方針とやらを書けばいいだけでしょ？
具体的に何も示さずに svnbook 見てもわからんけど、git flow なら方針書いてあると言われてもね。
なお、情報ソースは >>225 がレベルの高い奴を示してくれるらしいから、それでもいいよ (w
230:デフォルトの名無しさん
14/08/27 19:55:48.72 W2qyiycm.net
今になってtrunk/branches/tagsもベストプラクティス、がじわじわきだした
231:デフォルトの名無しさん
14/08/28 09:57:20.57 hbdIfiYh.net
>>226
> 具体的に何も示さずに
って、俺はそんなもの（確立された運用方針）なんかないって言ってるんだから、示すも糞もないよ。
あるんだったら、お前がURL示せ。
232:デフォルトの名無しさん
14/08/28 12:31:06.51 XxtALw5X.net
>>228
はあ？
git flow にはあるんじゃないのか？
両方ないと言うなら、それでもいいけど。
233:デフォルトの名無しさん
14/08/28 12:54:49.24 hbdIfiYh.net
>>229
一体何の話をしてるんだ？
gitにはgit-flowやGitHub Flowのような開発フローがあるが、svnにはそれに類するものがあるのか
というのが最初の疑問(>>160)。
で、そういうのは残念ながら無いというのが俺の主張。
「svnbook に書いてなくて git flow で決められてる方針とやらを書」いたものなんてどこにも無いよ。
234:デフォルトの名無しさん
14/08/28 18:46:05.74 XxtALw5X.net
>>230
だから、
> gitにはgit-flowやGitHub Flowのような開発フロー
の具体的な内容を書いてくれればいいだけ。
svnbook には、典型例としてソフトウェアリリースや（特定機能の）開発におけるブランチの使い方が書いてあるけど、君は git flow はそんなもんじゃなくて、もっと色々決められてるって言うんでしょ？
それを教えて。
URLﾘﾝｸ(svnbook.red-bean.com)
235:デフォルトの名無しさん
14/08/28 23:21:36.65 Djfy5D0r.net
わかった上でわざとずれたこと書いて荒らしてるんじゃないかという気がしてきた。
236:デフォルトの名無しさん
14/08/29 00:00:57.86 kapyA6bl.net
ぐぐれば図はでてくるんだけどこれじゃ理解できないってことなのかなぁ。
URLﾘﾝｸ(image.itmedia.co.jp)
そのやり方はsvnbookを見れば同じようなことが書いてあるとでも言い出すんだろうか。
237:デフォルトの名無しさん
14/08/29 00:07:08.18 Bkb0jioJ.net
まぁベストプラクティスおじさんも
>>160が欲しがるURLに辿り着けたようだし
この辺でもういいんじゃないの？
238:デフォルトの名無しさん
14/08/29 07:21:09.31 c8acy8St.net
>>233
> そのやり方はsvnbookを見れば同じようなことが書いてあるとでも言い出すんだろうか。
そんなご託は、違いを説明してから言えば？
239:デフォルトの名無しさん
14/08/29 10:15:23.47 IvLQYdhB.net
へえ、svnbookでは、こんなことが推奨されてるのか。
> Developers commit all new work to the trunk. Day-to-day changes are committed to /trunk: new features, bug fixes, and so on.
240:デフォルトの名無しさん
14/08/29 12:52:13.11 yH9aSNf4.net
>>236
小規模なチームならそのやり方でいいだろうし、もう少し複雑な開発なら次の節にも目を通しておいた方がいい
241:デフォルトの名無しさん
14/08/29 14:34:17.02 kapyA6bl.net
>>235ってID:KL0wurV3？
242:デフォルトの名無しさん
14/08/31 10:27:47.17 w7igHjFL.net
SVN1.6を使ってるプロジェクトで仕事をしている不幸な俺が来ましたよ。
今のプロジェクト資産をSVN1.8 に移行させたいんだが、dump してload でOKですか？
243:デフォルトの名無しさん
14/08/31 12:37:14.01 vjR2LjMT.net
>>239
この際gitに移行しろｗ
そうすりゃsvnなんて、できたものをアップするだけの
単なる中央サーバーにしておける。古くても全然問題なし。
244:デフォルトの名無しさん
14/08/31 13:03:00.35 w7igHjFL.net
>>240
全くその通りで、git に移行出来ればベストなんだが、
うちのプロジェクトの連中はSVN1.6に何の疑問も感じない管理職だの外注さんだのから
構成されていて、git 入れるとか言ったらそれだけでひと悶着ありそうな気配なので、
SVN以外は無理な感じ。
245:デフォルトの名無しさん
14/08/31 13:22:54.88 vjR2LjMT.net
>>241
違う違う。自分一人でgit使えばいいの。
ローカルだけで。
自分だけはgitで楽をする。
他の人は成長しないままｗ
246:デフォルトの名無しさん
14/08/31 13:55:19.31 kY+m/tLd.net
タイムスタンプですね
わかります
247:デフォルトの名無しさん
14/08/31 14:13:58.95 lJhm1dB+.net
今更人に聞けない。
「ぎっちょ」って呼んで良いんだよな
248:デフォルトの名無しさん
14/08/31 14:43:01.38 1nPrgnOa.net
まわりが徐々に移行しているときに同じようにやっておかないと
いつの間にか直接移行できなくなるほどバージョンに差ができていたりするよなｗ
249:デフォルトの名無しさん
14/08/31 14:45:12.60 6qeU6N/A.net
わざわざgitに変更するメリットあるの？
250:デフォルトの名無しさん
14/08/31 15:11:36.05 phP4JmF2.net
>>239
dump load いらないよ。
URLﾘﾝｸ(subversion.apache.org)
URLﾘﾝｸ(subversion.apache.org)
251:デフォルトの名無しさん
14/08/31 15:15:09.72 w7igHjFL.net
>>242
何という裏ワザ
>>245
そう思いますよ。駄目なプロジェクトってずっと同じもの使ったりするんで
何とかして欲しいです。
>>247
dump load しなくても大丈夫なのかな、、
252:デフォルトの名無しさん
14/08/31 16:08:57.38 phP4JmF2.net
>>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.
253:デフォルトの名無しさん
14/08/31 16:45:43.70 w7igHjFL.net
>>249
なるほど
254:デフォルトの名無しさん
14/08/31 17:57:57.45 gvWJPatT.net
先月だかまで1.6だたけどbackportsに1.8来てたからうpぐれしたわ
255:デフォルトの名無しさん
14/08/31 18:39:37.01 nYTEAaY7.net
俺なんかなー
レポジトリを1.7にした一週間後くらいに1.8が出て涙目で1.8に上げたわ
256:デフォルトの名無しさん
14/08/31 19:21:08.74 EhwSagBI.net
互換性を調べられないような人にまで
駄目と言われるプロジェクトか
よっぽど駄目なんだろうな
257:デフォルトの名無しさん
14/08/31 19:27:26.51 phP4JmF2.net
「gitに移行するのがベストだから移行したい」ってこの人が言い出したら、俺だって反対する。
お願いだから何もしないでくれの裏返しで。
258:デフォルトの名無しさん
14/08/31 23:19:55.78 y65ys8N1.net
>>254
反対の理由は？
259:デフォルトの名無しさん
14/08/31 23:29:23.88 phP4JmF2.net
>>255
gitに移行すること自体は別に反対じゃない。
ただ、検証能力の低い人が移行したいと言い出すことについては反対。
260:デフォルトの名無しさん
14/09/01 00:21:24.59 AXYuTZK8.net
>>256
なんで条件つけるんだよｗ
検証能力が低い人が決めたことは
全部反対ってことで、git関係ないじゃないか。
261:デフォルトの名無しさん
14/09/01 00:29:29.14 dsbfj0jc.net
>>257
そうだよ。git関係ないよ。そう書いたつもりだけど。
なぜgitがベストだと判断したか、説得させる力がないのを、
あの人は疑問も持たず使ってるだとか、だめなプロジェクトを何とかしてほしいだとかいう人だよ？
アップグレードに関する知識も、答えが載ってるページを貼ったにもかかわらず理解できなかった人だよ？
そういう流れがあった上で、>>254では「この人」が言い出したらとなってるんだ。
262:デフォルトの名無しさん
14/09/01 00:33:17.89 dsbfj0jc.net
ちなみに、業務でやってるわけじゃないのならこういう言い方はしなかったと思うよ。
ただただ、業務上ソース管理の管理者的な立場にいるような人があのザマだったからで。
263:デフォルトの名無しさん
14/09/01 00:42:08.42 AXYuTZK8.net
その前にさ、subversionが別とベストだと
判断した理由がなければ、比較できないよね？
どうせsubversionは惰性で使ってるだけなんだろ？
gitに理由を求めるのであれば、
subversionに理由を求めてもいいはずだ。
264:デフォルトの名無しさん
14/09/01 00:46:31.35 dsbfj0jc.net
>>260
向きを変えてもいいよ。
現状gitを使っていて、管理者としての知識が欠けている人が、
svnのほうが便利らしいからsvnにしたいんですって言い出したらどうする？
よしんば知識が欠けていなかったとしても、なぜ？って話をするのが通常でしょ？
265:デフォルトの名無しさん
14/09/01 01:18:17.28 AXYuTZK8.net
>>261
あぁ、管理者が馬鹿なのか。
なら馬鹿な管理者よりも
有名な人が使っている人が
選んでいるものを使いますね。
266:デフォルトの名無しさん
14/09/01 14:02:43.92 6lz4AwEV.net
>>258
うぜぇ
267:デフォルトの名無しさん
14/09/01 17:14:42.01 AS5e+N3+.net
頭が悪くて反論できないならgitスレに帰りなよｗ
268:デフォルトの名無しさん
14/09/01 17:17:31.52 6lz4AwEV.net
頭が悪くてスレ違いだってことがわかんないんでしょうか
269:デフォルトの名無しさん
14/09/01 20:32:46.44 gwJalaDc.net
で git flow がーとか騒いでた奴は、結局 >>233 で終わりだったの？
270:デフォルトの名無しさん
14/09/02 15:03:57.57 OYzSQhCX.net
あんなに元気だったのにな。
突然静かになると逆に心配ですらある
271:デフォルトの名無しさん
14/09/02 15:35:21.67 3p6fLY1c.net
svnbookがbest practice
272:デフォルトの名無しさん
14/09/13 16:12:11.13 278ay5Hi.net
質問させて下さい。
svn logで削除されてしまったファイルの履歴を見ることは可能ですか？
最新版で削除されている場合、エラーになってしまいます
pathではなくURL指定にしてみたり、-rでまだ削除されていないrevisionを指定してみたりしましたが、ダメでした
なにか、方法があれば教えてください
よろしくお願いいたします
273:デフォルトの名無しさん
14/09/13 19:13:36.13 xWJsMKfp.net
svn log -rrev url@revでわ?
274:デフォルトの名無しさん
14/09/23 00:08:53.77 EypAVB5A.net
>>270
URL後に@revで出来ました！
ありがとうございます！！
でも、そもそもrevいくつで消されたのかわからないと、この方法も厳しいですね
やっぱり、消されていない上位のフォルダ取ってフィルタとかかっこ悪い方法しかないですかね
いずれにせよ、ありがとうございました
275:デフォルトの名無しさん
14/10/01 21:51:38.36 AofJ5YBN.net
すみません。
情報いただきたいのですが、ユーザが二人いて、両者が同じバージョンの同じファイルをupdateしたとします。
そのうち片方がdelete、commitを行いファイルをサーバから削除したとします。
その状態でもう片方がそのファイルを編集して、その後、サーバでファイルが削除されていることに気がついてupdateをしたら何が起こりますか？
ファイルがワーキングコピーから削除されることを期待しているのですが、うまく動きません。
コンフリクトの解決でなにか必要なオプションがあるのですか？
276:デフォルトの名無しさん
14/10/01 22:34:23.68 dBYSrlyc.net
>>272
> updateをしたら何が起こりますか？
コンフリクトするんじゃね？
> ファイルがワーキングコピーから削除されることを期待している
編集中の内容がなくなるような動作はしないはず。
> うまく動きません。
なんでどうなるのか書かないんだ？
普通の板ならいざ知らず、ここはム板なんだよ。
277:デフォルトの名無しさん
14/10/01 22:43:39.38 DTMRbqd/.net
>>272
コンフリクトが起こる
コンフリクトを解決するのはユーザの仕事
コンフリクトを起こしてしまった人間が、自分の仕事を破棄しても良いと判断するなら、revertすれば良いのでは？
278:デフォルトの名無しさん
14/10/01 22:46:51.36 DTMRbqd/.net
>>273
お前…偉いな
他意は無いよ
素直にそう思った
> なんでどうなるのか書かないんだ？
> 普通の板ならいざ知らず、ここはム板なんだよ。
これ重要だよな
279:デフォルトの名無しさん
14/10/02 01:46:05.51 XIrrMuib.net
どうなってるかぐらい読めるだろ。
> ファイルがワーキングコピーから削除されることを期待しているのですが、うまく動きません。
うまく動かない = 期待通りの動作をしない = ワーキングコピーに残ったままになる
> コンフリクトの解決でなにか必要なオプションがあるのですか？
コンフリクトが発生している
280:デフォルトの名無しさん
14/10/02 09:46:38.27 zHXM1gHR.net
アホはうまくいかない場合に高い確率で予想もつかない操作をしている。
したがって現在の状況は激しく不明。適切なアドバイスは不可能。
281:デフォルトの名無しさん
14/10/02 09:52:19.05 vjyI8iPg.net
馬鹿には無理
282:デフォルトの名無しさん
14/10/02 10:04:16.90 mcw6ATuL.net
俺らの常識を超えるのはよくあることだが
予想もつかないと認めてしまうともはや転職するしかない
283:デフォルトの名無しさん
14/10/02 12:35:56.17 iu9W8QST.net
>>272
もう答えが出てるも同然なんだけど、親切ぶって書いておくと
＞コンフリクトの解決でなにか必要なオプションがあるのですか？
コンフリクトの解決として、ローカルにあるファイルを生かすのか、削除するのかは
ユーザーが選ぶ必要がある。
その選択がすでに決まっている(今回の場合はリポジトリ優先)なら update / resolve のオプションで
--accept theirs-conflict か theirs-full が使えるかもしれない。
284:デフォルトの名無しさん
14/10/02 22:44:40.53 YtrPZWGc.net
>>279
> 予想もつかないと認めてしまうともはや転職するしかない
自社製品（ソフトウェア）のサポートしたことあるけど、色々ヒアリングしたら結局インストールしてないとかはまだかわいいもので、全く関係のない他社製品のクレームいれてきて、すぐ直せとか、予測なんてとても無理 w
285:デフォルトの名無しさん
14/10/03 00:13:17.34 sUnjKgGy.net
予想できる範囲の予想を放棄することについて言ってんでしょ。
理解力のなさが致命的じゃないか。そんなのでサポートできるのかどうか疑問だが、
過去形だからもうサポートはしてないんだよね。賢明だと思う。
286:デフォルトの名無しさん
14/10/03 07:31:53.97 x+Ir+7bo.net
>>282
なんかアホが絡んできたぞ
まあ、これぐらいは予想できてたけど w
287:デフォルトの名無しさん
14/10/03 0
288:8:15:06.89 ID:N0NEXaB4.net
289:デフォルトの名無しさん
14/10/03 08:30:51.96 SuG4O46a.net
他社製品のクレームぐらい事例にありそうだけど
290:デフォルトの名無しさん
14/10/03 09:21:34.28 N0NEXaB4.net
ヒアリングせず他社製品のクレームだと予想してそれへの対応するのか?
死んだ方が良いぞ、お前。
291:デフォルトの名無しさん
14/10/03 10:11:59.67 SuG4O46a.net
お前のレスは読み飛ばしたからお前に対するレスじゃないんだ
292:デフォルトの名無しさん
14/10/03 16:32:03.89 N0NEXaB4.net
残念ながら「事例」が出てきてるのは、お前が読み飛ばしたはずのオレのレスなんだ。
頭悪いぞ、お前。
293:デフォルトの名無しさん
14/10/03 17:16:24.75 SuG4O46a.net
おまえは>>281か?
294:デフォルトの名無しさん
14/10/03 17:39:13.94 MGOEkXEo.net
お互い予測できてない会話の例
295:デフォルトの名無しさん
14/10/03 17:49:28.71 SuG4O46a.net
>>283 書いてからしばらくたって ID変えてまで >>284 書くから別人かと思った
～を聞いてみて～という返事が返って来たら、他社製品の○○のせいだからお引取り願う
なんて事例は結構あるかと思ったけど
296:デフォルトの名無しさん
14/10/03 18:00:02.33 lXIQAzKJ.net
２ちゃんで他人か自演かを議論しても殆ど意味は無い
297:デフォルトの名無しさん
14/10/03 18:14:35.26 x+Ir+7bo.net
>>291
> ～を聞いてみて～という返事が返って来たら、他社製品の○○のせいだからお引取り願う
そんなやわな例ならわざわざ書かないよ
>>281 で書いたのは、うちの製品が全く関係ない例
具体的な製品名は出せないけど、例えばプリンタで印刷がおかしいというクレーム受けたから、色々ヒアリングしたら最終的に他社の製品だったというオチ
最初に型番ぐらい確認しろよ、とか言うだろうけどそんなものにまともに答えるような奴はそもそもこんなアホなクレームつけてこない
下手に無理やり型番聞こうとすると、そんなもんはどうでもいいからすぐ来て直せとかよけいに激昂して泥沼に入るだけ
298:デフォルトの名無しさん
14/10/03 18:22:03.69 MGOEkXEo.net
Subversionスレで何やってんですか
299:デフォルトの名無しさん
14/10/03 21:31:07.10 0rA8hC2X.net
マニュアル対応しかできないからこんな会話になるんだろw
300:デフォルトの名無しさん
14/10/03 21:57:20.10 9JXRawoI.net
次にお前はこう言う
「俺が予測出来ないのでは無い。相手がアスペなんだ」
「はっ？！」
301:デフォルトの名無しさん
14/10/03 23:34:16.78 p8EJU7ib.net
Subversionが停滞しているのではない。
gitが前進しているのである。
302:デフォルトの名無しさん
14/10/04 05:03:15.68 lObYY5qZ.net
>>293
あなたの経験はどうでもいいんだけど、今回の話の基点になってるのは >>272 に対する >>277 だよね。
>>272 を読んで適切なアドバイスが不可能な人は、今のところ >>277 以外にいない。
303:デフォルトの名無しさん
14/10/04 05:55:20.32 j+aw4iLv.net
>>298
あなたは >>272 なの？
適切なアドバイスかどうかは >>272 でないとわからない
>>280 みたいな具体的なコマンドラインオプションを知りたかったのかもしれないし、>>297 が正しいなら git へ go が適切だったかもしれない
あと、アドバイスができない奴でレスしない奴がいないことをどうやって確認したの？
304:デフォルトの名無しさん
14/10/04 07:03:31.85 lObYY5qZ.net
>>299
>>272じゃないよ。ところで>>299は>>293なの？
> >>280 みたいな具体的なコマンドラインオプションを知りたかったのかもしれないし、
ちがうね。期待していた動作に近い挙動をさせる方法を知りたかっただろう。
> >>297 が正しいなら git へ go が適切だったかもしれない
まさかｗ
305:デフォルトの名無しさん
14/10/04 07:12:58.07 j+aw4iLv.net
>>300
> ちがうね。
本人でもないのに断言
アホ過ぎ
306:デフォルトの名無しさん
14/10/04 08:55:27.06 9D7AARhC.net
こんなものは停滞し続けてもらわないと、
フォーマットが変わったから1からコミットし直しなんて
もう嫌だｗ
307:デフォルトの名無しさん
14/10/04 13:39:10.20 r/oIg3wR.net
>>302
何でそうなる？
308:デフォルトの名無しさん
14/10/04 15:45:10.72 ugcUiR2p.net
>>298
>>>272 を読んで適切なアドバイスが不可能な人は、今のところ >>277 以外にいない。
お前が適切なアドバイスとやらをしてみろ。ワ
309:デフォルトの名無しさん
14/10/06 02:58:33.52 0Y2OJiB/.net
何で伸びてんのかと思ったら理解力がないものとそれを無駄にあおり続けるものの応酬だった。
2chでは良くあることだけどこのスレでそうなるとはね。
310:デフォルトの名無しさん
14/10/06 03:22:18.69 S+cxwUfE.net
２ちゃん中毒症状の進行
1.物騒な掲示板だなと印象を持つ
2.全部自演だと思い込む
3.自分で自演を始める
4.自分で自演してるのに他人の自演を叩く
5.自演じゃないと言い張る
6.他人のレスと自分のレスの区別が付かなくなる
311:デフォルトの名無しさん
14/10/06 21:58:30.50 2jlCLSza.net
>>306
6番って、
他人へのレスと自分へのレスって事？
それとも、
自分が書いたレスを(自演だけど)本当に他人が書いたと思ってしまうって事？
前者は良くいるけど、後者は怖いよね…
312:デフォルトの名無しさん
14/10/06 22:37:11.58 +UB/EuAd.net
なんで伸びてるのかと思ったら、>>305 がヨタ話始めただけだった。
2chでは良くあることだけどこのスレでそうなるとはね。
313:デフォルトの名無しさん
14/10/07 01:57:45.48 yeRBhH6L.net
よくある流れ
314:デフォルトの名無しさん
14/11/18 11:29:16.53 4hHTj/p7.net
TortoiseSVNの「未コミット項目が残ったらコミットダイアログを再度開く」のオプションって
なんで無くなったのか分かる人いない？
一部だけコミットしてまたコミットダイアログ開くの面倒くさいよ
315:デフォルトの名無しさん
14/12/15 20:56:02.95 4cyuKd8C.net
svn logでそのレビジョンで変更があったファイル、フォルダを見れると思います
その際、削除されたフォルダの下の情報も取得するオプションはありますか？
たとえば
A(Folder)
- B(Folder)
-- C(Folder)
-- d.txt(File)
という階層があって、Bを削除された場合、そのレビジョンではBがdeletedだったと表示されると思うのですが、C,d.txtも表示させたいです
ご存知の方がいらっしゃいましたら、教えてください
よろしくお願いいたします
316:デフォルトの名無しさん
14/12/18 02:07:41.51 h1z0/qH7.net
Subversion 1.7 & TortoiseSVN 1.7 系の環境を
Subversion 1.8 & TortoiseSVN 1.8.9 に移行して、気が付いたんだが、
コミット済みのファイルをTortoiseSVN でrename して再度コミットするとエラーになる。
同じ操作をしても1.7系だとコミット出来たのに、1.8系だとエラーになる。
回避するには、コミット済みのファイルをTortoiseSVN でrename した場合は、
一つ上のフォルダに移動して、そこでコミットすると、コミット出来る。
これって仕様なんだろうけど、使いにくくないか？
317:デフォルトの名無しさん
14/12/18 02:11:07.69 mibKJ2wG.net
>>312
Subversion の rename は copy&delete の２つの操作の組み合わせとしてコミットされる。
1.7 までは rename で発生した copy だけをコミットすることができていたが、それはたいていの場合
間違い。（リポジトリ上にリネーム前のファイルと後のファイルが両方存在する状態になる）
そういう間違いを防ぐため 1.8 でこれをエラーとするようにした。とても助かる。
318:デフォルトの名無しさん
14/12/18 20:54:09.30 15LuVpQp.net
>>311
できるよ
319:デフォルトの名無しさん
14/12/19 00:10:43.61 kvpMU++U.net
>>314
できないよ
320:デフォルトの名無しさん
14/12/19 07:39:25.42 YVzRGliM.net
>>315
できるよ
321:デフォルトの名無しさん
14/12/19 22:34:23.82 n1GxhqE3.net
>>316
できないよ
322:デフォルトの名無しさん
14/12/20 18:59:23.15 gGCVpdkj.net
できるよ
323:デフォルトの名無しさん
14/12/21 00:26:40.92 PgF+sSNf.net
できないよ
324:デフォルトの名無しさん
14/12/21 00:57:31.27 icy8S1ux.net
どっちだよ(´・ω・｀)
325:デフォルトの名無しさん
14/12/21 13:28:53.87 wgEqtlVM.net
svn.exeで色々とオプション試してみたが、無理だと思う
svn.exeではなく、subversionのDLL直叩きなら、なんか方法あるかもしれんが
>>318>>316>>314
本当に出来るなら、やり方教えて欲しい
326:デフォルトの名無しさん
14/12/21 13:55:00.79 Av/isWbI.net
>>313
rename した後に同じフォルダーでcommit するとエラーで
上のフォルダーに移動してcommit するとＯＫってのが謎の仕様なんですけど、、
327:デフォルトの名無しさん
14/12/22 00:43:12.72 wZjn2wNf.net
>>321
ちょっと意地になって色々ためしたけど、無理っぽい
あと、質問なんだが、
＞subversionのDLL直叩き
これどういう意味？
328:デフォルトの名無しさん
14/12/22 08:50:25.22 6zmhakte.net
>>323
API 使えってことじゃね？
329:デフォルトの名無しさん
14/12/26 20:56:52.95 9COLSw4d.net
すみません、何方かアドバイスをお願いします
メンバの一人が間違って登録されてるファイルを全部消すと言うミスをしてしまいました
このリビジョン（仮にrev100）における操作を完全に無かったことにしてrev99=HEADの状態
にするにはどうすればよいのでしょうか？
330:デフォルトの名無しさん
14/12/26 21:08:51.98 ngP4rqwQ.net
>>325
↓こんな感じ？試してないけど。
svn cp -r99 ^/ ^/
331:325
14/12/26 21:21:58.89 9COLSw4d.net
325です
自己解決しました
332:デフォルトの名無しさん
14/12/27 03:53:42.69 O2EmQmpe.net
>>326
333:普通は逆マージ。
334:325
14/12/27 12:33:50.64 P6YUVs7g.net
325です
履歴にも残さずに完全にロールバックしたかったので逆mergeやcopyと言う方法
は選べませんでした
335:デフォルトの名無しさん
14/12/31 15:11:53.14 R9r0iQKl.net
今年はsubversionの終わりが加速した感じだった。
dev-MLの投稿数は毎月200通以下が普通になったし、
1.9は全然収束しない。
しかも、1.9は機能を削りまくってる。
まともなrenameトラッキングは当分先みたいだし。
うちの会社もあちこちでgitに移行してるし。
336:デフォルトの名無しさん
14/12/31 15:15:26.31 lvkAiJ/l.net
それは良かった
337:デフォルトの名無しさん
14/12/31 15:35:26.41 uw/dheYU.net
このスレーってもうSubversion単体スレーである必要が全く完全に無いだろ
バージョン管理ツールスレーとかでいいんじゃないの？
>330 も言うようにどんどんgitへの移行も進んでるし、今更subversionで語る
ようなことも無いだろ
338:デフォルトの名無しさん
14/12/31 16:36:32.17 69RlDRjx.net
人居ないからな
廃合は仕方ない
339:デフォルトの名無しさん
14/12/31 19:52:34.34 +R6nzZDg.net
Gitだと、ロックして編集とかEXCELの管理とか
やりにくいんじゃなかったっけ？
340:デフォルトの名無しさん
15/01/01 03:48:37.20 EqvEBySL.net
そういうのはSubversionが向いてる
もっともエクセル単体ならエクセル自身でバージョン管理した方がいいけど
341:デフォルトの名無しさん
15/01/02 00:56:10.13 2EPSXalc.net
ロックはともかくExcelにSubversionの利点なんてあったっけ？
バイナリ差分があまり効かないからgitと大して変わらないような
342:デフォルトの名無しさん
15/01/02 01:38:07.24 Mlsgxxua.net
subversionは名前が悪かったと思う。何しろ「サブ」だし。
せめてmainversionとかの名前ならもうちょっとユーザが増えた気がする
あと、gitなら「じっと」「ぎっと」「ぎと」って感じで呼ばれることが多いけど
subversionは「さぶ」「さぶん」「さぶば」で通用する事はあまり無くて大体が
「えすぶいえぬ」って呼ばれるのも痛い
343:デフォルトの名無しさん
15/01/02 07:49:21.97 Kr2J2p4W.net
確かにsub-versionだと思っているgitは多いかもね。
344:デフォルトの名無しさん
15/01/02 08:05:46.34 ibIo6Doo.net
今更のつりだろ、スルーしとけよ
345:デフォルトの名無しさん
15/01/02 22:30:49.49 yUe16gzJ.net
URLﾘﾝｸ(blogs.yahoo.co.jp)
346:デフォルトの名無しさん
15/01/02 22:33:51.24 yUe16gzJ.net
URLﾘﾝｸ(www.royta.net)
347:デフォルトの名無しさん
15/01/03 01:46:39.23 d2Sh2V72.net
>>336
ロックが取れる事がexcel(というかバイナリ)を使う上での最大のメリットってことでしょ。
一人で使う分には、確かにgitでも変わらんけど。
348:デフォルトの名無しさん
15/01/03 01:49:31.60 d2Sh2V72.net
>>335
エクセル自身のバージョン管理はオススメできぬ。
ファイルが肥大して大変だし、壊れた時のリスクが高い。
349:デフォルトの名無しさん
15/01/04 02:36:33.25 i9Li470n.net
バイナリ差分があまり効かないというが、がんばればしっかり差分取れるものではある。
ただ面倒なんだよなopenxml
350:デフォルトの名無しさん
15/01/08 21:44:20.48 G6P01zOT.net
OfficeはOffice自身でバージョン管理できるし、本格的にビジネスで使うならSharepointがある
ソースコードと一緒に管理したいならSvnでもいいけど
351:デフォルトの名無しさん
15/01/11 10:21:40.94 CE66uVvw.net
質問させて下さい。
あるファイルをaddしてcommit、編集してcommit、deleteしてcommitしたとします。 -> この履歴を①とします。
その後、同じ名前のファイルをaddしてcommitしたとします。 -> この履歴を②とします。
その状態で、その名前に対し、svn logをすると、②の分の履歴しか取得できません。
svn logに渡すpathに@バージョン番号をつけると①の履歴が取れますが、逆に②の履歴が取れません。
おそらく、subversionの頭が良くて、同じpathでもdeleteされた前と後では別物として扱っているのだと思います。
どうにかして、svn logでpathを指定した場合、途中でdeleteが行われ同じファイル名のファイルがaddされていたも、そのpathの全ての履歴を表示する方法は無いでしょうか？
よろしくお願いいたします。
352:デフォルトの名無しさん
15/01/13 23:43:22.59 IQluUJw+.net
logは履歴を見るもんなんだが。
履歴がつながってないから全く別のファイル。
どうしてもそれしたければ
delete直前のリビジョンからコピーしてきて新しい内容で上書き&コミット。
353:デフォルトの名無しさん
15/01/14 01:34:24.48 PZtFq0gG.net
>>346
svn log -v --search path
354:デフォルトの名無しさん
15/01/19 10:22:10.09 a1hSaFg4.net
trunk
AAAA
BBBB
CCCC
DDDD
↓
trunk
DDDD
EEEE (新規に追加)
AAAA
BBBB
CCCC
TortoiseSVNで上のような移動をしたいのだけど、
これをやったあとにEEEEフォルダのログを見たとき、
AAAAやBBBBなどのこれまでのログも出てくるようにできますか？
355:デフォルトの名無しさん
15/01/19 13:29:01.96 KroxEeJe.net
1)
trunk
AAAA
BBBB
CCCC
DDDD
EEEE 追加
2)
trunk
DDDD
EEEE
AAAA 移動
BBBB 移動
CCCC 移動
手順踏めば大丈夫
356:デフォルトの名無しさん
15/01/19 13:40:20.78 a1hSaFg4.net
>>350
その方法でやってみたのですが、EEEEフォルダのログには、
EEEEフォルダ追加からのログしか出てこないのです。
trunkフォルダのログや、AAAAフォルダのログには、
EEEEフォルダ追加以前のものもすべて出てきます。
357:デフォルトの名無しさん
15/01/19 13:44:36.31 KroxEeJe.net
コミットを分けた？
358:デフォルトの名無しさん
15/01/19 13:56:35.50 a1hSaFg4.net
リポジトリブラウザ上でテストしたので、
操作ごとにコミットされているかと思います。
ログは以下のようになっています。
リビジョン2
/trunk/AAAA 追加
リビジョン3
/trunk/BBBB 追加
リビジョン4
/trunk/CCCC 追加
リビジョン5
/trunk/DDDD 追加
リビジョン6
/trunk/EEEE 追加
リビジョン7
/trunk/AAAA 削除
/trunk/BBBB 削除
/trunk/CCCC 削除
/trunk/EEEE AAAA 追加 (コピー元 /trunk/AAAA 6)
/trunk/EEEE BBBB 追加 (コピー元 /trunk/BBBB 6)
/trunk/EEEE CCCC 追加 (コピー元 /trunk/CCCC 6)
359:デフォルトの名無しさん
15/01/19 22:15:29.08 zfzVZ1X7.net
だってそりゃEEEEにはリビジョン6より前の歴史なんてないじゃん。
とか。
360:デフォルトの名無しさん
15/01/20 04:38:09.76 37je+qde.net
俺もこの場合はログが出ないものだと思っていたが、出せるなら知りたい
361:デフォルトの名無しさん
15/01/20 10:48:22.12 tMuEMnZJ.net
>>354-355
フォルダに対するログの表示は、
「フォルダ以下にあるすべてのアイテムのログ」ではなく、
「フォルダそのもののログ」ということなんですか。
フォルダを移動しないうちは同じように見えるけど、
移動してしまうと表示の違いが出てくると。
前者のほうがしっくり来るのですが、こういう表示はできないのですかね。
362:デフォルトの名無しさん
15/01/30 23:58:00.81 6DjaTlPF.net
2014年2Qにリリース予定だった1.9の進捗状況はいかがでしょうか。
363:デフォルトの名無しさん
15/02/16 20:57:30.37 T+HM2fDz.net
どなたか詳しい方、コメントいただきたく。もうワケが分からない…
windows7のPCをSubversionのサーバーとして使っています。
半年くらい前にpost-commitフックで、cmailを使ってコミット内容をメール通知するようにしました。
先日、サーバーを再起動した途端にコミット完了するのが異様に遅くなり、原因を調べてみるとcmailでメール送信する所で2分くらいダンマリしている事がわかりました。(この間、cmailプロセスのCPU使用率は0%表示。最終的にはメール送信成功する)
同じメール内容をサーバーのコマンドプロンプトから送信すると、一瞬で完了します。
どうアプローチしていいのか分からず完全にお手上げ状態です。誰かお助け下さい。
364:デフォルトの名無しさん
15/02/17 00:20:17.66 WOLXU8Lo.net
cmailでのメール送信だけやってみて様子を見るとか。
なんとなく名前解決関連な気もするけどわからん。