X
Subversion r15
■ このスレッドは過去ログ倉庫に格納されています
0002デフォルトの名無しさん
垢版 |
2014/08/02(土) 17:21:57.75ID:Pbzuc8Bb
前スレ
r14 http://peace.2ch.net/test/read.cgi/tech/1326806859/
r13 http://toro.2ch.net/test/read.cgi/tech/1286654542/
r12 http://hibari.2ch.net/test/read.cgi/tech/1254838551/
r11 http://pc12.2ch.net/test/read.cgi/tech/1230488758/
r10 http://pc11.2ch.net/test/read.cgi/tech/1215565366/
r9 http://pc11.2ch.net/test/read.cgi/tech/1202086238/
r8 http://pc11.2ch.net/test/read.cgi/tech/1192864879/
r7 http://pc11.2ch.net/test/read.cgi/tech/1180858500/
06 http://pc11.2ch.net/test/read.cgi/tech/1165892754/
05 http://pc8.2ch.net/test/read.cgi/tech/1145841405/
04 http://pc8.2ch.net/test/read.cgi/tech/1129642894/
03 http://pc8.2ch.net/test/read.cgi/linux/1100622362/
02 http://pc5.2ch.net/test/read.cgi/linux/1078609142/
01 http://pc.2ch.net/test/read.cgi/linux/1002355536/
0003デフォルトの名無しさん
垢版 |
2014/08/02(土) 17:22:45.55ID:Pbzuc8Bb
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/
0004デフォルトの名無しさん
垢版 |
2014/08/02(土) 17:23:32.96ID:Pbzuc8Bb
◆関連スレ
バージョン管理システムについて語るスレ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/
0005デフォルトの名無しさん
垢版 |
2014/08/02(土) 17:26:54.04ID:Pbzuc8Bb
■記事(最近)
「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
0009デフォルトの名無しさん
垢版 |
2014/08/02(土) 20:12:35.61ID:0kTV0vzL
グロ
0010デフォルトの名無しさん
垢版 |
2014/08/03(日) 00:10:47.82ID:oEZJtdrX
subvertionから移行しやすいのは、gitでなくhg
0011デフォルトの名無しさん
垢版 |
2014/08/03(日) 00:15:01.01ID:g3w/WXUa
その前にsubvertionて何ですのん
0015デフォルトの名無しさん
垢版 |
2014/08/03(日) 12:30:11.92ID:tNPEJw6R
subversion は良くも悪くも普通のバージョン管理ツールだけど
git って、パッチ管理（リモート、ローカル）＆マージ処理に特化したのが勝因だよなー

Linusとしては自分に必要な、Linuxのパッチ適用に必要な機能だけ
あればよいって言う考えでgitを設計したんだろうけど。
0016デフォルトの名無しさん
垢版 |
2014/08/03(日) 12:43:18.82ID:vDYlVj70
subversionはソースコードを管理するツール
gitは機能単位でコミットを作るための開発ツール
0017デフォルトの名無しさん
垢版 |
2014/08/03(日) 13:24:33.93ID:hQ3yR5lB
フツーの業務システム開発ならsvnのtrunk一本でそれほど困らんけどね
複数人で同じソースをいじくりまわしてマージが大変なんてことは無いし
0018デフォルトの名無しさん
垢版 |
2014/08/03(日) 13:33:31.75ID:m8NxcudO
>>17
ぼっち開発者の俺はtrunkだけでほぼいける。
以前のバージョンに戻すこともめったにない。

ビルド出来ないとか、動作が不完全のような中途状態で取っておきたいときに
ブランチを作って、ＯＫになったらtrunkへマージする。
このブランチ側の作業を、ローカルリポジトリか何かで自動化できるとうれしい。
gitのリモート/ローカルってそういうものなんだろーなーと指を加えて見てる。
0020デフォルトの名無しさん
垢版 |
2014/08/03(日) 13:47:16.84ID:EYCCS+tk
>>19
ぼっち開発ならそのまま trunk 上で開発もありだろ
どうしても途中で元のバージョンに修正入れたいなら、その時ブランチ切ればいいんだし
0022デフォルトの名無しさん
垢版 |
2014/08/03(日) 22:51:10.95ID:vDYlVj70
>>21
コミットの考え方が違うね。
svnは単なる作業履歴って感じだけど、
gitはコミットを一つ一つに意味があって
大事にしている。
0023デフォルトの名無しさん
垢版 |
2014/08/04(月) 00:09:08.40ID:Q4DpUAES
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以降は、日本語の記事も極端に減った感じがする
0025デフォルトの名無しさん
垢版 |
2014/08/04(月) 13:57:04.00ID:c5xHxkCU
多いというか、整理されていないというか
かといって無いと不便というか
慣れるしかないというか
0026デフォルトの名無しさん
垢版 |
2014/08/04(月) 14:03:00.85ID:XttId4/U
新しく始めるときはgit使うようにしてるけど、慣れたらsvn使うの面倒くさく感じるようになってきた。
0028デフォルトの名無しさん
垢版 |
2014/08/04(月) 18:15:01.48ID:Ov9EQrbF
>>20
その運用するなら「元のバージョン」として扱うだろうと考えられるリビジョンでタグ打っときなよ
0029デフォルトの名無しさん
垢版 |
2014/08/04(月) 20:40:49.84ID:UAhHAw7M
>>25
> 整理されていないというか

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

>>28
ぼっち開発だとログもたいしたことないし...
まあ、リリース毎には外部バージョンでタグ打つけどね
0031デフォルトの名無しさん
垢版 |
2014/08/04(月) 22:53:31.39ID:gDpcXLgO
guro
0032デフォルトの名無しさん
垢版 |
2014/08/04(月) 22:58:50.77ID:O7gnQe0p
一人でやってると、コミットの扱いが雑にならね？

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

で、コミットメッセージに○○の修正って書いてるのに、
無関係の修正が含まれてたり。
0034デフォルトの名無しさん
垢版 |
2014/08/05(火) 03:20:24.50ID:YIevQOQe
狭く深くか、広く浅くかで分けて
広く浅い方は「後で絶対に戻さない」という信念を持ってコミットする
0035デフォルトの名無しさん
垢版 |
2014/08/06(水) 23:28:00.45ID:Rv/16L6Z
> 広く浅い方は「後で絶対に戻さない」という信念を持ってコミットする

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

人間である以上、漏れっていうのは絶対にある。
こんな些細な事はあとから修正すればいい話でgitならそれができる。
0036デフォルトの名無しさん
垢版 |
2014/08/07(木) 19:51:06.05ID:2eVL32He
単に数日前に戻りたいだけとか、コミットにいちいち信念なんてうぜーとかなら、
別にわざわざscm使う必要なくね?
そういうやつはどうせコミットメッセージなんてロクにつけないんだろ?
このスレでいうのもなんだが、そういう使い方しかしないんなら、
nilfs2などのログファイルシステム使っとけば十分な気がするが。
webdavなクラウドストレージでもいいし。
無理してscm使う必要ないと思うけど。
0037デフォルトの名無しさん
垢版 |
2014/08/07(木) 21:58:12.49ID:KOv3T7TP
コミットの内容に気を使うか、
単なるバックアップとして使うかの
違いだよね。

バックアップとしてしか使ってない人は
ソースコードを管理しているわけじゃないというだけのこと。
0039デフォルトの名無しさん
垢版 |
2014/08/08(金) 02:38:38.23ID:pWDxpd5M
差分確認したいから使うわけだが
0040デフォルトの名無しさん
垢版 |
2014/08/08(金) 02:54:36.69ID:9Z/dDvz0
その差分が、一日とかの時間単位の差分なのか
コミット＝機能 単位の差分なのかで意味が違ってくるけどな。

しっかりコミットには機能を含ませないとダメだよ。
○機能のコミット、間を空けて、○機能のバグ修正とか
機能が複数のコミットに分断されたりすると、差分調べづらいからさ。
0041デフォルトの名無しさん
垢版 |
2014/08/08(金) 10:14:49.47ID:U3aQnjb8
>>40
一機能が数十ファイルに渡る数千行の変更になることが普通だから、機能毎のcommitは粒度が大きすぎる。
0042デフォルトの名無しさん
垢版 |
2014/08/08(金) 23:37:02.98ID:7OE7NDSB
粒度が小さくしようと思えば、
コミットの回数は必然的に多くなると思うけど、
そうすると大変にならね？

ちょっとしたミスでもしないように
心がけないといけないから、テストに時間が掛かる。
0043デフォルトの名無しさん
垢版 |
2014/08/09(土) 15:03:48.49ID:tAcYV70i
>>42
昔、１つの障害直すのに機能修正用に一回コミットして、
その後ソースのインデント変更でもう一回コミットとかした事がある。

確かに細かくコミットした方が後で見るときに分かりやすいというのはある。
0045デフォルトの名無しさん
垢版 |
2014/08/10(日) 18:07:16.07ID:on/xxl87
>>40
ブランチ作ればいいんでないのと思うんだけど、それではだめなのかな。

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

>>43
気持ちは分かるんだけど、インデントに関してのみいえばdiffのオプションで
インデント変更を無視することができるので、分けなくても大丈夫。
むしろ、特定リビジョンにおいてインデントが崩れている状態を生み出したというのは
個人的にはあまりよろしくないと思う。
0047デフォルトの名無しさん
垢版 |
2014/08/12(火) 18:02:50.52ID:v1nubPFA
>>45
> 粒度を小さくするってことは、固まったところからコミットしていくということなので
> 特にテストの手間は増えないよ。

固まった所からコミットするってどうやるの？
ファイルの一部分だけコミットとか出来ないよね？
0048デフォルトの名無しさん
垢版 |
2014/08/12(火) 18:08:45.21ID:v1nubPFA
あと固まった所からコミットというのは
作業が直列化してるんだよね。


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

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

そういうときサブ処理Aのコミットを
修正できないのはキツイよね。
0049デフォルトの名無しさん
垢版 |
2014/08/12(火) 18:22:27.64ID:DPsvz0Xi
>>48
> そういうときサブ処理Aのコミットを
> 修正できないのはキツイよね。

言ってる意味がわからないんだが・・・。
BあるいはCをきりのいいところでcommitして、Aを修正すればいいのでは・・・。
0052デフォルトの名無しさん
垢版 |
2014/08/12(火) 22:20:13.12ID:v1nubPFA
>>51
意味を考えたことある？

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

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

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

コミットの内容を小さくすればするほど、無駄なコミットはなくそうと
考えるのが普通では無いかな？
0053デフォルトの名無しさん
垢版 |
2014/08/12(火) 22:42:52.85ID:9cOXUK+K
>>52
確かにバグ修正のコミットは結果的に言えば無駄だね。
じゃあ、いつコミットできるの？
バグが一切存在しないコードを書けるクヌース先生みたいな人なのかな。
0054デフォルトの名無しさん
垢版 |
2014/08/12(火) 22:49:43.95ID:lQ8v3e0D
>>52
詭弁だね。
gitでもローカルではこまめにコミットするよ。
gitでは、みんな整えてからサーバーにプッシュしてくれるから、機能単位になるけどね。
SVNでそれは出来ないし、現状そういう使い方には向かない。

>>53
最も過ぎて感動した。
0056デフォルトの名無しさん
垢版 |
2014/08/12(火) 23:50:23.60ID:9cOXUK+K
>>55
そうだね。むやみに細かなコミットはするべきじゃないよ。
それと、固まったところを切り出してコミットをするのをやめろって話とは矛盾しない。

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

分けるべきことと分けてはいけないことを把握できてるなら、たぶん考えてることは同じだと思う。
0058デフォルトの名無しさん
垢版 |
2014/08/12(火) 23:52:57.40ID:+KZZ7y/Q
なんかこう、>52は根本的なところでVCSを理解できていないか
それとも何かの教条主義に陥っているのか。
いずれにしても、tagやコミットログを使いこなせていないのだろう。
0059デフォルトの名無しさん
垢版 |
2014/08/13(水) 00:05:50.29ID:sMkXwa1N
経験則でいうと、手当たり次第に手をつけながら改修を行うような人にはVCSは向かないと思う。
それはひとえにコミット単位が大きくなりすぎるからという理由。
この手の人は大抵コンフリクトに頭を抱え、VCSに対して文句を言う羽目になってる。

時がたち、コミット単位をうまくまとめられるようになったころには、
手当たり次第に改修するというスタイルは矯正されてると思う。
0060デフォルトの名無しさん
垢版 |
2014/08/13(水) 00:07:16.21ID:NDCsqVwr
そもそもツールに問題があるとは考えないのか？

gitではできるが
subversionではできないんだよ。
0061デフォルトの名無しさん
垢版 |
2014/08/13(水) 00:09:19.27ID:NDCsqVwr
>>59
> 経験則でいうと、手当たり次第に手をつけながら改修を行うような人にはVCSは向かないと思う。

それは違うな。

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

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

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

subversionというツールに問題があるんですよ。
006253=59
垢版 |
2014/08/13(水) 00:11:57.89ID:sMkXwa1N
だめだこりゃ。
0063デフォルトの名無しさん
垢版 |
2014/08/13(水) 00:13:50.98ID:BorG/OEI
個人的には、意味のある単位であれば、コミットは細い程良いと思ってる。
その、程々の粒度のコミット単位を見つけられるかが経験なのかもしれないけどね。
俺も経験上の話をすると、でかいコミットをカマス奴は信用できないヤツが多い。
しかも、不具合やリファクタリングを指摘しても、何だかんだで直してくれない。
(その理由の一つが、履歴が汚れるからとか、おかしいだろ…)
0065デフォルトの名無しさん
垢版 |
2014/08/13(水) 08:16:22.09ID:O9MT/Amg
>>63
あるある
所詮開発ツールのログにすぎないのに、そのログの保守が目的になっちゃう人
極端に偏るのはウザいし、業務遂行の妨げだよね～
程々でいいんだよ、何事もバランスが大切
0067デフォルトの名無しさん
垢版 |
2014/08/13(水) 10:50:51.37ID:jXoiUBxz
>>56
> 逆に>>48でいうところの3つのサブ処理が互いに疎ではないのであれば、Aのみをコミットするのはどうかと思う。
つか、互いに疎になるように分割しないと駄目なのでは？
0069デフォルトの名無しさん
垢版 |
2014/08/13(水) 11:45:42.27ID:jXoiUBxz
まあ、「ある機能」の規模感が人によってさまざまで、だから意見が食い違ってる気がする。
俺の場合は、「機能」で分割した場合、コードの行数は500～3000行くらいで、500行の場合でも
クラスを3つ、メソッドそれぞれ10～30行とかで、メソッド一つ～数個ごとにコミットする感じ。
0070デフォルトの名無しさん
垢版 |
2014/08/14(木) 01:01:10.16ID:pDOsDmj5
1.9　って、ＤＢ機能の強化がメインなのか？

バックグランドの機能強化とか誰得なんだ？
0073デフォルトの名無しさん
垢版 |
2014/08/14(木) 11:27:09.25ID:vzBa7P/6
大規模CI環境になるとsvnが性能ネックになりうるので
バックエンドの強化は地味ながら効果的
0074デフォルトの名無しさん
垢版 |
2014/08/15(金) 18:15:50.03ID:NhRsvWgL
データベースを強化しないと機能追加が難しい。急がば回れ。
OSS関係はgitが主流になったんで開発を急ぐ必要も無いから
0076デフォルトの名無しさん
垢版 |
2014/08/16(土) 15:33:06.06ID:HaTedOVs
ぐろ
0078デフォルトの名無しさん
垢版 |
2014/08/18(月) 21:10:12.16ID:qllk6aou
>>77
subversionにもメリットがあって、
gitとsubversionのどちらがいいか戦ってるって
話かと思ったら、

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

