10/08/02 01:15:46
名前欄残ってた＾＾；
767:デフォルトの名無しさん
10/08/02 10:28:23
>731も関係者なのかと思ってしまったじゃないかw
某品川方面のSIerで>763のような運用をしているらしい噂を耳にしたことがあるけどビンゴ?w
768:デフォルトの名無しさん
10/08/02 10:31:51
私が上司ですがなにか
769:デフォルトの名無しさん
10/08/02 10:48:31
>>768
今すぐ、死んでください。お願いします。
770:デフォルトの名無しさん
10/08/02 10:55:43
あなたと、一緒なら
771:デフォルトの名無しさん
10/08/02 11:04:02
誰にも迷惑を掛けることなく孤独に死ね
772:デフォルトの名無しさん
10/08/02 18:39:03
アホな部下など信頼できん。Subversionもだ。ロック第一。
今すぐ信頼と安心のVSSに切り替えろ。
773:デフォルトの名無しさん
10/08/02 19:58:07
今更VSSなんかに戻れないと個人的には思うけど、
763みたいな運用ならVSSの方が向いてるな。デフォルトでロックだしね。
774:763
10/08/03 00:37:11
今日も来ましたよ。
幸い？branch側に行く人で、ロック持ってる人はほとんど居ませんでした。
あと二ヶ月これで我慢して回しながら、（まだこれから一年近く続く）
10月以降の次フェーズ開始までに何とか軌道修正したいです。
しかしながら、修正はシリアルに、という考えが根強い様です。
マージの概念がピンと来ないみたい。（特に年寄り）
ソース持ち出しての開発もしている様なので、今後 >>641の様な
事故が発生する懸念も・・・。末端まで教育が行き渡るかどうか・・・。
>>767
んー、ハズレです。もっと南ですね。
>>773
最初は「信頼と安心」のVSSも選択肢としてあった様でした。
しかし、導入費用をケチるというセコさ。
775:763
10/08/03 10:16:43
需要は無いと思うけど，今回Lock関連でわかったことまとめ。
・svn copyでLockは外れる。
ブランチ先およびタグからはスッキリ外れます。
合法？に外したい場合は悪用できるかも。
・hotcopyで取得したバックアップリポジトリに対してはロックが維持される。
まあ，当たり前か。
・synsyncで同期するSlave側にはロックが渡らない。
Slaveを2つ立ててMasterから5分おきにsyncしてますが，
ロック情報は同期されません。
(copy-revpropsで出来る？ 試してません。)
Slaveを使用して復旧する際には注意ということか。
776:デフォルトの名無しさん
10/08/03 10:37:04
品川より南なら大田区かな？
マージが理解されていないというのにそこまでしてSubversionとブランチとロックを使うか？
運用見直しの機会と持ち出しもあるというのなら>>739や>>720のようなミラーを作った方が良いと思うが。
DVCSのマージの方が直感的だし。
777:デフォルトの名無しさん
10/08/03 16:07:28
svnsyncを使ってGoogleCodeのリポジトリをローカルのリポジトリへ複製しようとしましたが、
コマンド実行後にコマンドプロンプトが固まってしまいます。どうして？
svnは、TortoiseSVN1.6.10についているのを使っています
778:デフォルトの名無しさん
10/08/03 16:10:50
田町とかでないの？
copy元のロックも外れちゃうってこと？ロック使わないけど、それってまずいんじゃないのかな。
779:デフォルトの名無しさん
10/08/03 16:24:00
>>778
田町は品川より北。
品川と言っても品川駅は港区。
品川駅より南というと品川区も入る。
780:デフォルトの名無しさん
10/08/03 16:49:25
品川駅より南って誰が言ったのさ？
781:デフォルトの名無しさん
10/08/03 16:55:36
>>780
誰もいっていないけど品川っていうと品川駅のことを言うから混乱する。
あと目黒駅も。
782:デフォルトの名無しさん
10/08/03 17:36:06
tortoiseSVN で svn-commit.tmp を current directory 以外(例えば /tmp) に
作らせる方法を教えてください。
よろしくお願いします。
783:デフォルトの名無しさん
10/08/03 18:40:44
目黒駅は品が沸く
784:763
10/08/04 01:18:34
品川で盛り上がってるところ悪いけど、スルーするよ。
>>776
開始当初にsvkをほんの少しだけ検討したけど、時間切れ。
Subversionならみんな知ってるから、という理由でstartし今に至る。
まあ、eclipseでjavaだから、自然にその方向になったと思う。
個人的にはMercurialに興味ありですが、移行も含めて運用を
切り替えるのはちょっとキツい。Trac＆postgresqlも連携させてるし。
>>763では大げさに書いてしまったけど、Heavyなロッカー達は
全体の1/4程度で、あとは、まあ、普通に運用してもらっています。
それでも「svn updateで作業コピーがファイルごと上書きされる」と思っている人とか、
「紛失」と出ても平気で無視した挙げ句、「フリーソフトは信用できん」とか言う人がいて
ネタには尽きません。(Linuxもsvnもeclipseもapacheもjreも全部「フリーソフト」と呼ぶ)
>>778
言葉足らずでした。copy元のLockは残ります。
それよりもsync先に渡らないのは新たな発見で、ライトスループロキシで
負荷分散構成するときはロック禁止にしないといけないことがわかった。
785:デフォルトの名無しさん
10/08/04 07:34:27
>>784
別に一気に別のDVCSに移行する必要は無い。Tracと連携しているのならなおさら。
オープンソース界隈ではマスタがsvnでもクライアントはgit/hgというのはごく普通。
でも最初のcloneが重いってことでgithub/bitbucketにミラーがある。
svnが更新されたらgit/hgも更新される。
そうすれば各人好み・得意のVCSを使える。
完全移行のタイミングは？というとsvnで言うところのブランチを切るタイミング。
新ブランチはgit/hgで旧ブランチはsvnという感じ。
openofficeがこんな感じだった思う。svnじゃなくてcvsだったそうだが。
そうすればTracでの管理も辻褄が合う。
786:デフォルトの名無しさん
10/08/04 15:36:28
>>784
コピー先にまでロックがかかると思った理由が分からないし
コピー先でロックが外れていることを悪用できそうだと思う理由も分からない
> branchからtrunkへのマージ作業がなんか面倒くさそう
変な親切心でbranchとtrunk両方にコミットする人がいなければ楽にすむよ。
普通にやればいいだけ。