09/07/17 22:58:44
複数案件を、検証用サーバ、本番サーバに順不同でリリースしたい場合の例ってどこかにありますか？
具体的には、検証用サーバには案件A Bの順でリリースしたが、
本番サーバには案件B Aの順でリリースしたい場合です。
現在のリポジトリ構成
trunk 検証、本番
branches
案件A
案件B
のような感じです。
651:デフォルトの名無しさん
09/07/17 23:07:45
「リリース」でSubversionで何をしたいのかがわからん
652:デフォルトの名無しさん
09/07/17 23:15:40
各サーバで普通にチェックアウトするだけじゃないのか
653:デフォルトの名無しさん
09/07/17 23:49:17
>>650
もう少し解りやすく質問してお願い。
654:650
09/07/18 01:58:14
言葉が足りずすみません。
既存システムの修正を行おうとしています。
修正の内容が2種類あり、それらのリリースタイミングが異なるため、別のブランチを作成します。
リリースはtrunkにマージしたものを本番サーバに配布することを指しています。
また、それぞれの案件が同じファイルを修正する可能性もあります。
検証用サーバを挟まない場合、
1 trunkをコピーして、A Bブランチを作成
2 (Aをリリース) Aをtrunkにマージ
3 (Bをリリース) trunkの変更をBにマージ後、Bをtrunkにマージ
という流れでいけると思っています。
しかし、検証用サーバを挟み、本番サーバへBを先にリリースしたい場合、
1 trunkをコピーして、A Bブランチを作成
2 (Aを検証用サーバにリリース) Aをtrunkにマージ
3 (Bを検証用サーバにリリース) trunkの変更をBにマージ後、Bをtrunkにマージ
4 (Bを本番サーバにリリース)
とやってしまうと、Bを先に本番サーバへリリースを行おうとした時に、BのブランチにはAの内容が
含まれた状態になっているため、Bのみの内容を抽出することが難しいのではないかと懸念しています。
伝わるでしょうか。。。
655:デフォルトの名無しさん
09/07/18 09:14:30
リリース直前に専用のブランチを作って、そこで切ったタグからリリースしてはどうでしょう。
リリース直前の修正はブランチで行い、trunkへのマージはタグ切ってリリースした後で。
そもそも、本番サーバへのリリース計画と異なる手順で検証用サーバにリリースするのが間違いのような。
いったい何を検証するつもりなんでしょうか？
656:デフォルトの名無しさん
09/07/18 10:06:40
>>654
なんでtrunkにマージすんだよ。
branchの先端をリリースしろ、馬鹿。
657:653
09/07/18 14:32:00
>>654 流れは大体合ってる。
>3 (Bを検証用サーバにリリース) trunkの変更をBにマージ後、Bをtrunkにマージ
ここの後半で競合が起きるかもってことかな？確かに起きる。
TortoiseSVNであれば、このときはBをtrunkにマージではなくって、ブランチを再統合するを選べばＯＫだよ。詳しくはtortoiseSVNのヘルプの4.20ブランチの再統合を参照してね。
尚、Bの変更内容だけを抽出したいなら、trunkの変更をBにマージした時点でのＢとtrunkとの差分をとればBの変更が抽出できる。
658:デフォルトの名無しさん
09/07/18 14:59:27
ありがとうございます。
>>655
確かに、同じファイルを変更する可能性があるため、後から検証サーバに配置したものについて、
厳密に検証が行えなくなることは認識しています。
専用のブランチというのは検証用サーバと同じ状態にあると見なすブランチということでしょうか？
>>656
Aブランチの先端をリリース、Bブランチの先端をリリースという順で行うと、同じファイルを変更した場合に
Aブランチの修正が消えてしまうのではないでしょうか。
>>657
競合が起きるのは仕方ないと思っています。TortoiseSVNの統合をもう少し見てみます。
Bの変更内容は確かにおっしゃる方法で抽出できると思うのですが、検証サーバでの修正を
どこにコミットすればいいのかが分かりません。
trunk(検証サーバの最新状態)に入れた場合、Bブランチに入れた場合ともに、Bのみの修正を抽出
しにくくなると思っています。
1 検証サーバの状態を保つためのブランチ(test)をtrunkから作成
2 (Aを検証サーバにリリース)
Aをtestにマージ
3 (Bを検証サーバにリリース)
Bから作業ブランチBsubを作成
Bsubにtestの変更をマージ
Bsubをtestにマージ
なども考えてみたのですが。。
もう少し考えてみます。
659:デフォルトの名無しさん
09/07/18 17:31:46
>>658
本番サーバと違うことを検証サーバでしようとするからおかしくなる。何のための検証サーバか。
開発スケジュールとリリーススケジュールがずれるのはいいとしても、
リリース時の手順はしっかり合わせた方がいい。
660:デフォルトの名無しさん
09/07/18 18:20:26
>>658
もっと単純に考えたほうがいいんじゃないかな。
trunk 本番
ベータ版ブランチを作成。ベータ版フィードバックをベータ版ブランチへ、その後trunkへマージを繰り返す。
最終的にtrunkからリリースブランチを作成。
661:デフォルトの名無しさん
09/07/18 21:28:25
そろそろうざいな。
必要なAの変更とBの変更をブランチだかtrunkだかにマージすればいいだけの話だろ。
ブランチ作成後にtrunkに変更を入れるのかどうか知らんけど、
リリースに必要な変更を全てマージすればいいだけの話。
ブランチが足りないなら、さらにブランチ作って、不要になったら消せ。
662:デフォルトの名無しさん
09/07/18 22:07:38
>>650
基本的には、本番環境にリリースする単位で検証しなければいけない。
branch作成後にtrunkにA,Bと関係ない変更を行わないという前提で考えれば、
1. trunkでAの修正を行う
2. branchBを作成し、Bの修正を行う
3. Aの修正が終わったら、trunkを検証にリリース（なぜこれを先にリリースする必要があるのかわからない）
4. Bの修正が終わったら、branchBを検証にリリース
5. branchBを本番にリリース
6. それと同時に、branchBをtrunkにマージ
7. マージしたtrunkを検証にリリース
8. trunkを本番にリリース
つまり、検証には三回リリースしなければならないということ。
663:デフォルトの名無しさん
09/07/18 22:19:23
>>658
それぞれのbranchでの変更は、そのbranchにcommitしろ。
マージはそのbranchがfixしてからだ。
664:デフォルトの名無しさん
09/07/18 22:20:27
>>659
> 本番サーバと違うことを検証サーバでしようとするからおかしくなる。
客からの要望が
・A Bをやりたいがどちらを先に本番リリースするかは決まっていない
・どちらも本番リリースすることは確実なので、対応できたものから検証サーバに配置して欲しい
というものなので、そうなってしまいました。
>>661
はい、必要なブランチを作成して不要になったら消そうとしています。
>>660 >>662
ありがとうございます。もう少し考えてみます。
665:デフォルトの名無しさん
09/07/18 22:27:15
１．branchAを作って、Aの修正を行い、検証サーバにリリースする。
２．branchBを作って、Bの修正を行い、検証サーバにリリースする。
３．branchA、branchBをtrunkにマージし、検証サーバにリリースする。
クライアントの要求に従って、（１、３）あるいは（２、３）の順でリリースする。
リリースの順番が早く決まるんなら、もう少し手順は省略できるが、わからないならこれしかないのでは。
666:665
09/07/18 22:34:05
どう実現するかを考えるのももちろん必要だけど、リリース順序をクライアントに決めさせる努力も重要。
文脈から、クライアントが行う受け入れテストの基盤を「検証サーバ」と呼んでるような気がするが、
リリース順序の決定が遅れる場合は、受け入れテストの工数が増大することをクライアント側に説明
しておく必要がある。二回の受け入れテストで済むものが、三回必要になるかもしれないということ。
まぁ、開発側も受け入れ側も、Aの検証を行い、Bの検証を行えば、AとB両方入れてもOKっしょ的な、
運を天に任せるというやり方でもいいけど。
667:デフォルトの名無しさん
09/07/18 23:42:47
そんなトロい客とSEは回帰バグで死んでしまえ。
668:デフォルトの名無しさん
09/07/19 00:00:04
どちらも最終的に必要なのに、どちらが先かわからないということは、同時に用意することになるんだね。
ならば、ＡＢ同時にやって条件ifで片方の機能を殺して提出する方が楽かもね。
669:デフォルトの名無しさん
09/08/02 09:23:05
先生質問です ノ
svn:keywords=Revと属性を付けておくと$Rev$を置換してくれますが、
あくまで、このファイル自体が変更されたタイミングですよね。
で、このファイルに変更が無くても、他のファイルをコミットするときに
置換して欲しいんですが、そういう方法ってありますか？
希望する動作：
a.txtは属性svn:keywords=Rev
b.txtは属性なし
b.txtを変更してコミット
a.txtは変更していないが$Rev:$が置換されている
リポジトリは共有フォルダ(必要があればsvnserveも変更可能)、
クライアントはTortoiseSVNです。
670:デフォルトの名無しさん
09/08/02 11:23:32
それくらい、バチファイルで組め
671:デフォルトの名無しさん
09/08/02 12:20:51
どっちかというと、変更して無いファイルをコミットするコマンドがあるのかに興味があるな。
672:デフォルトの名無しさん
09/08/02 16:30:59
変更すればいいじゃん
673:デフォルトの名無しさん
09/08/02 20:02:00
>変更して無いファイルをコミットする
単にタイムスタンプを変更したいってこと？
674:デフォルトの名無しさん
09/08/02 22:06:03
>>673 コミットログ書き忘れたときに簡単にログだけを追加したいと思うことがある。
675:デフォルトの名無しさん
09/08/02 22:33:56
>>674
svnadmin setlog でOK
676:デフォルトの名無しさん
09/08/02 23:16:06
>>674
最初っからそれを言えよ
677:669
09/08/03 12:08:06
>>670 >>672
・コミットはTortoiseSVNから
・チームで開発してる
・漏れを無くしたい(自動的に、確実に)
という状況／考えだったので、
クライアント側はTortoiseSVNの操作だけにしたいな、と思いまして。
私だけならバッチで良いんですけどね。
ちなみに目的は、各環境のDB構造のバージョンアップ(alter文とか)
の際に↓のようなsqlを最後に流して、
その環境に、どのrevまでの変更を適用したか
より確実に残しておきたかったんです（今は手動でrevを書き換えてupdate）。
--rev.sql--
insert into upd_rev(dt,rev) values(now(), '$Rev: 0 $');
とりあえず、フックスクリプトで出来るかやってみようと思います。
>>674
たまにそれやって空行追加して再コミットしてるｗ
過去の内容変えるとsvnの差分バックアップとか
svkのミラーリングに入らないしね。
678:デフォルトの名無しさん
09/08/03 13:28:39
>>677
rev.sqlのヘッダ部分に日付を手作業で入れておく。
他のファイルを修正したとき、rev.sqlのヘッダ部分の日付をその日に変更してコミット。
これでrev.sqlには常に最新のリビジョンが入るよ。
679:デフォルトの名無しさん
09/08/03 13:30:34
そゆのって、チェックアウト側でやるもんじゃないの？
チェックアウトして
svnversion でリビジョンを取得して、
rev.sql を自動的に書き換えて
ＤＢに流し込む
680:デフォルトの名無しさん
09/08/03 13:31:54
おっと、679 は >>677 へのレス
681:デフォルトの名無しさん
09/08/03 14:18:28
>>677
ログが空ならコミットさせないようにすればいいじゃん
682:677
09/08/03 19:29:22
＞他のファイルを修正したとき、rev.sqlのヘッダ部分の日付をその日に変更して
ここが自動でないなら、今まで通り手動でRev入れるのと大差無いので。
>>681
空でコミット流石にしないかな。書き忘れたことがある場合ね。
フックスクリプト試したけど、
pre-commitだとトランザクション名指定して内容書き換えるの無理っぽいし、
post-commitなら変更出来るだろうけど毎回２コミットになって論外・・・。
クライアントフックスクリプトじゃメンバーやPC変わったときに設定忘れてｵﾜﾙ危険があるので除外。
683:677
09/08/03 19:32:54
APIのリファレンス見つけたので、関数直接呼んでトランザクションの内容を
書き換えるプログラムを作ってみようと思います。
それをpre-commitから呼べばおそらく何とか。
URLﾘﾝｸ(svnbook.red-bean.com)
684:デフォルトの名無しさん
09/08/03 19:35:27
頭が悪すぎる
685:デフォルトの名無しさん
09/08/03 19:42:47
頭悪くて申し訳ないけど、良い方法が有れば教えて頂けると助かります
686:デフォルトの名無しさん
09/08/03 19:52:47
>>354と同じことをやりたいのか？
687:デフォルトの名無しさん
09/08/03 20:25:43
いえ、クライアント側の設定不要で自動的に書き換わっている（＝漏れが無い）のを求めていて、
置換自体は別に手間でないので。
688:デフォルトの名無しさん
09/08/03 20:34:07
ごはん食べずにお腹いっぱいになる方法、ありますか？
689:デフォルトの名無しさん
09/08/03 20:57:05
変えてないファイルのリビジョンをいじる必要があるのか考え直したほうがいいのでは？
690:デフォルトの名無しさん
09/08/03 21:08:35
>>677
よくわからないんだけど、
Excelで台帳作って、管理するとかじゃ支障があるものなの？
691:デフォルトの名無しさん
09/08/03 21:22:19
ねずみさんはひらめきました。
そうだ、猫の首に鈴をつければいい！
・・・で、いったい誰が？
692:デフォルトの名無しさん
09/08/03 21:23:42
管理はしたくない。
だって、管理し忘れたら意味無いだろ？
ってことか。
693:デフォルトの名無しさん
09/08/03 21:26:16
個人的にはチーム開発ほどコミュニケーションが重要だと思う。
機械で自動化したからOKみたいな乗りだとちょっと怖いな。
694:デフォルトの名無しさん
09/08/03 22:52:36
打ってるんじゃない、打たされているんだ
695:デフォルトの名無しさん
09/08/04 00:05:28
>>682
あれ？
だから、書き忘れないように空コミットを防ぐスクリプト使えばよくね？って話で。
もしかして書き忘れって部分的な書き忘れ？
696:デフォルトの名無しさん
09/08/04 00:13:51
そんで、本題の方だけど、DBに新しいレイアウトを適用した人が責任を持って設定するのではダメ？
もしくはalterなりなんなりのスクリプトをコミットするときにバージョン情報も更新するスクリプトを変更するようにするとか。
*.sqlがコミットされた場合に、version.sqlも一緒にコミットされていなければはじくスクリプトとかできるよね？
697:デフォルトの名無しさん
09/08/04 00:21:51
それを忘れた場合が困るんじゃね？
698:デフォルトの名無しさん
09/08/04 00:31:25
実際のDB環境環境と作業頻度みたいなのイメージがわかないから解らないが、ぶっちゃけどんぐらい大きさのなんだよ。
DB更新先が、10,000箇所とかあって、作業員も100人以上とかで並行作業で困ってるとかなら同情するが・・・
699:デフォルトの名無しさん
09/08/04 10:35:33
>>687
逆の発想で、アップデート時にリビジョン入りファイルを出力するのはどう？
TortoiseSVNを使っているなら post-update フックが使えるよ。
700:デフォルトの名無しさん
09/08/04 19:21:23
>>699
>>682
＞クライアントフックスクリプトじゃメンバーやPC変わったときに設定忘れてｵﾜﾙ危険があるので除外。
だって。
もうすべてきれいに忘れそうな勢い。ｗ
701:デフォルトの名無しさん
09/08/04 21:01:18
しかも相手にしているのは小児病のメンバーってか?w
702:デフォルトの名無しさん
09/08/05 00:48:28
TortoiseSVN のマージで PEG リビジョンを指定するにはどうしたらいいのでしょうか？
703:デフォルトの名無しさん
09/08/07 13:26:04
Subversion 1.6.4, 1.5.7 security release age
URLﾘﾝｸ(svn.collab.net)
> User-visible changes:
> * fixed: heap overflow vulnerability on server and client
> See CVE-2009-2411, and descriptive advisory at
> URLﾘﾝｸ(subversion.tigris.org)
704:デフォルトの名無しさん
09/08/07 13:29:18
TortoiseSVN 1.6.4 age
URLﾘﾝｸ(tortoisesvn.net)
705:デフォルトの名無しさん
09/08/07 17:05:52
>>702
マージダイアログでURLの後に“@番号”とつければいいのではないかと思います。
706:デフォルトの名無しさん
09/08/08 21:45:42
>>705
TortoiseSVN 1.6.4 で試しましたが、
「エラー: パス '/sandbox/!svn/bc/22/test/trunk@19' が見つかりません」
というエラーが出てきました。
707:デフォルトの名無しさん
09/08/10 14:27:27
>>706
“@番号”は使えなかったですか。失礼しました。
いろいろ調べたり実験してみたのですが、よくわかりませんでした。
[BUG] Merge dialog peg revisions
URLﾘﾝｸ(svn.haxx.se)
というスレがあるので、外人さんはPEGでマージしている予感があります。
もう少し調べてみます。
708:デフォルトの名無しさん
09/08/10 16:48:49
1.6.4 アイコンの色合いとか微妙に変わったね
709:デフォルトの名無しさん
09/08/10 17:34:56
Subversionに脆弱性
URLﾘﾝｸ(journal.mycom.co.jp)
1.5.6およびそれよりも前のバージョンと、1.6.0から1.6.3までのバージョンが影響を受ける。
対策が施されたバージョンは1.5.7および1.6.4。
710:デフォルトの名無しさん
09/08/10 22:54:49
Windows Server 2003
VisualSVN Server2.0.5
Windowsのバッチファイルでsvnadmin等のエラーが発生したかどうか
ERRORLEVELで判断することは可能ですか？
svnadmin hotcopy
if errorlevel 0 goto end
if errorlevel 1 goto error
svnadmin dump
if errorlevel 0 goto end
if errorlevel 1 goto error
いろいろググってみましたがそもそも値が返るのかもよくわかりませんでした。
711:デフォルトの名無しさん
09/08/10 23:29:17
svnadmin が終了コードを返すのかどうかは知らないけど
>>710 は errorlevel の使い方が間違ってる。
まちがい
if errorlevel 0 goto end
if errorlevel 1 goto error
正しい
if errorlevel 1 goto error
if errorlevel 0 goto end
他のやり方その１
if %errorlevel;%==1 goto error
他のやり方その２
svnadmin hotcopy || goto error
くわしいことはバッチファイルのスレで質問して
712:デフォルトの名無しさん
09/08/11 13:45:53
フックでハマタ＼(＾o＾)／
URLﾘﾝｸ(subversion.tigris.org)
> どうしてリポジトリのフックが動作しないの?
> フックは、外部プログラムを呼び出すことを期待されているんだけど、
> その呼び出しが、全然生じていないよう感じだ。
>
> Subversion はフックスクリプトを起動する前に、全ての環境変数を取り除く。
> その中には、Unixでは $PATHが、Windows では %PATH% が含まれる。
> 結果、スクリプトでは、絶対パス名の記述された他のプログラムだけを実行可能だ。
アドレスだけでいいから、テンプレに入れといて。
どおりで、PYTHONPATH設定しているのに、フックから見えないはずだな！
713:デフォルトの名無しさん
09/08/11 23:11:32
そんなことcrontab書いたことがあれば当たり前の話な訳だが。
714:デフォルトの名無しさん
09/08/11 23:52:08
svnのフックはcrontabじゃないわけだが
715:デフォルトの名無しさん
09/08/12 00:17:24
>>714
類似性に気付かないあたりが経験不足だな。
自分で痛い目に遭ったし人が痛い目に遭ってるのも見てるから、
crontabを挙げたくなる気持ちはよくわかる。
716:デフォルトの名無しさん
09/08/12 04:12:26
crontabもまあ似てるけれど、cgiの方で引っかかる人も多くない？
apacheはどのユーザとして動いてんの？っていうの。
広げてもしょうがない話ではあるけれど…
717:デフォルトの名無しさん
09/08/12 16:07:35
Windowsなら、
ユーザーの環境変数は使用できないけれど、システムの環境変数は使える
ってのが普通に予想される動作だろう
全ての環境変数を取り除くなんてのは、当たり前の動作じゃない
718:デフォルトの名無しさん
09/08/12 18:18:31
間違って変なものが動いてしまわないようにするのは良いことじゃん。
719:デフォルトの名無しさん
09/08/12 19:17:38
当たり前かどうかは人それぞれだと思います。
当たり前でない人のために、次のテンプレに >>712 を入れるのがいいと思います。
720:デフォルトの名無しさん
09/08/12 22:58:28
環境変数に依存するのもどうかと思うよ。
721:デフォルトの名無しさん
09/08/13 00:21:28
システムの環境変数ってのも改めて考えてみると気持ち悪いな
722:デフォルトの名無しさん
09/08/13 03:02:02
そう？/etc/profile も嫌？
723:デフォルトの名無しさん
09/08/13 12:20:44
環境変数って結局グローバル変数だよ。
どこで誰が書き換えたかわかったもんじゃないし
724:デフォルトの名無しさん
09/08/13 12:57:02
プログラム側でPATH=/binとかいちいち指定するつもりか
725:デフォルトの名無しさん
09/08/13 13:11:45
環境変数は親から子へしか伝播しないのだからグローバル変数ほど悪くないよ
726:デフォルトの名無しさん
09/08/13 13:13:21
気持ち悪いなと思ったのは
/etc/profile とかって確かにシステムワイドではあるけど
sh がそれを読み込むというだけだし
だったらログインシェルがないユーザだと
どーなんかと
「システム」の環境というのとはちょっと違う気が。
あとまぁ >>723 みたいなグローバル変数的なとこが気持ち悪いな。
727:デフォルトの名無しさん
09/08/13 16:48:11
>だったらログインシェルがないユーザだとどーなんかと
これ解らないで口出すとかネタだよな？
UNIX系じゃnologinのユーザ作ることあるけど
その場合の動きが解らんと言う事か？
728:デフォルトの名無しさん
09/08/13 17:05:27
svnで直前のコミットを取り消すにはどうしたらいんでしょ。
ファイル自体は元にもどしたくありません。
コミットした後で、いくつかのファイルが保存されていないことに気づいたのです。
git commit --amend みたいなものです。
729:デフォルトの名無しさん
09/08/13 17:07:02
取り消したいファイルだけコミットし直せ
730:デフォルトの名無しさん
09/08/13 18:05:27
>>728
よく有る話だけど、あきらめて残りをコミットしてログに「前のリビジョンとセットです。スマソ」と書いておけばいいんじゃないかな。
731:デフォルトの名無しさん
09/08/13 18:29:52
リポジトリのcurrentってファイルに書かれてるリビジョン番号を戻せば可能ではあるけど
非常にオススメできない。
732:デフォルトの名無しさん
09/08/13 18:40:53
極端な話、取り消すことができたとしても間違えて取り消したら取り返しの付かないことになるからね。あまりそういう機能は欲しくないな。
どうしても消したいなら、落ち着いてdump&loadするしか
733:デフォルトの名無しさん
09/08/13 19:09:02
ログインシェルが指定されてないユーザならshとか標準のシェルが呼ばれるだけだろ
(中身はcshやbashだったりするけど)
734:デフォルトの名無しさん
09/08/14 00:29:54
>>727
まさに nologin とか false だとどうなるんだろうと思ったのです
その場合 /etc/profile とか読まれないのだと思ってたけど
もしかして恥ずかしい勘違いだった？
735:デフォルトの名無しさん
09/08/14 11:38:51
>>729-732
サンクス
gitやhgだとできたけど、svnではできないのか…。なるほど。
とりあえず、>>730みたいに「すまそ」って書く方法でいきます。
BTSと連動はさせているから、チケットはコミットと複数関連付けできるし、問題ないのかもしれない。
736:デフォルトの名無しさん
09/08/16 17:14:35
ちっちゃいプロジェクトがいっぱいある会社には不向きだな
737:デフォルトの名無しさん
09/08/17 14:15:27
大変、困ったことがありまして、相談いたします。
以前、プログラムミスで (省略)\trunk\hoge\ というディレクトリを作るつもりで、
単体のファイル (省略)\trunk\hoge を生成して追加コミットしてしまいました。
その後、間違いに気づきそのファイルを消してコミットしました。
そして、'(省略)\trunk\hoge' というフォルダを再度作り追加しようとすると、
TortoiseSVNにて、
> '(省略)\trunk\hoge'
> は、異なる種別のノードに置換できません。'(省略)\trunk\hoge'
> を追加する前に、削除をコミットして親ディレクトリを更新しなければいけません
と言われて、hogeディレクトリとそれ以下のファイルを追加することができなくなってしまいました。
すでに、削除してコミットはしてあります。
リポジトリブラウザで見ましても、'(省略)\trunk\hoge' というファイルは見当たりません。
もしかして、svnではかつてあった同名のディレクトリを追加することはできないものなのんでしょうか？
738:デフォルトの名無しさん
09/08/17 14:21:51
>>737
ファイルの削除を、ファイル単体でコミットしたんじゃないかなー？
trunk を一回最新に更新したらいけるかもね。
739:738
09/08/17 14:22:35
>>737
あー、エラーメッセージの「親ディレクトリを更新しなければいけません」で言われてることだねぇ。
740:デフォルトの名無しさん
09/08/17 14:43:38
>>737
ワーキングディレクトリを更新するか
リポジトリからチェックアウトし直してみてください
741:737
09/08/17 15:01:00
>>738-740
親ディレクトリ更新したら、すんなり無事にいけました。
って、ちゃんとエラーメッセージに書いてあるじゃん！！… orz
ともあれ、皆さんありがとうございました。
>>738
そのとおりのようでした
742:デフォルトの名無しさん
09/08/18 21:37:38
SVN リポジトリからチェックアウトできるオープンソースプロジェクトの
ソースコードを自分のリポジトリのベンダーブランチにコピーしたいのですが
ファイル属性を含めて簡単にコピーする方法はあるでしょうか？
743:デフォルトの名無しさん
09/08/18 21:44:42
>>742ベンダーブランチに相手のリポジトリからマージ
744:デフォルトの名無しさん
09/08/18 22:45:58
リポジトリの位置が変わったらコマンドが使えなくなっちゃったんだけど
スマートに変わったよって.svnに教えてあげるコマンドって何かありますか？
745:デフォルトの名無しさん
09/08/18 22:50:32
>>744
多分、svn switch --relocate
746:デフォルトの名無しさん
09/08/18 22:51:13
たしか
svn switch --relocate ほげほげ
して
svn switch はげはげ
じゃなかったかな
747:デフォルトの名無しさん
09/08/18 23:22:12
Tortoiseの再配置/Relocateで行けそうです。
ありがとうございます。
748:デフォルトの名無しさん
09/08/19 13:00:06
TortoiseSVN 1.6.4の「競合の解消」変じゃね？
実行しようとするとウィンドウ出るけど、固まるよ。
749:デフォルトの名無しさん
09/08/19 16:24:23
Xcodeでsubversion(SCM)をつかうとき
ブランチをどのようにすれば切ることができるのでしょうか
750:デフォルトの名無しさん
09/08/19 18:14:13
>>743
ありがとうございます。
svn merge にそういう機能があることに気づきませんでした。
これならベンダーブランチも必要なさそうですね。
751:デフォルトの名無しさん
09/08/19 18:58:59
>>749
Xcodeでは出来ません
752:デフォルトの名無しさん
09/08/19 19:56:59
>>749
出来ますよ。
「SCM」「リポジトリ」でリポジトリパネを出して、
対象を選択後ツールバーの「コピー」ボタンをクリック。