タイトルの訳間違ってるだろｗｗｗ
0079デフォルトの名無しさん
垢版 |
2014/08/18(月) 21:38:25.14ID:XfPgTp0v
みんなそんなにSVNに困ってるの？
0080デフォルトの名無しさん
垢版 |
2014/08/18(月) 21:44:14.15ID:RwGMDQAu
gitに移行した方がいいプロジェクトも確かにあるけど、
プログラマー以外の職種が多い場合や、
巨大なデータを扱うのがメインだと難しいね
0081デフォルトの名無しさん
垢版 |
2014/08/18(月) 23:28:18.45ID:5QD9Cwn1
>>77
すでにコメントで指摘されてるけど、下二つのグラフが同じだな
おぼちゃんじゃないけど、こういうミスがある記事はあまり信頼できない
0082デフォルトの名無しさん
垢版 |
2014/08/18(月) 23:59:55.48ID:KXo4EPQU
適材適所という言葉が奴らの辞書には載ってないんだよ
0083デフォルトの名無しさん
垢版 |
2014/08/19(火) 01:07:57.99ID:hZ1y1Bcl
適材適所？ 中央リポジトリには
subversionが適してると思ってる？

残念。中央リポジトリにしか使えないんだよ。
rebaseできないからな。
0084デフォルトの名無しさん
垢版 |
2014/08/19(火) 01:10:04.56ID:hZ1y1Bcl
>>79
うん。困りまくり。

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

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

こんなの使えないよ。
0087デフォルトの名無しさん
垢版 |
2014/08/19(火) 11:28:17.07ID:tg7i16ue
>>86
> できることは多いほうがいいよ？

多機能家電に憧れちゃう人？ w
git はもう少し機能を整理した方がいいと思う。
0089デフォルトの名無しさん
垢版 |
2014/08/19(火) 20:56:55.78ID:NEeA6T8i
gitはログ追うのも難儀するからな
0090デフォルトの名無しさん
垢版 |
2014/08/19(火) 20:57:40.71ID:NEeA6T8i
NEATe68i
0091デフォルトの名無しさん
垢版 |
2014/08/19(火) 21:34:51.65ID:wZ/va0+J
>>88
VCSにrebaseを求めない人がいるのが信じられないんだけど。
だって普通開発してたらケアレスミスするじゃん？
コミットした後で気づくってよくある話だと思うけど。
ケアレスミスじゃなくても単にバグとかさ。
0092デフォルトの名無しさん
垢版 |
2014/08/19(火) 21:46:10.76ID:mxmpwOEU
そんなのは普通に直して普通にコミットすればよろしい。
rebeaseだのはVCS的には邪道。
うっかりだろうとケアレスミスだろうと、それすらも履歴として残すことに
本来的な意味がある。
0093デフォルトの名無しさん
垢版 |
2014/08/19(火) 21:59:43.08ID:wZ/va0+J
わからないな。
ミスさえしなければ、本来できるはずがなかったコミットを
残す理由って何よ？
0094デフォルトの名無しさん
垢版 |
2014/08/19(火) 22:08:41.41ID:mxmpwOEU
もちろん単なる履歴だ。それ以外に特別な意味はない。
すべてのコミットが単なる履歴なのだから、強いて言えば「こんな馬鹿な奴が
いました。次のプロジェクトからは外した方がいいですよ～」という証拠でもある。
0096デフォルトの名無しさん
垢版 |
2014/08/19(火) 22:15:43.48ID:wZ/va0+J
コミットの価値を理解しないとダメだよ。

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

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

意味のある単位をむやみに分割したりとか
複数の単位をまとめてしまったら、コミットが使えなくなる。
0097デフォルトの名無しさん
垢版 |
2014/08/19(火) 22:17:29.06ID:hIkjmM2M
rebase出来るということは潜在的に「履歴を間違えて消してしまう」リスクを背負う事になっちゃうからね。
ま、ローカルでのrebaseであれば作業者の責任範囲なのでウェルカムこの上ないんだけど。

人間だから、コードにバグ入れるのも当たり前、コミットミスするのも当たり前、同様にrebaseミスするのも当たり前だということ。
この中で一番ミスった時のリスクが高いのがrebaseなので、不要と考える人の気持ちもわかる。
0099デフォルトの名無しさん
垢版 |
2014/08/19(火) 22:35:26.02ID:hIkjmM2M
もちろんすぐに気付けばreflogとかでやり直せばいいと思うし、ローカルでやってくれる分には別に気にしないよ。
共有リポジトリに対してやられたりして、更に何らかのミスていることに気づかないで放置されると後々面倒だなーと。
人のコミットまでrebaseできちゃうわけだし。
0100デフォルトの名無しさん
垢版 |
2014/08/19(火) 22:38:27.65ID:hIkjmM2M
勿論欲しい事は欲しいんだけど、集中型のsvnには、「まだ」時期尚早な機能じゃね？
0101デフォルトの名無しさん
垢版 |
2014/08/19(火) 22:40:19.87ID:mxmpwOEU
やっとわかった。自分勝手な基準で「意味のあるコミット」だとか
「意味のないコミット」だとか、そういうものが存在するという幻想を
抱いてるレベルなのか…
できればVCSを使わないで欲しいな、そんな奴には…

逆なんだよ、「コミットする事に意味がある」んだって分かって欲しいね。
0102デフォルトの名無しさん
垢版 |
2014/08/19(火) 22:43:40.49ID:wZ/va0+J
>>99
> 人のコミットまでrebaseできちゃうわけだし。

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

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

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

そもそもローカルにある自分のコミットがオリジナルで
そっちは無事なので何の問題もないけど。
0104デフォルトの名無しさん
垢版 |
2014/08/19(火) 22:45:12.28ID:wZ/va0+J
目的と手段が入れ替わってるんだろうな。
コミットすることが目的になっちゃってる。

コミットを使わないと
何の意味もないのに。
0105デフォルトの名無しさん
垢版 |
2014/08/19(火) 22:48:07.47ID:hIkjmM2M
>>101
直線履歴が基本のsvnだと確かに全ての作業ログを残して欲しくなるね。
でも、ブランチと機能コミットが基本の分散型だと、すごーく履歴がカオスになるので、rebaseで直線化して欲しくなる気持ちもわかるよ。
0106デフォルトの名無しさん
垢版 |
2014/08/19(火) 22:50:06.96ID:wZ/va0+J
あぁ、作業ログ。そうかsubversionは
単なる作業ログなんだ。

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

そうか単なる作業ログか。
0108デフォルトの名無しさん
垢版 |
2014/08/19(火) 22:54:40.94ID:hIkjmM2M
>>106
アオリたいだけなら、俺はもう引っ込むね。
そんなやり合いには何の実もないから。
適材適所なんだから、そういう突っかかり方するのもどうかと思うよ。
0109デフォルトの名無しさん
垢版 |
2014/08/19(火) 22:54:49.52ID:wZ/va0+J
>>107
あるけどそれが？

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

git使ってから、ツールが悪かったんだなって
わかった。
0110デフォルトの名無しさん
垢版 |
2014/08/19(火) 22:56:33.30ID:wZ/va0+J
>>108
だって作業ログなんでしょ？

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

言いたいことがあるのなら言い返せばいいのに
それもできないでいるしさ。
0111デフォルトの名無しさん
垢版 |
2014/08/19(火) 22:58:42.34ID:wZ/va0+J
社内の仕事だったら、適当な作業ログでいいかもしれないけどさ、
これが赤の他人に提出するパッチだったら
コードはちゃんとレビューできるようになってないとダメだよ。
赤の他人のコードなんて信用出来ない。

コミットがきちんと理解できるように
意味のある単位に分かれていなければ、
受け取ってもらえない。
0112デフォルトの名無しさん
垢版 |
2014/08/19(火) 23:07:57.10ID:hIkjmM2M
>>111
何だ、適材適所という事をわかってるじゃないか。
それなのに何でそこまで君の正義を主張したがる？

君の言うことは正しい。
でもそれが全てじゃない。
0114デフォルトの名無しさん
垢版 |
2014/08/20(水) 00:00:03.80ID:f3yS32aL
バカには無理
0115デフォルトの名無しさん
垢版 |
2014/08/20(水) 00:53:26.19ID:a44PmGri
>>77
>>81
読んだ感じでは、俺が感じていたのと殆ど同じなので、違和感が無い。

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

SVNに関する需要が0になる事は無いと思うからどこかで、下げ止まると思うけど
0116デフォルトの名無しさん
垢版 |
2014/08/20(水) 02:20:29.54ID:tVPQaqWC
svnを使う理由は「今更やめられない」か
「新しいものを覚えたくない」だけになりそうだね。
0117デフォルトの名無しさん
垢版 |
2014/08/20(水) 02:23:43.02ID:tVPQaqWC
機能で言えばgit > svnなんだよな

gitはsvnの代わりに使えるが、
svnはgitの代わりにはならない。
0118デフォルトの名無しさん
垢版 |
2014/08/20(水) 03:17:17.30ID:f3yS32aL
svnは一部のcoできるけどgitは・・
0119デフォルトの名無しさん
垢版 |
2014/08/20(水) 03:34:47.62ID:ZA48Lhll
svnはコミット単体でが何というブランチになされたものかわかるけど、gitは…
0121デフォルトの名無しさん
垢版 |
2014/08/20(水) 07:44:27.64ID:VDbLT/q5
一部coは明らかに有用。
0122デフォルトの名無しさん
垢版 |
2014/08/20(水) 08:18:04.87ID:f3yS32aL
巨大プロジェクト全体のcloneなんて無駄なことしたくないからね
0123デフォルトの名無しさん
垢版 |
2014/08/20(水) 08:28:54.10ID:ywmZeMUB
gitがoss向きなのは明らかだね。
自然集約と自然淘汰を本質とするossの性質に良くマッチしている。
一方、統制を基本とする企業という枠組みの中では必ずしもマッチするものではないと思う。
ただ、企業と言ってもこれまた多種多様で、ソフトウェア実装専門であればgitが適していると思う。
gitは良くも悪くもテキストに特化したツールだから、他の文書や成果物を合わせて管理するには向いていない。
0124デフォルトの名無しさん
垢版 |
2014/08/20(水) 08:30:54.38ID:Dj5PYAlQ
ソースコードだけ対象で、計画的な開発体制が出来てるならgitの方がいいと思う
そうでない場合、subversionがいい場合もある
0125デフォルトの名無しさん
垢版 |
2014/08/21(木) 02:22:10.31ID:W/oig19k
>>122
巨大プロジェクトってたとえばどんなの？

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

だめだよ。プロジェクトごとに
リポジトリは分けなきゃ。
0127デフォルトの名無しさん
垢版 |
2014/08/21(木) 02:39:29.35ID:W/oig19k
ん？ またソースコードを管理するから
ソースコード管理ツールに
データ入れてるって話？
0131デフォルトの名無しさん
垢版 |
2014/08/21(木) 10:18:28.92ID:7zFpfveR
>>125のように頭の悪い奴が支持してるのがgit
0135デフォルトの名無しさん
垢版 |
2014/08/21(木) 22:13:47.40ID:xeZNqCr5
おれも問題はそこだと思う。

実行ファイルにコンパイルされるソース一式と仮定すると、
たとえばひとつの実行ファイルだけで完結してしまって、
他の実行ファイルとの関係など全くないような
小さなモノしか扱ったことのないやつにとっては、きっと
(実行ファイル) = (プロジェクト) = (リポジトリ)
という頭しかないんだろ。
0136デフォルトの名無しさん
垢版 |
2014/08/21(木) 22:37:19.35ID:W/oig19k
>>134
> 「プロジェクト」の定義は？
プロジェクトっていうか
プロダクトかな。

プログラマなら疎結合にする重要性は知っていると思うが、
プロジェクト定義は別々にリリースしても問題ない単位でいいんじゃないかな
または別々のバージョン番号をつけている単位でもいいかも
ようするに商品として独立していること。
0137デフォルトの名無しさん
垢版 |
2014/08/21(木) 22:40:07.04ID:W/oig19k
>>135
プロジェクトには複数の実行ファイルがあるわけだけど、、
当たり前だけど、それでも全部を一つのリポジトリに入れたらダメだよね。
無関係のものもあるわけだし。

プロジェクトごとにリポジトリを分ける。
一つのプロジェクト（リポジトリ）には複数の実行ファイルが入ってる。
これが理想だろうね。
0139デフォルトの名無しさん
垢版 |
2014/08/21(木) 22:47:31.02ID:W/oig19k
全部一つにまとめると。一部だけ移動したりする時とかに
使いにくくなるんだよな。

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

（使いにくいから）一つのプロジェクトに
まとめるなという話をしてる。
0141デフォルトの名無しさん
垢版 |
2014/08/21(木) 23:34:08.49ID:xeZNqCr5
>>137
関連する実行ファイルのソースはすべてひとつのリポジトリに揃ってないと、
各実行ファイル間の関係を追跡できなくなってしまう。
プロジェクトが「プロダクト(製品)」の意味ととらえても、
おれのところではひとつの製品の中に無関係のものなんてないし、
ひとつのソース一式が複数の製品で利用されてたりもするから、
それらが全部同じリポジトリにないと管理ができなくなる。

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

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

結局、おれのところでは基本的にライセンスや使用許諾条件によってリポジトリを分けてるかな。
異なるライセンスのソースが同じリポジトリにあっちゃマズイから。
0142デフォルトの名無しさん
垢版 |
2014/08/21(木) 23:59:09.62ID:W/oig19k
関連する実行ファイルのソースはすべてひとつのリポジトリに揃ってないと、
各実行ファイル間の関係を追跡できなくなってしまう。

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

これ以上の話はする必要がないとおもう
0143デフォルトの名無しさん
垢版 |
2014/08/22(金) 09:02:34.71ID:vd34DDnl
急に禅問答になった。
0144デフォルトの名無しさん
垢版 |
2014/08/22(金) 13:37:43.59ID:p2QF+4Sq
リポジトリは分けた上で、リビジョン指定のsvn:externalsで関連付けたらいいのでは
0145デフォルトの名無しさん
垢版 |
2014/08/22(金) 14:14:15.25ID:mvEiVivf
やり方は沢山あって、それなりに一長一短ある。
> オレ様のやり方が一番良い。オレ様のやり方でやるべき。
と言い出すバカは死んでくれ。
0148デフォルトの名無しさん
垢版 |
2014/08/23(土) 00:43:59.83ID:UlvkZmqF
>>142
むやみにひとつのリポジトリで運用すべきではないという主張になってると思うんだけど、
当初はdump restoreが重過ぎるからひとつにするなといっていたよね。

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

ちなみにdump restoreの重さが気になる頻度でそれを行っているのなら、そこを改めるべきだと思う。
0149デフォルトの名無しさん
垢版 |
2014/08/23(土) 00:48:28.44ID:j4ngjv2t
開発元がひとつにまとめてる時点でないだろ
0151デフォルトの名無しさん
垢版 |
2014/08/23(土) 13:22:14.44ID:ONwlfWFe
パッケージ管理とバージョン管理の区別が付いてないと
悲惨なリポジトリになる
0153デフォルトの名無しさん
垢版 |
2014/08/23(土) 17:10:06.41ID:UlvkZmqF
>>150
独立したそれぞれの理由を書いてるけど、どれもこれも分けないことによって生まれるデメリットに相当しないんだもの。
0156デフォルトの名無しさん
垢版 |
2014/08/24(日) 00:45:17.64ID:cxV5Zamh
この流れは何度も繰り返されているけれど、そのたびに分けなくていいという結論になってない？
0157デフォルトの名無しさん
垢版 |
2014/08/24(日) 11:38:05.22ID:tjUQeC3v
>>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か月のサイクルで出したいとか言ってたけど、無理みたいだな。
0158デフォルトの名無しさん
垢版 |
2014/08/24(日) 12:46:27.42ID:04V5n05d
これぐらいの速度で出して欲しい

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リリース
0160デフォルトの名無しさん
垢版 |
2014/08/24(日) 16:17:32.62ID:1q09/hom
subversionにgit flowとかgithub flowみたいなのってある？
subversionを使ってどういうふうに運用するかを
決めた開発のフロー
0161デフォルトの名無しさん
垢版 |
2014/08/24(日) 16:22:50.54ID:1q09/hom
あとどういう時にブランチ切ってる？
バグ修正用のブランチとか切っていい？

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

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

要らなくなったブランチは削除していいよね？
ブランチは削除できるみたいだし。
0162デフォルトの名無しさん
垢版 |
2014/08/24(日) 17:05:10.65ID:cxV5Zamh
大抵のバグはブランチを作るほどじゃないなぁ。影響範囲も小さく、内容が明白であれば1コミットで済むでしょ。

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

要らなくなったブランチはどんどん削除。
0163デフォルトの名無しさん
垢版 |
2014/08/24(日) 18:53:31.85ID:1q09/hom
> 大抵のバグはブランチを作るほどじゃないなぁ。影響範囲も小さく、内容が明白であれば1コミットで済むでしょ。

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

並列で複数の作業が発生するわけだしコードレビューも必要。
0164デフォルトの名無しさん
垢版 |
2014/08/24(日) 19:49:07.75ID:9zqGicGe
>>163
> 一人でやっていればいいけど、複数人でやってると
> そうも行かないよね？

修正範囲が多岐に渡るでかい修正ならそうだけど、大抵の修正は一人でやってる範囲に収まるよ
でかい修正の時は修正方針決めた段階で関係者集めてレビューするから
0165デフォルトの名無しさん
垢版 |
2014/08/24(日) 23:27:54.67ID:1q09/hom
いや、書いたコードをレビューしないと、
修正方針通りでも、コードがダメな場合があるじゃないか
コピペされていたり、正しくない構造を指定たり。
0166デフォルトの名無しさん
垢版 |
2014/08/24(日) 23:29:50.41ID:1q09/hom
それに複数人でやるっていうのは、修正する人が一人かどうかじゃなくて、
平行して、別々の開発があるじゃないかって話。

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

そういう人が、それぞれtrunkにコミットしたらダメだろ？
だからブランチという機能があるんだが。
0168デフォルトの名無しさん
垢版 |
2014/08/25(月) 15:34:41.14ID:W/mMJDzT
>>166
> 一つのプロジェクトの新規機能Aを担当する人、
> 同Bを担当する人、同C担当する人、バグ1を修正する人、以下略って。
>
> そういう人が、それぞれtrunkにコミットしたらダメだろ？
ん？それって10人で開発する場合、最低10個のbranch切って各人がそれぞれのbranchで開発するってこと？
それ、いつtrunkにマージするの？
0170デフォルトの名無しさん
垢版 |
2014/08/25(月) 16:38:16.81ID:W/mMJDzT
>>169
> そりゃできた順（もしくはリリースする順）にマージだろ
で、、マージ後branchは消すの？
消さないと、1リリース毎に見ると数百のbranchが残るよね。
0171デフォルトの名無しさん
垢版 |
2014/08/25(月) 16:39:32.30ID:W/mMJDzT
それとも、マージ後trunkの変更点をbranchに取り込んで、各人はそのbranchで作業を続行するのかな？
それだと、branchの意味あんまなさそう・・・。
0173デフォルトの名無しさん
垢版 |
2014/08/25(月) 17:19:00.91ID:n6MYI6xH
そんなもんだろ。
subversionをバックアップとしてしか使ってない証拠。

まあ、普通はマージを日常的に使ってたら
subversionは使いづらくてしょうがないから
gitに移行するんだけどねｗ
0174デフォルトの名無しさん
垢版 |
2014/08/25(月) 17:38:32.48ID:uT4xDhJR
こりゃ面白い。急成長じゃないか。
明日にもgit叩きを始めそうな展開で胸が熱い。

>>161 ブランチどうやって切ればいいんですかね；；
>>163 トンチンカン
>>166 だからブランチという機能があるんだが。
0175デフォルトの名無しさん
垢版 |
2014/08/25(月) 17:44:56.29ID:Q6cKsmaN
>>174
> >>161 ブランチどうやって切ればいいんですかね；；

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

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

160 名前：デフォルトの名無しさん[sage] 投稿日：2014/08/24(日) 16:17:32.62 ID:1q09/hom
subversionにgit flowとかgithub flowみたいなのってある？
subversionを使ってどういうふうに運用するかを
決めた開発のフロー
0176デフォルトの名無しさん
垢版 |
2014/08/25(月) 17:46:57.39ID:uT4xDhJR
なんだ、じゃあどういうときに切るかはまだ分からないままか。
じゃあ >>162 のまま特に変える必要ないなぁ。
0178デフォルトの名無しさん
垢版 |
2014/08/25(月) 18:20:23.87ID:9I6muac3
>>176
一人開発で使ってるだけで、そういう高度なことは
やってないから知らない。って答えてもいいんですよ？
0179デフォルトの名無しさん
垢版 |
2014/08/25(月) 18:29:44.44ID:t3eJagh2
ID:W/mMJDzTはsubversion book読んで出直しなさい。
レベルが低過ぎて会話に追従出来てない。
0180デフォルトの名無しさん
垢版 |
2014/08/25(月) 18:36:43.65ID:dIutByqY
そう言えば俺svnでは一度もマージ使った事なかったな…
なんて事、trunk一本糞なオープンソースに関わりながら思い出した
0181デフォルトの名無しさん
垢版 |
2014/08/25(月) 18:51:31.79ID:fQ2cskxs
subversionの人にとってはsubversionは
バックアップツールなんだよ（笑）

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

> 内容（「BOOK」データベースより）
> この本は、Subversionというバックアップのためのソフトについて説明したものです。
> 内容（「MARC」データベースより）
>
> Windows上で使えるバックアップツール「Subversion」の基礎知識から
> 具体的な使い方までをわかりやすく解説。テキストファイルも画像ファイルも、
> ファイルもフォルダも、好きなときにバックアップできる!
0183デフォルトの名無しさん
垢版 |
2014/08/25(月) 20:33:53.30ID:uT4xDhJR
>>168
人単位でブランチは作らない。
>>166が一機能一人みたいな書き方してるからアレだけど、
新規機能が10個あって、それらのリリースタイミングが同一であることが明らかではない場合、
個別にブランチを作る。

>>170-171
複数バージョンを並行してメンテする場合、リリースブランチとして運用をするために残すこともある。
大抵は、リリース時にタグを打っておいて、必要ならタグからブランチを作成してメンテするけれど。
0184デフォルトの名無しさん
垢版 |
2014/08/25(月) 22:36:00.58ID:U7wi69h2
　　　　 |
　＼　　__　　／
　＿　（ｍ）　＿ﾋﾟｺｰﾝ
　　　　|ミ|
　／ 　.｀´　 ＼
　　 　∧＿∧ 　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　（・∀・∩＜そうだ！subversion の開発は、git を使ってやればいいんだ
　　　（つ　　丿 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　⊂＿ ノ
　　　 　（＿）
0185デフォルトの名無しさん
垢版 |
2014/08/25(月) 22:45:10.35ID:2hV0rF99
gitならば、gitならば問題ない
と言いたい人がいるようだけど、
どう問題ないのか是非聞かせていただきたい。
0186デフォルトの名無しさん
垢版 |
2014/08/25(月) 23:20:37.21ID:dIutByqY
>>160,161の質問でここまで紛糾する理由がワカランチン

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

俺もあるのか知りたい
0187デフォルトの名無しさん
垢版 |
2014/08/25(月) 23:30:46.07ID:GZsp8R0a
別にブランチを避ける文化もあるってことでいいのでは。
0189デフォルトの名無しさん
垢版 |
2014/08/26(火) 00:09:07.68ID:cOpcHFf6
>>186
>>160 で揉めてる訳じゃないでしょ
Subversion にはその手の機能はないと思う

ブランチ云々は宗教戦争ネタなので大抵揉める
0190デフォルトの名無しさん
垢版 |
2014/08/26(火) 00:13:06.12ID:wWUBoWT7
いや機能じゃないでしょ。。
0192デフォルトの名無しさん
垢版 |
2014/08/26(火) 00:58:42.64ID:VaQvEhwE
>>190
ああ、git flow で使うフローと言うか、お約束について聞いてたんだな
そう言う意味なら trunk/tag/branch も一つのお約束だから、あるって言えなくもないかな

>>191
まあ、git flow は運用フローの支援機能ではある
0194デフォルトの名無しさん
垢版 |
2014/08/26(火) 11:25:57.07ID:HxwOhsx5
>>192
> そう言う意味なら trunk/tag/branch も一つのお約束だから、あるって言えなくもないかな

trunk/tag/branchがある前提で、git flowのような運用をする方法がsvn界隈で確立されてるかって疑問だと思う。
そして、それは確立されていない。
0195デフォルトの名無しさん
垢版 |
2014/08/26(火) 12:32:08.23ID:naQUKVyS
>>194
> そして、それは確立されていない。

どういう基準で確立されてないと言えるんだ？
されていないと言い切るんだから、明確に答えられるよね？
0197デフォルトの名無しさん
垢版 |
2014/08/26(火) 13:04:39.81ID:HxwOhsx5
>>195
某かのbest practiceがあるなら、教えて欲しい。
確立されたbest practiceなら、多分それには名前が付いているはずで、ググれば少なくとも数千はヒットすると思われる。
そういうのある？
0198デフォルトの名無しさん
垢版 |
2014/08/26(火) 13:30:57.85ID:naQUKVyS
>>197
trunk/tag/branch を切ると言うのも運用だろ？
そして、各々にどんなものを入れるかを決めるのも運用だよね。
逆に言うと何ができてたら、best practice って言えるんだ？
0199デフォルトの名無しさん
垢版 |
2014/08/26(火) 14:53:02.80ID:03rKZRQN
git flowってさ、trunk,brances,tagsっていうお約束より更に一つ上の層のお話だとボク思うんだ
0200デフォルトの名無しさん
垢版 |
2014/08/26(火) 15:07:10.76ID:HxwOhsx5
>>198
いやだからgit-flowとかGitHub Flowのようなものがsvnにはあるの？って話なんだけど。

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

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

まぁ大体の所はオレオレ運用じゃないのかなぁと思ってるんだけど。
ちなみにうちは、Redmineの1チケットがtrunkへの1コミットとなるよう、必要ならbranch切れ、くらいで運用してる。
0201デフォルトの名無しさん
垢版 |
2014/08/26(火) 15:10:21.15ID:dFxdDibp
ベストプラクティスに名前をつけるという行為はさほど一般的じゃないと思うけど、
どのベストプラクティスがベストなんだ？という面倒なことを避けるために名前をつけるのはひとつの方法なのかなぁ。

大抵みんなやり方が同じようになってきてるから、こういうときどうすればいいのって聞けばいいんじゃないかな。
0202デフォルトの名無しさん
垢版 |
2014/08/26(火) 15:53:13.50ID:HxwOhsx5
>>201
> 大抵みんなやり方が同じようになってきてるから、

そうなの？
新機能の実装をtrunkでがんがんやる派とそうじゃない派で、まず大きく二つに分かれる気がするけど。
0203デフォルトの名無しさん
垢版 |
2014/08/26(火) 17:28:20.40ID:NSwC5k+Z
俺は1本のままで保守モード移行と同時にそこまでの履歴丸ごとコピーで別リポジトリに追い出してた@decade ago
1.x/trunk---t-2.x/trunk---t-3.x/trunk---t-4.x/trunk---
　　　　　　　　L-1.x　　　　　　L-2.x
0205デフォルトの名無しさん
垢版 |
2014/08/26(火) 18:53:32.91ID:IPwBXJgH
trunkで開発すすめて特定の所からリリースブランチ作るって
やり方もあるよね。
0207デフォルトの名無しさん
垢版 |
2014/08/26(火) 22:42:03.56ID:dFxdDibp
>>206
ベストプラクティスの意味が分からないって言ってるんだろうか。
> 運用をより具体的に決めてるだけとも言える。
0208デフォルトの名無しさん
垢版 |
2014/08/26(火) 22:47:19.91ID:0QshLCvc
ベストベストって開発規模やコミット粒度によって何がベストかは違うだろ
統一見解なんて求めるのは無意味
0210デフォルトの名無しさん
垢版 |
2014/08/26(火) 22:55:05.25ID:naQUKVyS
>>208
いや、それを言い出したらきりがない。
六割とか八割の人が便利に使えるならそれはそれで ベストプラクティス でいいと思うよ。
ただ、ベストプラクティスはこれしか認めんとか言い出したら、それはおかしいよね。
0211デフォルトの名無しさん
垢版 |
2014/08/27(水) 00:16:36.50ID:UFd+PdSa
>>210
じゃあどうなればベストプラクティスなんだ？これは運用を決めてるだけじゃないかなんていう
ばかげたレスをしなければいいのに。

二転三転してんよ。
0212デフォルトの名無しさん
垢版 |
2014/08/27(水) 00:20:37.72ID:UFd+PdSa
>>208
多くの人が困った出来事に見舞われなくて済むように作られた集合知だから、
ある程度は統一されるよ。

>>202 の前者なんてのは痛い目を見て二度とするもんかと心に誓う手法でしかない。
0213デフォルトの名無しさん
垢版 |
2014/08/27(水) 01:21:09.81ID:1NXBn9Ay
1.9で予定されていた機能の殆どは延期
減り続けるユーザー
MLへの投稿も減少の一途
Apacheからも邪魔者扱い

どうすんの？
0214デフォルトの名無しさん
垢版 |
2014/08/27(水) 07:38:51.42ID:KL0wurV3
>>211
ひょっとして壊滅的に理解力がないとか？ w
俺は git flow も、trunk/tag/branch もレベルは違うが両方ともベストプラクティスだと言う立場だよ。
なので、>>194 に
> 確立されていない。
と言い切る理由を聞いてるだよ。

まあ、
> >>202 の前者なんてのは痛い目を見て二度とするもんかと心に誓う手法でしかない。
とか言う人には、理解できないかな。
0215デフォルトの名無しさん
垢版 |
2014/08/27(水) 07:42:25.58ID:KL0wurV3
>>213
別に今のまま使えばいいだけでしょ。
そのうちもっと便利なものが出てくれば移行すればいいだけだし。
>>213 が subversion の行く末を案じて、何とかしようと思ってるならがんばれーって応援するけどね。
0216デフォルトの名無しさん
垢版 |
2014/08/27(水) 07:44:19.56ID:W2qyiycm
svnで言うtrunk/tag/branchはこう使ったらいいぜ！
ってのがgit-flowなんですけど…
0217デフォルトの名無しさん
垢版 |
2014/08/27(水) 10:54:18.36ID:JjSOikWD
>>214
いやだから「git-flowのような」svnの運用方法はまだ確立されてないよねって話なんですけど。
0219デフォルトの名無しさん
垢版 |
2014/08/27(水) 12:17:18.99ID:KL0wurV3
だから「ような」ってなに？
何を満たせばお前さんが言う「git flow のような運用方法」になるんだ？
って話をしてるんだが。
0220デフォルトの名無しさん
垢版 |
2014/08/27(水) 12:43:28.37ID:JjSOikWD
>>219
例えば、Subversionを初めて導入するチームが、とりあえずの指針として使えるような運用方法。
初めて導入する場合、trunk/branches/tagsを作るところまでは良いが、おそらくそこで途方に
暮れることになるだろう。
つか、git-flowとかGitHub Flow知ってる？
0221デフォルトの名無しさん
垢版 |
2014/08/27(水) 13:47:44.30ID:UFd+PdSa
>>217
新規開発ならまだしも、trunkで"新機能"開発を認めるような人って、
develop featureブランチを作らないことで何が起こるかしらない人かもしんない。
そうなら説明しても理解できないと思う。

git flowは使ったことないけど、ブランチ構成管理の図を見る限りsvnでも大抵同じ構成でやってるよ。
svnやgit、他のVCSひっくるめてブランチ管理のベストプラクティスってのはもうあって、
それをサポートするための実装の一つがgit flowなんじゃないかなぁと思うけど、gitユーザから見るとどうですかね。
0224デフォルトの名無しさん
垢版 |
2014/08/27(水) 14:32:21.64ID:JjSOikWD
>>222
もう、どう言ったらいいのか・・・。

svnbookで説明されてるされてることを、実際にどう運用するのが良いのかの指針となるような
git-flowやGitHub Flowのような運用方針が、人口に膾炙された形でsvn界隈にあるのかって
ことで、それはまだないでしょということなんだけど、わかんないかな。

長年svnを使ってれば、そりゃ自分たちにフィットした運用方針があるだろうけど、他SCMから来た人とか
初めてのSCMとしてsvnを選んだ（選ばざるをえなかった）人たちが、どう運用を開始すれば良いのかの
情報ってそれほどないでしょ。
そういうのがあれば、>>160にこれを参考にするといいよってURLを示すだけで終了でしょ。
0225デフォルトの名無しさん
垢版 |
2014/08/27(水) 15:01:37.11ID:UFd+PdSa
>>222
よりによってそれを貼るって、レベルが違いすぎて話にならない。ヨチヨチじゃねえか。

>>223
ちゃんと回ってるうちはそれでいいと思うもんなんだよ。
0226デフォルトの名無しさん
垢版 |
2014/08/27(水) 18:44:05.74ID:KL0wurV3
>>224
svnbook に書いてなくて git flow で決められてる方針とやらを書けばいいだけでしょ？
具体的に何も示さずに svnbook 見てもわからんけど、git flow なら方針書いてあると言われてもね。
なお、情報ソースは >>225 がレベルの高い奴を示してくれるらしいから、それでもいいよ (w
0228デフォルトの名無しさん
垢版 |
2014/08/28(木) 09:57:20.57ID:hbdIfiYh
>>226
> 具体的に何も示さずに
って、俺はそんなもの（確立された運用方針）なんかないって言ってるんだから、示すも糞もないよ。
あるんだったら、お前がURL示せ。
0230デフォルトの名無しさん
垢版 |
2014/08/28(木) 12:54:49.24ID:hbdIfiYh
>>229
一体何の話をしてるんだ？
gitにはgit-flowやGitHub Flowのような開発フローがあるが、svnにはそれに類するものがあるのか
というのが最初の疑問(>>160)。
で、そういうのは残念ながら無いというのが俺の主張。

「svnbook に書いてなくて git flow で決められてる方針とやらを書」いたものなんてどこにも無いよ。
0231デフォルトの名無しさん
垢版 |
2014/08/28(木) 18:46:05.74ID:XxtALw5X
>>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
0232デフォルトの名無しさん
垢版 |
2014/08/28(木) 23:21:36.65ID:Djfy5D0r
わかった上でわざとずれたこと書いて荒らしてるんじゃないかという気がしてきた。
0234デフォルトの名無しさん
垢版 |
2014/08/29(金) 00:07:08.18ID:Bkb0jioJ
まぁベストプラクティスおじさんも
>>160が欲しがるURLに辿り着けたようだし
この辺でもういいんじゃないの？
0235デフォルトの名無しさん
垢版 |
2014/08/29(金) 07:21:09.31ID:c8acy8St
>>233
> そのやり方はsvnbookを見れば同じようなことが書いてあるとでも言い出すんだろうか。

そんなご託は、違いを説明してから言えば？
0236デフォルトの名無しさん
垢版 |
2014/08/29(金) 10:15:23.47ID:IvLQYdhB
へえ、svnbookでは、こんなことが推奨されてるのか。

> Developers commit all new work to the trunk. Day-to-day changes are committed to /trunk: new features, bug fixes, and so on.
0237デフォルトの名無しさん
垢版 |
2014/08/29(金) 12:52:13.11ID:yH9aSNf4
>>236
小規模なチームならそのやり方でいいだろうし、もう少し複雑な開発なら次の節にも目を通しておいた方がいい
0239デフォルトの名無しさん
垢版 |
2014/08/31(日) 10:27:47.17ID:w7igHjFL
SVN1.6を使ってるプロジェクトで仕事をしている不幸な俺が来ましたよ。
今のプロジェクト資産をSVN1.8 に移行させたいんだが、dump してload でOKですか？
0240デフォルトの名無しさん
垢版 |
2014/08/31(日) 12:37:14.01ID:vjR2LjMT
>>239
この際gitに移行しろｗ

そうすりゃsvnなんて、できたものをアップするだけの
単なる中央サーバーにしておける。古くても全然問題なし。
0241デフォルトの名無しさん
垢版 |
2014/08/31(日) 13:03:00.35ID:w7igHjFL
>>240
全くその通りで、git に移行出来ればベストなんだが、
うちのプロジェクトの連中はSVN1.6に何の疑問も感じない管理職だの外注さんだのから
構成されていて、git 入れるとか言ったらそれだけでひと悶着ありそうな気配なので、
SVN以外は無理な感じ。
0242デフォルトの名無しさん
垢版 |
2014/08/31(日) 13:22:54.88ID:vjR2LjMT
>>241
違う違う。自分一人でgit使えばいいの。
ローカルだけで。

自分だけはgitで楽をする。
他の人は成長しないままｗ
0245デフォルトの名無しさん
垢版 |
2014/08/31(日) 14:43:01.38ID:1nPrgnOa
まわりが徐々に移行しているときに同じようにやっておかないと
いつの間にか直接移行できなくなるほどバージョンに差ができていたりするよなｗ
0248デフォルトの名無しさん
垢版 |
2014/08/31(日) 15:15:09.72ID:w7igHjFL
>>242
何という裏ワザ

>>245
そう思いますよ。駄目なプロジェクトってずっと同じもの使ったりするんで
何とかして欲しいです。

>>247
dump load しなくても大丈夫なのかな、、
0249デフォルトの名無しさん
垢版 |
2014/08/31(日) 16:08:57.38ID:phP4JmF2
>>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.
0251デフォルトの名無しさん
垢版 |
2014/08/31(日) 17:57:57.45ID:gvWJPatT
先月だかまで1.6だたけどbackportsに1.8来てたからうpぐれしたわ
0252デフォルトの名無しさん
垢版 |
2014/08/31(日) 18:39:37.01ID:nYTEAaY7
俺なんかなー
レポジトリを1.7にした一週間後くらいに1.8が出て涙目で1.8に上げたわ
0253デフォルトの名無しさん
垢版 |
2014/08/31(日) 19:21:08.74ID:EhwSagBI
互換性を調べられないような人にまで
駄目と言われるプロジェクトか
よっぽど駄目なんだろうな
0254デフォルトの名無しさん
垢版 |
2014/08/31(日) 19:27:26.51ID:phP4JmF2
「gitに移行するのがベストだから移行したい」ってこの人が言い出したら、俺だって反対する。
お願いだから何もしないでくれの裏返しで。
0256デフォルトの名無しさん
垢版 |
2014/08/31(日) 23:29:23.88ID:phP4JmF2
>>255
gitに移行すること自体は別に反対じゃない。
ただ、検証能力の低い人が移行したいと言い出すことについては反対。
0257デフォルトの名無しさん
垢版 |
2014/09/01(月) 00:21:24.59ID:AXYuTZK8
>>256
なんで条件つけるんだよｗ

検証能力が低い人が決めたことは
全部反対ってことで、git関係ないじゃないか。
0258デフォルトの名無しさん
垢版 |
2014/09/01(月) 00:29:29.14ID:dsbfj0jc
>>257
そうだよ。git関係ないよ。そう書いたつもりだけど。
なぜgitがベストだと判断したか、説得させる力がないのを、
あの人は疑問も持たず使ってるだとか、だめなプロジェクトを何とかしてほしいだとかいう人だよ？
アップグレードに関する知識も、答えが載ってるページを貼ったにもかかわらず理解できなかった人だよ？

そういう流れがあった上で、>>254では「この人」が言い出したらとなってるんだ。
0259デフォルトの名無しさん
垢版 |
2014/09/01(月) 00:33:17.89ID:dsbfj0jc
ちなみに、業務でやってるわけじゃないのならこういう言い方はしなかったと思うよ。
ただただ、業務上ソース管理の管理者的な立場にいるような人があのザマだったからで。
0260デフォルトの名無しさん
垢版 |
2014/09/01(月) 00:42:08.42ID:AXYuTZK8
その前にさ、subversionが別とベストだと
判断した理由がなければ、比較できないよね？

どうせsubversionは惰性で使ってるだけなんだろ？

gitに理由を求めるのであれば、
subversionに理由を求めてもいいはずだ。
0261デフォルトの名無しさん
垢版 |
2014/09/01(月) 00:46:31.35ID:dsbfj0jc
>>260
向きを変えてもいいよ。
現状gitを使っていて、管理者としての知識が欠けている人が、
svnのほうが便利らしいからsvnにしたいんですって言い出したらどうする？

よしんば知識が欠けていなかったとしても、なぜ？って話をするのが通常でしょ？
0262デフォルトの名無しさん
垢版 |
2014/09/01(月) 01:18:17.28ID:AXYuTZK8
>>261
あぁ、管理者が馬鹿なのか。
なら馬鹿な管理者よりも
有名な人が使っている人が
選んでいるものを使いますね。
0269デフォルトの名無しさん
垢版 |
2014/09/13(土) 16:12:11.13ID:278ay5Hi
質問させて下さい。
svn logで削除されてしまったファイルの履歴を見ることは可能ですか？
最新版で削除されている場合、エラーになってしまいます
pathではなくURL指定にしてみたり、-rでまだ削除されていないrevisionを指定してみたりしましたが、ダメでした

なにか、方法があれば教えてください
よろしくお願いいたします
0271デフォルトの名無しさん
垢版 |
2014/09/23(火) 00:08:53.77ID:EypAVB5A
>>270
URL後に@revで出来ました！
ありがとうございます！！

でも、そもそもrevいくつで消されたのかわからないと、この方法も厳しいですね
やっぱり、消されていない上位のフォルダ取ってフィルタとかかっこ悪い方法しかないですかね

いずれにせよ、ありがとうございました
0272デフォルトの名無しさん
垢版 |
2014/10/01(水) 21:51:38.36ID:AofJ5YBN
すみません。
情報いただきたいのですが、ユーザが二人いて、両者が同じバージョンの同じファイルをupdateしたとします。
そのうち片方がdelete、commitを行いファイルをサーバから削除したとします。
その状態でもう片方がそのファイルを編集して、その後、サーバでファイルが削除されていることに気がついてupdateをしたら何が起こりますか？
ファイルがワーキングコピーから削除されることを期待しているのですが、うまく動きません。
コンフリクトの解決でなにか必要なオプションがあるのですか？
0273デフォルトの名無しさん
垢版 |
2014/10/01(水) 22:34:23.68ID:dBYSrlyc
>>272
> updateをしたら何が起こりますか？

コンフリクトするんじゃね？

> ファイルがワーキングコピーから削除されることを期待している

編集中の内容がなくなるような動作はしないはず。

> うまく動きません。

なんでどうなるのか書かないんだ？
普通の板ならいざ知らず、ここはム板なんだよ。
0274デフォルトの名無しさん
垢版 |
2014/10/01(水) 22:43:39.38ID:DTMRbqd/
>>272
コンフリクトが起こる
コンフリクトを解決するのはユーザの仕事
コンフリクトを起こしてしまった人間が、自分の仕事を破棄しても良いと判断するなら、revertすれば良いのでは？
0275デフォルトの名無しさん
垢版 |
2014/10/01(水) 22:46:51.36ID:DTMRbqd/
>>273
お前…偉いな
他意は無いよ
素直にそう思った

> なんでどうなるのか書かないんだ？
> 普通の板ならいざ知らず、ここはム板なんだよ。

これ重要だよな
0276デフォルトの名無しさん
垢版 |
2014/10/02(木) 01:46:05.51ID:XIrrMuib
どうなってるかぐらい読めるだろ。

> ファイルがワーキングコピーから削除されることを期待しているのですが、うまく動きません。
うまく動かない = 期待通りの動作をしない = ワーキングコピーに残ったままになる

> コンフリクトの解決でなにか必要なオプションがあるのですか？
コンフリクトが発生している
0277デフォルトの名無しさん
垢版 |
2014/10/02(木) 09:46:38.27ID:zHXM1gHR
アホはうまくいかない場合に高い確率で予想もつかない操作をしている。
したがって現在の状況は激しく不明。適切なアドバイスは不可能。
0278デフォルトの名無しさん
垢版 |
2014/10/02(木) 09:52:19.05ID:vjyI8iPg
馬鹿には無理
0279デフォルトの名無しさん
垢版 |
2014/10/02(木) 10:04:16.90ID:mcw6ATuL
俺らの常識を超えるのはよくあることだが
予想もつかないと認めてしまうともはや転職するしかない
0280デフォルトの名無しさん
垢版 |
2014/10/02(木) 12:35:56.17ID:iu9W8QST
>>272
もう答えが出てるも同然なんだけど、親切ぶって書いておくと

＞コンフリクトの解決でなにか必要なオプションがあるのですか？

コンフリクトの解決として、ローカルにあるファイルを生かすのか、削除するのかは
ユーザーが選ぶ必要がある。

その選択がすでに決まっている(今回の場合はリポジトリ優先)なら update / resolve のオプションで
--accept theirs-conflict か theirs-full が使えるかもしれない。
0281デフォルトの名無しさん
垢版 |
2014/10/02(木) 22:44:40.53ID:YtrPZWGc
>>279
> 予想もつかないと認めてしまうともはや転職するしかない

自社製品（ソフトウェア）のサポートしたことあるけど、色々ヒアリングしたら結局インストールしてないとかはまだかわいいもので、全く関係のない他社製品のクレームいれてきて、すぐ直せとか、予測なんてとても無理 w
0282デフォルトの名無しさん
垢版 |
2014/10/03(金) 00:13:17.34ID:sUnjKgGy
予想できる範囲の予想を放棄することについて言ってんでしょ。
理解力のなさが致命的じゃないか。そんなのでサポートできるのかどうか疑問だが、
過去形だからもうサポートはしてないんだよね。賢明だと思う。
0284デフォルトの名無しさん
垢版 |
2014/10/03(金) 08:15:06.89ID:N0NEXaB4
予測でサポートは愚の骨頂
状況をヒアリングする → サポートデータベースを引き、それに合ったアクションをとる
システム化されたユーザーサポートには予測など入る余地はない
0286デフォルトの名無しさん
垢版 |
2014/10/03(金) 09:21:34.28ID:N0NEXaB4
ヒアリングせず他社製品のクレームだと予想してそれへの対応するのか?
死んだ方が良いぞ、お前。
0288デフォルトの名無しさん
垢版 |
2014/10/03(金) 16:32:03.89ID:N0NEXaB4
残念ながら「事例」が出てきてるのは、お前が読み飛ばしたはずのオレのレスなんだ。
頭悪いぞ、お前。
0291デフォルトの名無しさん
垢版 |
2014/10/03(金) 17:49:28.71ID:SuG4O46a
>>283 書いてからしばらくたって ID変えてまで >>284 書くから別人かと思った

～を聞いてみて～という返事が返って来たら、他社製品の○○のせいだからお引取り願う
なんて事例は結構あるかと思ったけど
0292デフォルトの名無しさん
垢版 |
2014/10/03(金) 18:00:02.33ID:lXIQAzKJ
２ちゃんで他人か自演かを議論しても殆ど意味は無い
0293デフォルトの名無しさん
垢版 |
2014/10/03(金) 18:14:35.26ID:x+Ir+7bo
>>291
> ～を聞いてみて～という返事が返って来たら、他社製品の○○のせいだからお引取り願う

そんなやわな例ならわざわざ書かないよ
>>281 で書いたのは、うちの製品が全く関係ない例
具体的な製品名は出せないけど、例えばプリンタで印刷がおかしいというクレーム受けたから、色々ヒアリングしたら最終的に他社の製品だったというオチ
最初に型番ぐらい確認しろよ、とか言うだろうけどそんなものにまともに答えるような奴はそもそもこんなアホなクレームつけてこない
下手に無理やり型番聞こうとすると、そんなもんはどうでもいいからすぐ来て直せとかよけいに激昂して泥沼に入るだけ
0296デフォルトの名無しさん
垢版 |
2014/10/03(金) 21:57:20.10ID:9JXRawoI
次にお前はこう言う
「俺が予測出来ないのでは無い。相手がアスペなんだ」
「はっ？！」
0298デフォルトの名無しさん
垢版 |
2014/10/04(土) 05:03:15.68ID:lObYY5qZ
>>293
あなたの経験はどうでもいいんだけど、今回の話の基点になってるのは >>272 に対する >>277 だよね。
>>272 を読んで適切なアドバイスが不可能な人は、今のところ >>277 以外にいない。
0299デフォルトの名無しさん
垢版 |
2014/10/04(土) 05:55:20.32ID:j+aw4iLv
>>298
あなたは >>272 なの？
適切なアドバイスかどうかは >>272 でないとわからない
>>280 みたいな具体的なコマンドラインオプションを知りたかったのかもしれないし、>>297 が正しいなら git へ go が適切だったかもしれない
あと、アドバイスができない奴でレスしない奴がいないことをどうやって確認したの？
0300デフォルトの名無しさん
垢版 |
2014/10/04(土) 07:03:31.85ID:lObYY5qZ
>>299
>>272じゃないよ。ところで>>299は>>293なの？

> >>280 みたいな具体的なコマンドラインオプションを知りたかったのかもしれないし、
ちがうね。期待していた動作に近い挙動をさせる方法を知りたかっただろう。

> >>297 が正しいなら git へ go が適切だったかもしれない
まさかｗ
0302デフォルトの名無しさん
垢版 |
2014/10/04(土) 08:55:27.06ID:9D7AARhC
こんなものは停滞し続けてもらわないと、
フォーマットが変わったから1からコミットし直しなんて
もう嫌だｗ
0304デフォルトの名無しさん
垢版 |
2014/10/04(土) 15:45:10.72ID:ugcUiR2p
>>298
>>>272 を読んで適切なアドバイスが不可能な人は、今のところ >>277 以外にいない。

お前が適切なアドバイスとやらをしてみろ。ワ
0305デフォルトの名無しさん
垢版 |
2014/10/06(月) 02:58:33.52ID:0Y2OJiB/
何で伸びてんのかと思ったら理解力がないものとそれを無駄にあおり続けるものの応酬だった。
2chでは良くあることだけどこのスレでそうなるとはね。
0306デフォルトの名無しさん
垢版 |
2014/10/06(月) 03:22:18.69ID:S+cxwUfE
２ちゃん中毒症状の進行
1.物騒な掲示板だなと印象を持つ
2.全部自演だと思い込む
3.自分で自演を始める
4.自分で自演してるのに他人の自演を叩く
5.自演じゃないと言い張る
6.他人のレスと自分のレスの区別が付かなくなる
0307デフォルトの名無しさん
垢版 |
2014/10/06(月) 21:58:30.50ID:2jlCLSza
>>306
6番って、
他人へのレスと自分へのレスって事？
それとも、
自分が書いたレスを(自演だけど)本当に他人が書いたと思ってしまうって事？

前者は良くいるけど、後者は怖いよね…
0308デフォルトの名無しさん
垢版 |
2014/10/06(月) 22:37:11.58ID:+UB/EuAd
なんで伸びてるのかと思ったら、>>305 がヨタ話始めただけだった。
2chでは良くあることだけどこのスレでそうなるとはね。
0310デフォルトの名無しさん
垢版 |
2014/11/18(火) 11:29:16.53ID:4hHTj/p7
TortoiseSVNの「未コミット項目が残ったらコミットダイアログを再度開く」のオプションって
なんで無くなったのか分かる人いない？
一部だけコミットしてまたコミットダイアログ開くの面倒くさいよ
0311デフォルトの名無しさん
垢版 |
2014/12/15(月) 20:56:02.95ID:4cyuKd8C
svn logでそのレビジョンで変更があったファイル、フォルダを見れると思います
その際、削除されたフォルダの下の情報も取得するオプションはありますか？

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

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

ご存知の方がいらっしゃいましたら、教えてください
よろしくお願いいたします
0312デフォルトの名無しさん
垢版 |
2014/12/18(木) 02:07:41.51ID:h1z0/qH7
Subversion 1.7 & TortoiseSVN 1.7 系の環境を　
Subversion 1.8 & TortoiseSVN 1.8.9 に移行して、気が付いたんだが、

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

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

これって仕様なんだろうけど、使いにくくないか？
0313デフォルトの名無しさん
垢版 |
2014/12/18(木) 02:11:07.69ID:mibKJ2wG
>>312
Subversion の rename は copy&delete の２つの操作の組み合わせとしてコミットされる。
1.7 までは rename で発生した copy だけをコミットすることができていたが、それはたいていの場合
間違い。（リポジトリ上にリネーム前のファイルと後のファイルが両方存在する状態になる）

そういう間違いを防ぐため 1.8 でこれをエラーとするようにした。とても助かる。
0321デフォルトの名無しさん
垢版 |
2014/12/21(日) 13:28:53.87ID:wgEqtlVM
svn.exeで色々とオプション試してみたが、無理だと思う
svn.exeではなく、subversionのDLL直叩きなら、なんか方法あるかもしれんが

>>318>>316>>314
本当に出来るなら、やり方教えて欲しい
0322デフォルトの名無しさん
垢版 |
2014/12/21(日) 13:55:00.79ID:Av/isWbI
>>313
rename した後に同じフォルダーでcommit するとエラーで
上のフォルダーに移動してcommit するとＯＫってのが謎の仕様なんですけど、、
0323デフォルトの名無しさん
垢版 |
2014/12/22(月) 00:43:12.72ID:wZjn2wNf
>>321
ちょっと意地になって色々ためしたけど、無理っぽい
あと、質問なんだが、

＞subversionのDLL直叩き

これどういう意味？
0325デフォルトの名無しさん
垢版 |
2014/12/26(金) 20:56:52.95ID:9COLSw4d
すみません、何方かアドバイスをお願いします

メンバの一人が間違って登録されてるファイルを全部消すと言うミスをしてしまいました
このリビジョン（仮にrev100）における操作を完全に無かったことにしてrev99=HEADの状態
にするにはどうすればよいのでしょうか？
0327325
垢版 |
2014/12/26(金) 21:21:58.89ID:9COLSw4d
325です
自己解決しました
0329325
垢版 |
2014/12/27(土) 12:33:50.64ID:P6YUVs7g
325です
履歴にも残さずに完全にロールバックしたかったので逆mergeやcopyと言う方法
は選べませんでした
0330デフォルトの名無しさん
垢版 |
2014/12/31(水) 15:11:53.14ID:R9r0iQKl
今年はsubversionの終わりが加速した感じだった。
dev-MLの投稿数は毎月200通以下が普通になったし、
1.9は全然収束しない。
しかも、1.9は機能を削りまくってる。
まともなrenameトラッキングは当分先みたいだし。
うちの会社もあちこちでgitに移行してるし。
0331デフォルトの名無しさん
垢版 |
2014/12/31(水) 15:15:26.31ID:lvkAiJ/l
それは良かった
0332デフォルトの名無しさん
垢版 |
2014/12/31(水) 15:35:26.41ID:uw/dheYU
このスレーってもうSubversion単体スレーである必要が全く完全に無いだろ
バージョン管理ツールスレーとかでいいんじゃないの？
>330 も言うようにどんどんgitへの移行も進んでるし、今更subversionで語る
ようなことも無いだろ
0333デフォルトの名無しさん
垢版 |
2014/12/31(水) 16:36:32.17ID:69RlDRjx
人居ないからな
廃合は仕方ない
0334デフォルトの名無しさん
垢版 |
2014/12/31(水) 19:52:34.34ID:+R6nzZDg
Gitだと、ロックして編集とかEXCELの管理とか
やりにくいんじゃなかったっけ？
0335デフォルトの名無しさん
垢版 |
2015/01/01(木) 03:48:37.20ID:EqvEBySL
そういうのはSubversionが向いてる
もっともエクセル単体ならエクセル自身でバージョン管理した方がいいけど
0336デフォルトの名無しさん
垢版 |
2015/01/02(金) 00:56:10.13ID:2EPSXalc
ロックはともかくExcelにSubversionの利点なんてあったっけ？

バイナリ差分があまり効かないからgitと大して変わらないような
0337デフォルトの名無しさん
垢版 |
2015/01/02(金) 01:38:07.24ID:Mlsgxxua
subversionは名前が悪かったと思う。何しろ「サブ」だし。
せめてmainversionとかの名前ならもうちょっとユーザが増えた気がする

あと、gitなら「じっと」「ぎっと」「ぎと」って感じで呼ばれることが多いけど
subversionは「さぶ」「さぶん」「さぶば」で通用する事はあまり無くて大体が
「えすぶいえぬ」って呼ばれるのも痛い
0342デフォルトの名無しさん
垢版 |
2015/01/03(土) 01:46:39.23ID:d2Sh2V72
>>336
ロックが取れる事がexcel(というかバイナリ)を使う上での最大のメリットってことでしょ。
一人で使う分には、確かにgitでも変わらんけど。
0343デフォルトの名無しさん
垢版 |
2015/01/03(土) 01:49:31.60ID:d2Sh2V72
>>335
エクセル自身のバージョン管理はオススメできぬ。
ファイルが肥大して大変だし、壊れた時のリスクが高い。
0344デフォルトの名無しさん
垢版 |
2015/01/04(日) 02:36:33.25ID:i9Li470n
バイナリ差分があまり効かないというが、がんばればしっかり差分取れるものではある。
ただ面倒なんだよなopenxml
0345デフォルトの名無しさん
垢版 |
2015/01/08(木) 21:44:20.48ID:G6P01zOT
OfficeはOffice自身でバージョン管理できるし、本格的にビジネスで使うならSharepointがある
ソースコードと一緒に管理したいならSvnでもいいけど
0346デフォルトの名無しさん
垢版 |
2015/01/11(日) 10:21:40.94ID:CE66uVvw
質問させて下さい。
あるファイルをaddしてcommit、編集してcommit、deleteしてcommitしたとします。 -> この履歴を①とします。
その後、同じ名前のファイルをaddしてcommitしたとします。 -> この履歴を②とします。

その状態で、その名前に対し、svn logをすると、②の分の履歴しか取得できません。
svn logに渡すpathに@バージョン番号をつけると①の履歴が取れますが、逆に②の履歴が取れません。

おそらく、subversionの頭が良くて、同じpathでもdeleteされた前と後では別物として扱っているのだと思います。
どうにかして、svn logでpathを指定した場合、途中でdeleteが行われ同じファイル名のファイルがaddされていたも、そのpathの全ての履歴を表示する方法は無いでしょうか？


よろしくお願いいたします。
0347デフォルトの名無しさん
垢版 |
2015/01/13(火) 23:43:22.59ID:IQluUJw+
logは履歴を見るもんなんだが。
履歴がつながってないから全く別のファイル。
どうしてもそれしたければ
delete直前のリビジョンからコピーしてきて新しい内容で上書き&コミット。
0349デフォルトの名無しさん
垢版 |
2015/01/19(月) 10:22:10.09ID:a1hSaFg4
trunk
　　AAAA
　　BBBB
　　CCCC
　　DDDD

↓

trunk
　　DDDD
　　EEEE (新規に追加)
　　　　AAAA
　　　　BBBB
　　　　CCCC

TortoiseSVNで上のような移動をしたいのだけど、
これをやったあとにEEEEフォルダのログを見たとき、
AAAAやBBBBなどのこれまでのログも出てくるようにできますか？
0350デフォルトの名無しさん
垢版 |
2015/01/19(月) 13:29:01.96ID:KroxEeJe
1)
trunk
　　AAAA
　　BBBB
　　CCCC
　　DDDD
　　EEEE 追加

2)
trunk
　　DDDD
　　EEEE
　　　　AAAA 移動
　　　　BBBB 移動
　　　　CCCC 移動

手順踏めば大丈夫
0351デフォルトの名無しさん
垢版 |
2015/01/19(月) 13:40:20.78ID:a1hSaFg4
>>350
その方法でやってみたのですが、EEEEフォルダのログには、
EEEEフォルダ追加からのログしか出てこないのです。

trunkフォルダのログや、AAAAフォルダのログには、
EEEEフォルダ追加以前のものもすべて出てきます。
0353デフォルトの名無しさん
垢版 |
2015/01/19(月) 13:56:35.50ID:a1hSaFg4
リポジトリブラウザ上でテストしたので、
操作ごとにコミットされているかと思います。

ログは以下のようになっています。

リビジョン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)
0356デフォルトの名無しさん
垢版 |
2015/01/20(火) 10:48:22.12ID:tMuEMnZJ
>>354-355
フォルダに対するログの表示は、
「フォルダ以下にあるすべてのアイテムのログ」ではなく、
「フォルダそのもののログ」ということなんですか。

フォルダを移動しないうちは同じように見えるけど、
移動してしまうと表示の違いが出てくると。

前者のほうがしっくり来るのですが、こういう表示はできないのですかね。
0358デフォルトの名無しさん
垢版 |
2015/02/16(月) 20:57:30.37ID:T+HM2fDz
どなたか詳しい方、コメントいただきたく。もうワケが分からない…


windows7のPCをSubversionのサーバーとして使っています。
半年くらい前にpost-commitフックで、cmailを使ってコミット内容をメール通知するようにしました。

先日、サーバーを再起動した途端にコミット完了するのが異様に遅くなり、原因を調べてみるとcmailでメール送信する所で2分くらいダンマリしている事がわかりました。(この間、cmailプロセスのCPU使用率は0%表示。最終的にはメール送信成功する)

同じメール内容をサーバーのコマンドプロンプトから送信すると、一瞬で完了します。


どうアプローチしていいのか分からず完全にお手上げ状態です。誰かお助け下さい。
0359デフォルトの名無しさん
垢版 |
2015/02/17(火) 00:20:17.66ID:WOLXU8Lo
cmailでのメール送信だけやってみて様子を見るとか。
なんとなく名前解決関連な気もするけどわからん。
0360デフォルトの名無しさん
垢版 |
2015/02/17(火) 01:11:34.71ID:Yac0Xv4U
runasでhookを実行するアカウントで実行したら、なにか差が出るかも。
ただ、自分も名前解決のタイムアウト待ちで遅くなってる気がする。
0361デフォルトの名無しさん
垢版 |
2015/02/17(火) 01:38:29.79ID:Zpfk+lU7
そこまでジャンクXVIを馬鹿にされたのが悔しいんだったらせめてちょっとは
綺麗にしとけよ・・・
0362デフォルトの名無しさん
垢版 |
2015/02/19(木) 22:57:53.58ID:GIBMUh5u
cmailでのメール送信が遅い件ですが、Subversion鯖に入っているノートン先生が原因のようです

ノートン先生が動いているときだけ、smtp鯖との通信確立にキッカリ30s、通信切断に30sの待ちが発生していました

以上、ご報告まで
0364デフォルトの名無しさん
垢版 |
2015/02/25(水) 10:22:11.31ID:s+t8Qw+G
svn1.8クライアントで少し大きめ(5Gくらい?)の作業コピーを更新しようとしたらE175012がでるんだけど、
これって鯖管にsvn1.8サーバのSVNAllowBulkUpdatesにPreferを設定してもらうように依頼したら直る?
0365デフォルトの名無しさん
垢版 |
2015/02/25(水) 13:02:05.75ID:PzgEvNFF
プロトコルどれ使ってるのかわかんないけど、そこのタイムアウト値を大きくするのはだめかな。
0366デフォルトの名無しさん
垢版 |
2015/02/25(水) 13:15:35.93ID:s+t8Qw+G
おk。ぐぐった。
MaxKeepAliveRequests 1000もつけるといいのかな。
依頼してみる。
0367デフォルトの名無しさん
垢版 |
2015/02/25(水) 20:57:32.07ID:PzgEvNFF
いや、そういう話ではないけど、鯖管に状況を説明して対応してもらえば済むように思う。
0368デフォルトの名無しさん
垢版 |
2015/03/02(月) 22:51:53.18ID:Wh2eDC6Q
ロードマップ更新されているね。
subversion.apache.org/roadmap.html

dev ＭＬも2月は久しぶりに400通越えだし、少し復活ぎみかな？
0369デフォルトの名無しさん
垢版 |
2015/03/03(火) 21:22:08.36ID:Ow1+4ULv
おいおい、新機能がほとんど先送りになって、1.9の目玉が何も無いじゃないか。
ローカルコミットは2017年以降かよ・・・orz
0372デフォルトの名無しさん
垢版 |
2015/03/15(日) 11:52:06.42ID:/diHjsjh
初めてWINDOWSの環境でリポロジを簡易NAS(ルータにUSBでマウントFAT　）に設定しました。
xドライブはネットワークドライブです。使い始めて数回コミットしたらエラーが出たんでベリファイしてみるとエラーが出るんで
リカバーしてみてRecovery completed.になっても治りません。　使い始めたばかりなんでリポロジを作り直してみても同じ現象になります。
svn, version 1.8.11 (r1643975)
ネットワークドライブでは問題がるんでしょうか。
ファイル 'Z:\SVN_試験\repo\db\revs\0\3' 中の長さの行を読めません
C:\Documents and Settings\nagashima>SVN_試験admin recover Z:\SVN_試験\repo
Repository lock acquired.
Please wait; recovering the repository may take some time...
Recovery completed.
The latest repos revision is 16.

C:\Documents and Settings\nagashima>svnadmin verify Z:\SVN_試験\repo
* Verifying repository metadata ...
svnadmin: E200002: Can't read length line in file 'Z:\SVN_試験repo\db\revs\0\3'
C:\>svnadmin verify Z:\SVN_試験\repo
* Verifying repository metadata ...
svnadmin: E200002: Can't read length line in file 'Z:\SVN_試験\repo\db\revs\0\3'

C:\>svnadmin recover Z:\SVN_試験\repo
Repository lock acquired.
Please wait; recovering the repository may take some time...

Recovery completed.
The latest repos revision is 16.

C:\>svnadmin verify Z:\SVN_試験\repo
* Verifying repository metadata ...
svnadmin: E200002: Can't read length line in file 'Z:\SVN_試験\repo\db\revs\0\3'
0373デフォルトの名無しさん
垢版 |
2015/03/15(日) 12:34:17.19ID:BJ5YFT88
> ネットワークドライブでは問題がるんでしょうか。
ここを心配するのであれば、なぜローカルドライブでテストしないのか。

あとRepositoryですよ。
0374デフォルトの名無しさん
垢版 |
2015/03/16(月) 14:15:24.29ID:6lqVHjbl
Javaの実装ってことで、svnkitを手に入れようと思ったんだけど
svnkit.comが何か変。
ドメインが期限切れになってるっぽい？
本家はどこになるんだろう？
0375デフォルトの名無しさん
垢版 |
2015/03/18(水) 11:13:50.41ID:zk1mZNzk
Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

Domain Name: SVNKIT.COM
Registrar: REGIONAL NETWORK INFORMATION CENTER, JSC DBA RU-CENTER
Sponsoring Registrar IANA ID: 463
Whois Server: whois.nic.ru
Referral URL: http://www.nic.ru
Name Server: NS.MASTERHOST.RU
Name Server: NS1.MASTERHOST.RU
Name Server: NS2.MASTERHOST.RU
Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
Updated Date: 31-oct-2014
Creation Date: 08-nov-2006
Expiration Date: 08-nov-2015

切れてないようだけど。
0376デフォルトの名無しさん
垢版 |
2015/03/18(水) 18:14:42.63ID:tZAdOhnT
今見たらちゃんとページ表示されるね。
>>374 のタイミングだとsvnkit.comのトップページからdocumentからdownloadページまで全部レジストラの広告ページっぽかったんだよ。
総入れ替えメンテでもしてたのかね？
0382デフォルトの名無しさん
垢版 |
2015/03/29(日) 22:01:12.35ID:q/o8IL5N
アメリカ時間の3/31 に 1.8.13と1.7.20 が出る模様。（1.8.12はパスらしい）
日本だと4/1に入手可能か、、
0384デフォルトの名無しさん
垢版 |
2015/04/03(金) 19:43:51.07ID:b+Vrux7U
>>383
ttp://subversion.apache.org/docs/release-notes/1.9.html

・　FSFS (subversion の内部DB)　のフォーマットが7 になった（1.8 はformat 6)。

FSFS format 7 への移行は
a) バイナリを入れ替えるだけ
b) バイナリ入れ替え＋svnadmin upgrade
c) dump ＋　1.9 でDB作成＋load
d) dump ＋　1.9 でDB作成＋load ＋svnadmin pack

のそれぞれの移行方法があるけど、Service qualityに差があるよ

・ＦＳＸっていう新しいＤＢも使えるけど、実験的な段階。

・コマンドがいくつか新しくなって、バグも直ったよ。

って感じかな。　　
0386デフォルトの名無しさん
垢版 |
2015/04/04(土) 11:06:27.41ID:sJ89ayUs
こないだまでいた、プロジェクトではRedMine 1.x と付属(?)のSVN 1.6 を使って、
履歴が12000を超えていた、、、

全部ダンプしてsubversion 1.9 のDBにload してやりたいわ。
0387デフォルトの名無しさん
垢版 |
2015/04/05(日) 10:37:15.12ID:LvdFe5oB
>>384
> ttp://subversion.apache.org/docs/release-notes/1.9.html

> ?Full checksum coverage of all revision data, including meta data and structural information.

で全データのチェックサムで保存するようにして、
次回 1.10 でrename トラッキングを実現しようという魂胆かな？
0389デフォルトの名無しさん
垢版 |
2015/06/08(月) 23:15:01.53ID:LTF0S2/5
基本的なことですが、AIX版のsubversionクライアントってありますか？？
ご存じの方がいれば教えていただけませんか？
0390デフォルトの名無しさん
垢版 |
2015/06/09(火) 14:28:08.81ID:+pJotM6M
基本的なことですか。makeすればよろしいのではないでしょうか。xl cでも何とかなるでしょう。
0391デフォルトの名無しさん
垢版 |
2015/06/09(火) 14:54:49.73ID:zvNkm8tu
そういえば昔、gccをインストールさせてくれってお願いしたけど、断られた思い出
0396デフォルトの名無しさん
垢版 |
2015/07/29(水) 19:56:40.21ID:syqOZkA4
Subversion 1.9.0
Subversion 1.8.14
Subversion 1.7.21

の3つが近いうちにリリースされそう。
0398デフォルトの名無しさん
垢版 |
2015/07/30(木) 09:31:53.91ID:f5wFg7pZ
バージョン多すぎ・更新間隔早すぎでついていけない
安定版と開発版の2つに減らして、更新は年1回にしてくれ
0399デフォルトの名無しさん
垢版 |
2015/08/01(土) 01:28:56.60ID:IR1g6pTz
1.9 の次は 1.10、1.11、1.12・・・
そうこうしているうちに subversion は時代遅れとなり消滅
2.0 は出ない
0400デフォルトの名無しさん
垢版 |
2015/08/03(月) 23:37:24.63ID:TW8nRuhL
Road Mapのページも更新されたので、
p://subversion.apache.org/roadmap.html

１．９が出るまで秒読み状態かな。
0402デフォルトの名無しさん
垢版 |
2015/08/07(金) 08:41:28.17ID:s6JmbTZM
きたか…!!
　　^‐‐^
　 ( ﾟ д ﾟ )　ｶﾞﾀｯ
　 /　　 ヾ
＿L| /￣￣￣/＿
＼
0405デフォルトの名無しさん
垢版 |
2015/08/11(火) 21:47:30.81ID:Yn+B/MfB
TortoiseSVN 1.9.0/1.8.12 リリース告知でたよ
メーリングリストに日本語で質問する三菱電機さんのつわもの現れた
logがおかしいみたいだけどよくわからんかった
0406デフォルトの名無しさん
垢版 |
2015/08/12(水) 03:44:20.32ID:uUCq7Pj1
> logがおかしいみたいだけどよくわからんかった
見たけど、俺も他に言いようがないな
0409デフォルトの名無しさん
垢版 |
2015/09/27(日) 10:50:16.75ID:j+3Ff7Dl
TortoiseSVNを使用しているのですが、質問させてください。
第三者のオンラインレポジトリから更新のある度にソースを拝借しつつ、
それを元に自分で改造したものをローカルレポジトリでバージョン管理したいと考えています。
このような場合、都度オンラインとローカルとで「切り替え」を行う運用でよいのでしょうか？
もっとスマートな運用方法があれば、ご教示いただければと思います。
0411デフォルトの名無しさん
垢版 |
2015/09/27(日) 12:30:16.28ID:VKkr6PIE
>>409
Subversionの開発に参加し、難航しているローカルコミット機能の実装に協力して2.0の新機能に盛り込ませる。
0412デフォルトの名無しさん
垢版 |
2015/09/27(日) 14:35:24.93ID:V6V0Y/p4
リボジトリが中央に一つという前提の設計が仇となって使いづらいよねえ
Gitの唯一にして最大の弱点（コミットのコメントにShift_JISが使えない）さえ
改善されれば、Subversionにこだわる必要もないんだが
0415409
垢版 |
2015/09/28(月) 23:28:21.88ID:Up+Tp8mt
レスいただき、ありがとうございます。
これを機に、gitに入門したいと思います。

>>411
とても素敵な解決策ですが、実現し得るスペックが今の私にはないので、今回は見送らせてください。すみません。
0416デフォルトの名無しさん
垢版 |
2015/09/29(火) 03:15:49.80ID:DjqaY7BG
普通にローカルコミット相当のブランチ作るんじゃダメなの？
それが手間だってことなら、そうですかとしか言えないけど。
0417デフォルトの名無しさん
垢版 |
2015/09/29(火) 04:30:44.86ID:AQnR8FWO
svnではexternal使えばいいんじゃないの?
欲しいのは所謂ベンダーブランチなんでしょ?

gitではremoteで他所のリポジトリを参照できる。
pullはするがpushはしないという運用でも良いかも知れんけど結局マージすることに変わりなし。
0418デフォルトの名無しさん
垢版 |
2015/11/03(火) 12:24:52.10ID:ld5Elv3z
Subversionが使えるSaaSの定番ってある？
0420デフォルトの名無しさん
垢版 |
2015/11/22(日) 01:10:45.52ID:/loq94Ox
質問ですが
Q1. svnで削除され、かつheadまでの間マージ等で復活してもいないファイルをリポジトリから完全削除する簡単なやり方ってないでしょうか。
svnadmin dump old_repo | svndumpfilter exclude --pattern "*.csv" | svnadmin load new_repo
でとりあえず"*.csv"にマッチするやつだけはまとめて消せましたが、
これをいちいち人手で削除対象を指定するのではなく、「svnで削除され、かつheadまでの間マージ等で復活してもいないファイル」という条件で消したい。

Q2. Rev.1～24を取り出せなくして（checkoutもupdateもできなくして）、かつリビジョン番号は保ちたいのですが、なんか方法ありませんか。
svnadmin dump -25:head | svn load new_repoとしたら一応取り出せなくすることはできたのですが、
勝手にリポジトリ番号が1始まりになってしまいまつ…
0421デフォルトの名無しさん
垢版 |
2015/11/22(日) 18:42:33.39ID:URyBXPFx
すみませんが、質問です。
あるファイルの履歴が、特定のコミットから前はたどれなくなっています。
svn blame してもそのコミットより前は取得できません。
しかしそれはそのコミットで新規作成されたものではなく、それ以前にも
存在したファイルのようなのです。理由は
・その特定のコミットがファイル全体でなくごく一部しか登録していない。
・そのディレクトリの以前のコミットを見ると、そのファイルを変更するコミットがいくつも見つかる。

ということで、質問です。
・これはどういう原因が考えられますか？
・ある特定の行がどのコミットで作成されたか、その特定のコミットより前に
　さかのぼって調べるにはどうしたら良いでしょうか？
0426デフォルトの名無しさん
垢版 |
2015/12/20(日) 23:02:19.20ID:MLldicde
すみません、svn merge で、
trunk と branch 間じゃなくて、
trunk から派生した機能branch 同士でマージすることってできますか？
またそれに関して何か参考資料があったら教えていただけないでしょうか？
どうも svn:mergeinfo のなかった頃の記事しか見つからなくて。
0427デフォルトの名無しさん
垢版 |
2015/12/21(月) 01:58:30.57ID:/A+q3f8t
>>426
できると思うけど。
俺の普段使っている構成はtrunk/brunch構成じゃなくて、brunchだけみたいな構成だけど、普通にマージしてるよ。
ってか、やってみたほうが早いぞ。
原理的に不可能なわけないんだから。
0429デフォルトの名無しさん
垢版 |
2015/12/21(月) 21:47:56.22ID:C2nvBJp+
>>427
426 です。
確かに trunk に対して sync merge の済んでいる branch 同士なら、
原理的には安全に merge できそうですね。
trunk からの派生時期が違ったとしても。
時間に余裕ができたら実際に試してみます。ありがとうございました。
0430デフォルトの名無しさん
垢版 |
2016/01/08(金) 16:15:51.03ID:vMu+JJ4u
質問です。
ある機能ブランチ func1 の開発で
trunk をときどき sync merge していたのですが、
どうもこれをよく理解せずにやった人がいたらしく
svn mergeinfo --show-revs eligible ^/trunk/
で何も出ないにも関わらず、
svn diff ^/trunk ^/branches/func1
だとtrunkの更新分がいろいろ func1 に取り込まれていないことが判明しました。

この修正はどうやったらいいのでしょう？

例えばfunc1で更新されていないファイルは、trunkからコピーして
そのままコミットしたいところですが、今度は func1 を trunk に
マージするとき、そのコミットがtrunk に反映されてしまいそうです。

・修正コミットの番号をわかるようにしておく
・func1 を trunk にマージするとき、その修正コミットだけを除外する
・マージコミット時、svn:mergeinfo を編集して、その修正コミットもマージ済みだということにする。
とりあえずこんな手順を考えていますが、もっと適切な方法はあるでしょうか？
0431デフォルトの名無しさん
垢版 |
2016/01/13(水) 21:18:16.79ID:V0iG8LAX
svnにはいくつも欠点があるが、中でもマージが1コミットになってしまうのが
自分はつらい。
機能ブランチ内で1コミット1サブ機能でキレイなコミット歴を残しても
trunkにマージされたら全部まとめて1コミット。
当時の履歴を追いかけるには、もう消したブランチを追いかけなきゃならない。
Gitならmasterにすべてのコミットが残ってるのに。
0432デフォルトの名無しさん
垢版 |
2016/01/13(水) 22:15:09.34ID:oEwhQ7Tk
バージョン管理システムのメリットよりも
使い方を覚える労力と、操作ミスでリボジトリをメチャメチャに
してしまうデメリットの方が大きいわ
俺はもうフォルダコピーで行くぞ
0434デフォルトの名無しさん
垢版 |
2016/01/13(水) 22:37:48.99ID:GW8aUEqD
助けてください！！

TortoriseSVNを使っています。
新プロジェクト（まだSVNに登録していません。）をいきなり、エクスプローラからソリューションを右クリックして、
コミットを実行してしまいました。エラーは出ませんでした。
でも、おかしいと思い、そのソリューションを開いたら、「.csprojが見つかりません。」みたいなメッセージが出ました。
その後、もう一度、Visual Studioを閉じて、再度上げ、問題のソリューションを
開いたら、本日作業した部分が消えていました。
どうしたら最新を戻せるでしょうか？

よろしくご指導ご支援のほどよろしくお願い申し上げます。
0435デフォルトの名無しさん
垢版 |
2016/01/13(水) 23:04:44.15ID:V0iG8LAX
>>434
C# のスレで聞いたほうがいいかもしれない。
たいていのプログラマはsvnを知ってるけど、
C#を知っている人は限られるから。つうか自分も知らない。
あとここ過疎スレだし。
0438デフォルトの名無しさん
垢版 |
2016/01/14(木) 01:03:43.85ID:0bFJzjCb
ああ、後woking dirでもないのに右クリックからコミットは無理かと。
右クリックしてRepo browser選んでみてはどうでしょか。
0439デフォルトの名無しさん
垢版 |
2016/01/14(木) 08:32:44.54ID:nVghBJHD
そもそもコミット時は必ずログ入カのダイアログが出るから
いきなりコミットしてしまいました
の時点で >>432 と同類のネタでしょ
0442デフォルトの名無しさん
垢版 |
2016/01/16(土) 14:07:18.15ID:T83PzPld
Subversion も git の良いところをどんどん取り込んでいけば、
とりあえず Subversion を選んどけば良いって状況になるはず
0444デフォルトの名無しさん
垢版 |
2016/01/16(土) 23:36:23.80ID:RCWlnHcP
Gitの良い所を取り込むのは今までもやってきてるけど、今後はもう
ほとんどないと思う。今までのペースを見ても
2008年 1.5 マージトラッキング導入。マージが自動に。
2011年 1.7 .svnディレクトリをワーキングコピーのルートだけに作成。
あとは svn merge --reintegrate が生まれて、自動化されて廃止されたり
svn mergeinfoコマンドができたり、そんぐらいしかない。
0445デフォルトの名無しさん
垢版 |
2016/01/17(日) 01:08:50.62ID:Hz/zelCD
>>442
日本人の発想とは違うから。
0446デフォルトの名無しさん
垢版 |
2016/01/17(日) 05:27:02.51ID:Qd0sLcKs
.svnだか.svnreposだかにリポジトリ作れればカジュアル用途で復活できるのにな
0447デフォルトの名無しさん
垢版 |
2016/01/17(日) 11:06:53.94ID:ifZNSkug
> .svnディレクトリをワーキングコピーのルートだけに作成。

これは、途中のディレクトリの.svnだけを他の場所に持って行ってupdate
ということができなくなってちょっと不満だった
(めったにしないからいいんだけど)
0448デフォルトの名無しさん
垢版 |
2016/01/17(日) 16:51:37.90ID:D83l6ovN
>>447
> 途中のディレクトリの.svnだけを他の場所に持って行ってupdate ということ

普通にリポジトリブラウザで途中のディレクトリを他の場所にチェックアウトすればいいだじゃないの？
0449デフォルトの名無しさん
垢版 |
2016/01/17(日) 18:24:28.43ID:ifZNSkug
いや…さすがにチェックアウト方法を知らないってことはないよ…

簡単にワーキングディレクトリをコピーする方法としてそれを使ってたって話
0450デフォルトの名無しさん
垢版 |
2016/01/18(月) 01:40:17.48ID:9UQJyg5l
>>449
そうすることのメリットは特にないよねってだけじゃないかな。
ネットワークが致命的に遅い環境ならわからんでもないけど。
0453デフォルトの名無しさん
垢版 |
2016/02/02(火) 00:59:33.59ID:zG53U0gn
指定のブランチだけローカルにリポジトリ作って
ローカルコミットできる機能がほしい
0456デフォルトの名無しさん
垢版 |
2016/02/04(木) 18:44:49.97ID:y0p/gOVk
ウチはgitをインストールするとＰＣの調子が悪くなる
gitをアンインストールすれば治る
だからまだgitに移行できてない
0457デフォルトの名無しさん
垢版 |
2016/02/04(木) 19:14:52.59ID:PFzCzh/c
>>455
> おまえら、svk亡き後はgit-svnつかとる？
一時使ってたけどいまいちスキルがなくて挫折した
ローカルコミットはうらやましいけどまあ SVN でだいたい間に合ってる
0458デフォルトの名無しさん
垢版 |
2016/02/04(木) 20:04:34.89ID:usIHembP
svkってなくなったんだ。
0460デフォルトの名無しさん
垢版 |
2016/02/09(火) 08:09:15.77ID:yUya84EX
SVNのマージってGitとかの新しめのVCSのマージと比べて制限ある？
GitみたいフローをそのままSVNでやってもOKかな？
0461デフォルトの名無しさん
垢版 |
2016/02/09(火) 08:45:58.79ID:G1Osl5xS
>>460
gitだと一瞬で終わる作業がsvnだと数十秒～数分ぐらい
かかるだけで同じことは出来るよ。

例えばrebaseだと5分ぐらいかかるかな。
0464デフォルトの名無しさん
垢版 |
2016/02/09(火) 18:55:36.30ID:IuKqTpt8
ToroiseSVNの質問はここで良いでしょうか？

二つのサーバで、それぞれでsvnのリポジトリを運用しているのですが、一方のサブディレクトリから他方のサブディレクトリを参照したいケースがあり、対応方法を検討しています。
（ディスク容量の都合上、リポジトリは一方に寄せられません）

今考えているのはhttpd.confにredirectを入れる方法です。

Redirect permanent /repo_path1/subdir1 http://domain2/repo_path2/subdir2

この方法だと、ブラウザからであればsubdir1にアクセスするとリダイレクト先のURLにリダイレクトされ、subdir2配下のディレクトリにもアクセスできます。
しかし、ToroiseSVNからだとsubdir2の中身は参照できますが配下のファイル等にアクセスするとURLが以下のようになりアクセスできません。

期待：http://domain2/repo_path2/subdir2/fileA
実際：http://domain1/repo_path1/subdir2/fileA

二つのリポジトリはBasic認証でアクセス制限していますが、アカウントとパスワードは同じです。

上記の事象の解決方法をご存知の方いらっしゃいましたらご教示願います。
0465デフォルトの名無しさん
垢版 |
2016/02/09(火) 19:57:12.05ID:IuKqTpt8
書き忘れてましたが、クライアント環境は
・Windows7
・TortoiseSVN 1.9.3 Build 27038 32Bit
・Subversion 1.9.3

サーバ環境は、リダイレクト元が
・CentOS 5.5
・Subversion 1.6.5-1
・httpd 2.2.3-43

リダイレクト先が
・CentOS 5.5
・Subversion 1.6.6-1
・httpd 2.2.3-63
です。
0471464
垢版 |
2016/02/10(水) 09:33:23.13ID:iFU3NYts
>>469
externals属性を試してみたところ、こちらの方が自分のやりたいことに適していました。
ありがとうございます。
0476デフォルトの名無しさん
垢版 |
2016/02/26(金) 22:44:41.52ID:tr67YefW
SubversionとGit両対応（クライアントとして）のサービスってGitHub以外ない？
0477デフォルトの名無しさん
垢版 |
2016/02/26(金) 23:01:41.70ID:o2AR5xl0
むしろsvn git hgに対応してないコードホスティングがあったら聞いてみたいくらい
0478デフォルトの名無しさん
垢版 |
2016/02/27(土) 10:44:10.28ID:wchZYC9x
>>477
GitHubがそうじゃん…
0480デフォルトの名無しさん
垢版 |
2016/02/27(土) 12:05:21.42ID:Y1XYvpWg
Git は初期から SVN からの移行を狙って
SVNもどきモードを付けてた

今も動くかは知らん
0481デフォルトの名無しさん
垢版 |
2016/02/29(月) 01:06:23.06ID:SlyvrE0p
えっ、GitHubってSubversion使えるの？？？
GitHubはGitしか使えないもんだとばかり思ってた
うちのPCは２台とも、Gitをインストールすると不調になるんで
(C言語のコンパイルができなくなるなど、不可解な現象が)
Subversion使えるとこ探してた
べつにOSDNも構わないんだけど・・・
0486デフォルトの名無しさん
垢版 |
2016/03/22(火) 19:04:25.92ID:rY40XwB7
リポジトリの一部をチェックアウトできること、チェックアウトしたファイルのタイムスタンプを復元できること、この二つの利点がある限りSubversionもドキュメント管理ツールとして使うつもり。
0488486
垢版 |
2016/03/23(水) 12:14:31.49ID:F88wfLyN
>>487
コミットした日付じゃなくて、コミットした時点のファイルのタイムスタンプが復元されて欲しい。
Gitの断片的なチェックアウトもやろうと思えばできるようだけど、一端全部チェックアウトしてから不要なものを消すという手順は面倒だね。
0492490
垢版 |
2016/03/23(水) 20:09:31.64ID:XvZTQgKe
>>491
すまん、自分は488じゃないんだ。横から勝手にコメントしただけ。
紛らわしいことをしてしまった。
0494486
垢版 |
2016/03/24(木) 18:32:22.80ID:FAmAzzpj
>>493
改めて確認してみたところ、コミット日時が反映されてました。
コミット時点のタイムスタンプというのは自分の勘違いだったようです。失礼しました。
0495デフォルトの名無しさん
垢版 |
2016/03/29(火) 23:57:12.51ID:IgCmXl5A
派生元の違うbranchをどうにかしてmergeしたいと思ってたんだけど、
やっとわかった。2-url-mergeを使えば良いのか。
http://subversion.apache.org/docs/svn-merge.txt

これで 3-way-mergeやrebaseのないsvnでも何とかやっていける。
ホントはさっさとGitに移行しなきゃならないんだけど、
その余裕がないんだよね…。
0496デフォルトの名無しさん
垢版 |
2016/03/31(木) 20:50:18.74ID:+0lEOH/d
デザイナさんが svn のレポジトリに backup/yyyMMdd ってディレクトリ作ってて、
アホかタグ使えよと思ってたんだけど、過去の履歴をgrepしようとして真顔になった。
git grep が svn にはない。アホは自分でした。

なんとかしたくてググったら
svn -
0497デフォルトの名無しさん
垢版 |
2016/03/31(木) 20:52:02.87ID:+0lEOH/d
なぜかレスの後半が無視されたんで再ポスト。

http://superuser.com/questions/793877/git-grep-equivalent-in-subversion
これシェルスクリプトで書いてるんだけどうんと遅いし、
しかもこれファイルは指定できるけどディレクトリは指定できない。
もっとゴリゴリ書けばなんとかなるだろうけど、ますます遅くなるし、
そもそもsvn環境にこれ以上投資する気になれない。
お前らよく文句言わずにsvn使ってるな。
0498デフォルトの名無しさん
垢版 |
2016/03/31(木) 22:53:43.93ID:BCr365+9
> デザイナさんが svn のレポジトリに backup/yyyMMdd ってディレクトリ作ってて、
> アホかタグ使えよと思ってたんだけど
ちょっとわからん、タグってディレクトリだろ
0499デフォルトの名無しさん
垢版 |
2016/04/01(金) 10:00:23.40ID:Gbw1yNNY
>>499
すまん、デザイナさんはtrunkの中にディレクトリを作ってたんだ。
アホな説明で申し訳ない。
0501デフォルトの名無しさん
垢版 |
2016/04/01(金) 12:08:27.08ID:Gbw1yNNY
>>500
そう、それ。よく察してくれた。svn copy じゃないから履歴も残らない。
勘弁してくれと思ったけど、過去バージョンの検索性という一点はすぐれていたというね。

ちなみにGitにはcopyコマンドはない（はず）。
ファイルの内容から履歴は自動追尾されるから、ローカルファイルのcp で構わない。
デザイナさんとsvnについてやり取りするたびに、人類にはsvnは難しすぎるんじゃないかと思う。
まあGitになったらなったでまた大変だろうけどね。
0503デフォルトの名無しさん
垢版 |
2016/04/01(金) 12:33:56.70ID:Gbw1yNNY
>>502
それ、ローカルに ^/tags を全部 checkout なり export なりしてgrep しろって言ってる？
たしかにそれやればなんとか検索できるな。

でも時間もローカルディスク容量もすごく食うし、しかもタグに記録しなかった履歴は検索できない。
Git なら git grep 一発だし、GitHub ならWebブラウザで検索フォームに入力するだけだ。
0505デフォルトの名無しさん
垢版 |
2016/05/01(日) 13:51:53.90ID:tKi6j9CT
匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？

Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ


The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
ｔ
0506デフォルトの名無しさん
垢版 |
2016/05/11(水) 04:04:06.49ID:Qb9Kyo2I
ある文字列が過去のどのリビジョンに存在していたかを検索する場面が思いつかないんだけど、
そういう検索ができる環境が当たり前になれば、それなりの用途があるんだろうか。
0507デフォルトの名無しさん
垢版 |
2016/05/11(水) 04:13:47.14ID:Qb9Kyo2I
grep through revisions と書かれてたからそう思ったんだけど、 git grep にそういうオプションが見当たらず。
githubの検索でも普通のgrepの結果っぽいのしか出てこないし。
0509デフォルトの名無しさん
垢版 |
2016/05/12(木) 21:53:23.38ID:2OPIh6as
>>506
なんかのライブラリとかを利用してて、試行錯誤で色んな関数呼んだりやめたりみたいなこと繰り返してから、
1年後あたりに、うろ覚えだけど、関数名だけは断片的に覚えてる、みたいな状況になったら必要じゃない？

個人的には割とよくあるけどなー
0510デフォルトの名無しさん
垢版 |
2016/05/21(土) 19:36:12.99ID:ikuIjUYo
>>509
関数が存在した時間かソースファイルの手がかりがあったら現行の機能だけでも逝ける、
まあ検索対象が大量にあって一括で探したい、とかいう場合はあれば便利かもだが
0511デフォルトの名無しさん
垢版 |
2016/05/21(土) 19:59:25.28ID:af3CQIfx
なぁ、32bit windows 版の tortoise 1.9.4 って、中身のバージョンが、最新チェック用のバージョンと微妙に違くね？
0512デフォルトの名無しさん
垢版 |
2016/05/25(水) 03:31:32.94ID:V+i5yD5b
>>510
たとえば、特定のコミットだけに存在した文字列とかも探せる？その特定のコミットは大体しかわからない前提で。
あんまり使い込んでなくて質問してるんで、あったらすまん。
0515デフォルトの名無しさん
垢版 |
2016/06/18(土) 16:22:08.36ID:m/CduI6Z
tortoiseの完成度がピカイチなだけに残念だな。
hgもgitもGUIの使い勝手が悪すぎて、会社で提案しにくい。
みんなコマンドライン使えるわけじゃないからなー。
0523デフォルトの名無しさん
垢版 |
2016/09/16(金) 15:26:57.24ID:4+GkgAAn
誰か教えてください。
TortoiseSVNでブランチを作って切り替えて変更した後にトランクに切り替えると競合が発生します。
トランクとブランチは切り替えるだけでマージされてしまうものなのでしょうか？
切り替え前にコミットするとそうはならないみたいですが。
0524デフォルトの名無しさん
垢版 |
2016/09/16(金) 16:48:48.86ID:PpYmmEIW
ブランチを切り替えるということはリポジトリの最新をローカルに書き戻すということ
コミットしてない奴は上書きで消されても文句言えない
マージしてくれるのは親切
0525523
垢版 |
2016/09/16(金) 17:21:46.19ID:4+GkgAAn
>>524
なるほど。
そういう仕様だったんですね。
都度コミットするようにします。
ありがとうございました。
0526デフォルトの名無しさん
垢版 |
2016/09/16(金) 17:38:13.67ID:HeaYZHP4
truncに切り替えるとコンフリクトが発生するのなら、branchをtruncにマージするときにコンフリクトが発生するのではないだろうか
0528デフォルトの名無しさん
垢版 |
2016/10/15(土) 13:06:58.38ID:HoCogbfT
いきなり dev-MLに大量にメールが流れていて驚いた。

それから、1.9.5も近いうちに出そうだな。
0529デフォルトの名無しさん
垢版 |
2016/10/15(土) 23:40:59.99ID:f1QyDe2U
1.10はよ
0536デフォルトの名無しさん
垢版 |
2016/11/30(水) 18:38:49.43ID:jvdRD7Js
>>535
この中にも多くあるんでしょうけど、
Subversionでアクセスできるものがどれなのかがよくわからないです。
0537デフォルトの名無しさん
垢版 |
2016/12/01(木) 03:24:06.55ID:Xg6M044B
"svn checkout https" と引用符で括ってぐぐればFreeBSDとかTracとかWebKitとかのドキュメントがひっかかるやん
0538デフォルトの名無しさん
垢版 |
2016/12/17(土) 02:06:53.85ID:JwOXjuT1
branchの切り替えについて質問さしてください

branchを切り替える事で、通常なら「commit→trunkの更新」となるところが
「commit→branchへの更新」となる事は分かります

ただ、

my_project
└ trunk
└ branches

となっていてtrunkに対して新しいbrancを作って

my_project
└ trunk
└ branches
＿＿└ 20160304

というブランチを作った場合、いちいち切り替えるのではなく
myproject/branches/20160304 をcheckoutした上でそこを書き換えるのでは
駄目なんでしょうか？いまいち「切り替え」がどのような局面で
有効なのか良く分かりません
0539デフォルトの名無しさん
垢版 |
2016/12/17(土) 07:32:55.65ID:s55gxQDX
>>538
> myproject/branches/20160304 をcheckoutした上でそこを書き換えるのでは
> 駄目なんでしょうか？
いいんじゃねーの？
つか俺はそうしてる
0540デフォルトの名無しさん
垢版 |
2016/12/17(土) 11:02:29.80ID:lvQHWty7
>>538
別に構わないけど、SVNとは関係ないところで注意点が増える。
パス構成が変わると、動かなくなる（設定変更が必要になる）ツールとかが無ければ問題ないんじゃね？
0541デフォルトの名無しさん
垢版 |
2016/12/22(木) 13:54:51.65ID:WvV0KHxS
過去のリビジョンへ一部修正する手順が解りません
現在のリビジョン40 も修正したいリビジョン30の場合
こんな方法でやっいてますが多分違うと思います
正し手順を教えてください
1.TortoiseSVNでSVNコミット
2.TortoiseSVNでSVN更新
ここまででリビジョン40の退避
3.コマンドプロンプトを開いて
　del rm *.* ----リビジョン40を消す消さないと競合するから
4. svn update -r 30
5.エディタで目的の部分修正
6.TortoiseSVNでSVNコミット(変更の保存コメントに注意を書く）
4.コマンドプロンプトを開いて
　del rm *.* ----リビジョン41を消す消さないと競合するから
7.svn update -r 40 ---元の状態に戻す
0542デフォルトの名無しさん
垢版 |
2016/12/22(木) 15:57:13.16ID:LjoTcBUk
Tortoise使ってるなら、ログで戻したいリビジョンを選択して
「このリビジョンに戻す」で作業コピーがr30に変更した状態になるよ
0545デフォルトの名無しさん
垢版 |
2016/12/25(日) 16:45:31.50ID:hrxPaxO/
emacsは衰退しました
0546デフォルトの名無しさん
垢版 |
2016/12/25(日) 22:15:10.49ID:MeBxIn7r
>>99
> 共有リポジトリ

ん？

共有フォルダに作ったリポジトリ？

よく分かんないけど、何故、共有フォルダに作るの？

メリットは？
デメリットは？
0548デフォルトの名無しさん
垢版 |
2016/12/25(日) 23:05:16.79ID:MFByqkiI
なんでそんな前のにレスつけてんの・・・
ちょっと、この人こわい・・・
り、リポジトリはローカルに作ったらいいんですか? (震え声)
0551デフォルトの名無しさん
垢版 |
2016/12/30(金) 13:35:41.86ID:KB0M7zpX
2.0はよ
0554デフォルトの名無しさん
垢版 |
2017/06/19(月) 16:25:13.59ID:/CE3XBCp
hage
0558デフォルトの名無しさん
垢版 |
2017/07/08(土) 18:08:52.88ID:HDF4cM22
1.10はよ
0561デフォルトの名無しさん
垢版 |
2017/07/10(月) 01:42:39.22ID:BSqkgm0Y
中央集権型ってだけで選択されない世の中になっちゃったからなー。
0563デフォルトの名無しさん
垢版 |
2017/07/24(月) 01:15:45.56ID:+one8Pjd
>>562
リテラシーって言うより、単なる慣れってことかなと思うようになった。
svn知らない奴に最初っからgit叩きこんだら、そこそこ使うようなってる。
こうなると、新規プロジェクトで敢えてsvnって選択はしづらいな。
0564デフォルトの名無しさん
垢版 |
2017/07/24(月) 01:37:48.06ID:WzIYl6Yz
svnはvssに慣れた方々の受け皿だからね。
0566デフォルトの名無しさん
垢版 |
2017/07/24(月) 22:14:43.70ID:LnmIpSRU
>>565
今は、1.10.0-alpha3　がテスト中。

ただ、1.10 の正式版が出ると、1.8系が更新されなくなるから、痛し痒しだな。
0568デフォルトの名無しさん
垢版 |
2017/10/10(火) 17:52:38.07ID:NwdZ+7o1
質問です。

あるファイルをリポジトリに登録後、チェックアウトしてみたところ登録前後でMD5の値が異なっていました。
試しに登録元ファイルをチェックアウトしたファイルに上書きし、MD5を確認するとチェックアウト時の値と異なる（登録元ファイルのMD5の値と一致する）のですが、差分有りになりません。
そのため、コミットしようとしても更新対象なしとなりコミットできません。

登録前後でMD5の値が異なると管理上不都合なのですが、なんとかならないでしょうか？

環境は以下の通りです。
クライアント
・Windows7
・TortoiseSVN 1.9.7
サーバ
・OS不明
・Subversion 1.6.5
0570568
垢版 |
2017/10/10(火) 18:14:08.88ID:NwdZ+7o1
自己解決しました。
Windowsを再起動してリトライしたところ、正常に差分として扱われるようになりました。
またコミット後チェックアウトし直したところ、こちらも登録前のファイルのMD5と一致しました。
原因不明ですが、とりあえず対処方法がわかりましたので質問は取り下げます。
お騒がせしました。
0577デフォルトの名無しさん
垢版 |
2018/01/10(水) 22:29:07.52ID:842l83fs
トラフィックの関係でインターネット上にリポジトリ置く場合は分散型が多いでしょ
0580デフォルトの名無しさん
垢版 |
2018/01/14(日) 12:15:17.46ID:aMlZzyKb
ローカル相当部分にはgitでも使って、ユーザー運用で対応するようにしたほうがいんじゃね？
0581デフォルトの名無しさん
垢版 |
2018/02/16(金) 05:59:59.49ID:W1XJdyx1
☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
0582デフォルトの名無しさん
垢版 |
2018/02/22(木) 01:13:40.25ID:rGv3zdVM
>>577
CVS,SVNとか普通に主流だったし
だったらなんで最初から分散型じゃなかった？
主流が切り替わったんだろ
0584デフォルトの名無しさん
垢版 |
2018/03/18(日) 06:48:35.59ID:YqQ2Wn9T
1.10やっとrcか…
0585デフォルトの名無しさん
垢版 |
2018/03/30(金) 13:27:44.40ID:6JWJbyA4
>>477
ホスティングサービスってどこがいいの？
ググってみたが多すぎてどこを選んだいいのかわからない
GitならとりあえずGitHub なんだろうけど
0586デフォルトの名無しさん
垢版 |
2018/03/31(土) 00:50:56.23ID:sRW3fSr8
>>585
安くあげるなら、XP-Dev.com とか。多重バックアップで安心を買いたいなら、beanstalkapp.com とか。
0587デフォルトの名無しさん
垢版 |
2018/04/05(木) 17:47:09.06ID:vDjQAkfg
TortoiseSVNで、開発ブランチをtrunkにマージしたあと、
trunkのログを表示させて、「マージされたリビジョンを含める」をオンにすると、
その開発ブランチ内の一部のログが、マージしたリビジョン番号の下にグレーで表示されず、
元々のリビジョン番号のところに黒で表示されることがあります。
マージのしかたがおかしいのでしょうか。
0588デフォルトの名無しさん
垢版 |
2018/04/06(金) 12:25:36.07ID:sTfZcU1Y
マージとはそういうものじゃなくて？
0589デフォルトの名無しさん
垢版 |
2018/04/06(金) 20:32:30.61ID:ilK+V1oX
そうなのですか？
大抵の場合は、マージしたリビジョンの下に
ツリーのようにぶら下がって表示されるのですが。
0593デフォルトの名無しさん
垢版 |
2018/04/19(木) 09:36:53.61ID:YT7DeGLC
Windows上の共有フォルダで「file:」でTortoiseSVNを使っている場合、
1.8と1.9と1.10は共存できますか？
共存できたとしても、なにか制限とか出てきますか？
0596デフォルトの名無しさん
垢版 |
2018/04/19(木) 20:34:14.80ID:t8CtE0gw
gitの場合は、リポジトリの中身がハッシュエントリベースのようなので、競合事故がなさそうなだけまあマシ。

個人的にはやらないけども。
0598デフォルトの名無しさん
垢版 |
2018/04/19(木) 22:41:27.31ID:t8CtE0gw
ニュアンスが違うぞ。そんな前向きさは一切ないだろ。

>FSFSリポジトリはネットワークフォルダー上に配置でき、file://プロトコルを用いて複数のユーザーからアクセスできますが、これは絶対にお勧め しません 。
実際のところ、このような使い方を私たちは思いとどまってほしいと強く思いますし、様々な理由からサポートもしません。
0600デフォルトの名無しさん
垢版 |
2018/04/19(木) 22:55:24.05ID:NI/UICUh
>>598
でも保証しないとは言ってないだろ
お勧めしないのはアクセス権限の話とかリポジトリのフォーマット更新の話もあるから
0602デフォルトの名無しさん
垢版 |
2018/04/20(金) 11:00:21.09ID:WJk0jxxj
>>599
ローカルにワーキングとは別にリポジトリのディレクトリ造っておいてそこを同期すればいい
0603デフォルトの名無しさん
垢版 |
2018/04/20(金) 12:29:34.25ID:DDZisBas
>>601
保証する
なんて誰も言ってないけど？
ム板なんだから「保証しないとは言ってない」が「保証すると言っている」とは違うことぐらいは理解しようよ
0606デフォルトの名無しさん
垢版 |
2018/04/23(月) 14:29:16.78ID:MXZbsWja
数年前だけどメルコのルータの簡易NASのファイル共有で使ったことがあるけどユーザ一人でも数日ごとにリポジトリ壊れて使うのあきらめたよ　NASがFATだったからかもしれないけど
0608デフォルトの名無しさん
垢版 |
2018/05/23(水) 19:40:29.97ID:Au5e7VGg
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

PNRFF
0611デフォルトの名無しさん
垢版 |
2018/07/04(水) 22:10:38.53ID:gFgZc5FG
035
0616デフォルトの名無しさん
垢版 |
2018/08/05(日) 19:15:47.48ID:2n69scci
13番線ホームのトイレみたいな書き方すな
0623デフォルトの名無しさん
垢版 |
2018/11/02(金) 09:08:28.68ID:O6G1y9wB
shelvingもどんなもんか使ってみたいからそろそろバージョンアップしてみるか
0627デフォルトの名無しさん
垢版 |
2019/03/11(月) 20:58:55.41ID:xN8s52Z7
自分の開発チームはsubversionを当面使うだろうな。
gitの良さと使い方教えてくれる人が身近にいれば移行が進むかも。
そもそもコミット履歴は移行できるのかな？
0630デフォルトの名無しさん
垢版 |
2019/11/13(水) 15:24:40.80ID:DY0CuYIv
TortoiseSVNのアイコンオーバーレイ機能がOneDriveなどと競合するので、
レジストリエディタを使ってTortoiseSVNの項目にスペースを入れて先頭に移したり、
ShellExViewを使ってOneDriveなどのものを無効にしたりしてみたのですが、
相変わらずいくつかの状態のアイコンが表示されません。
ネット上にあるこれらの方法は、最新のWindows10では使えないものなのでしょうか。
0631デフォルトの名無しさん
垢版 |
2019/11/13(水) 15:34:12.22ID:OceCV+VL
OneDriveをアンインストール
0632デフォルトの名無しさん
垢版 |
2019/11/14(木) 12:47:59.52ID:8sqJyoq5
>>631
OneDrive自体も使っているんです。
アイコンはTortoiseSVNのほうを優先させたいという希望です。
0633デフォルトの名無しさん
垢版 |
2019/12/13(金) 21:17:54.95ID:qgPSBtfa
エクスポートしたらゴミファイルがいっぱいコミットされてるぞ！つって怒られました
バージョン管理なしのファイルがローカルにダウンロードされるぞ、という認識だったのですが
どういうことなのか教えていただけますか
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況