09/04/03 15:26:19
>>706
それはある程度やっておりますが、そういう個人ごとのファイルを中途半端に
バージョン管理したいのです。設定項目が増えたりしますから。
今は、設定項目が増えたりするときは、メーリングリストで通知しています。
もっとうまい方法がないかと思うのです。
708:デフォルトの名無しさん
09/04/03 16:44:32
コミットのトリガーで動く前処理スクリプトか、
svnの代わりに呼ぶラッパー作れば？
709:705
09/04/03 17:27:21
>>708
それはいいかもしれませんね。
ただ、コミットのトリガーだと、ユーザ環境では「変更されたファイル」とし
て扱われてしまうし、
svnの代わりのラッパーは、ユーザのOSやクライアントソフトの種類が多くて難
しそうです。
710:デフォルトの名無しさん
09/04/03 18:18:09
>>705
分散型なら各自の設定ファイルもバージョン管理できるだろうけど、
それだけの為に分散型にするのはどうだろうね。
あなた一人だけでやってるなら頑張って使い方覚えればおkだけど。。。
antとかrakeみたいなので設定ファイルをジェネレートするようにしたほうが
適してるかも。
711:デフォルトの名無しさん
09/04/03 18:46:32
xmlでもiniでもconfigでも、拡張子の後に更にsampleとか拡張子付加して管理してる
使う側が勝手にマージしろって感じに
712:デフォルトの名無しさん
09/04/03 18:47:42
んでコミットされないようにignoreにも登録
713:705
09/04/03 19:13:18
>>710
おっしゃるとおり、当分はSubversionから離れることはできないでしょう。
分散型については将来に備えて知っておきたいと思っています。
ant や rake については、毎回ユーザが設定値を与えるならわずらわしいし、
値を保持するなら、その値をどうバージョン管理するかという話に。
>>711-712
それはTortoiseSVNのチュートリアルが推奨している方法ですね。
（サイトが落ちているようなのでキャッシュ）
URLﾘﾝｸ(72.14.235.132)
うちもそうしているのですが、テンプレートが更新されても気づかないんです。
ユーザにマージさせるのに、メーリングリストで通知することになります。
714:デフォルトの名無しさん
09/04/03 20:13:50
別にそれで良くね？
あとはpost-commitにでも特定のファイルがコミットされたら
注意しやすいように、分かりやすくなるようにスクリプト書くだけじゃん
715:705
09/04/03 21:08:44
>>714
なるほど、テンプレートファイルが更新されたら、自動でMLにメールを投げる
とかですね。
結局、その辺に落ち着くしかないのかもしれません。自分の当初のアイディア
も、例えば設定項目が増えた場合、その増えた値を個々のユーザに書き換えて
もらう必要があるなら、通知が必要なようですし。
716:デフォルトの名無しさん
09/04/04 01:09:39
>>705
うちはgit使ってるけど、
- ベースとなるブランチをmasterとする
- ホスト毎にそのホスト固有の修正を行うブランチを用意(host/foo, host/bar, ...)
- masterに更新があった場合はgit rebase master host/fooとして各ホスト用データを更新
としてる。
717:デフォルトの名無しさん
09/04/04 08:47:23
>>716
便乗質問させてください。
その場合は、ローカルの仕事を本家にcommitしたいときはcherypickするのでしょうか？
そのままmergeしちゃうとホスト固有の部分も区別なくmergeされちゃうので、
まずいですよね。
718:716
09/04/04 16:29:32
>>717
そもそもhost/fooではホストローカルな修正しかしないので、masterにそういう修正を持っていくことはないよ。
masterに持っていきたくなるような修正はmasterで作業すれば良いんだし。
それでも誤ってmasterで行うべき作業をhost/fooでしてしまうことはあるかも知れない。
そういうときは
- まだコミットしてないならgit checkout -m masterでブランチ切り替えて作業継続。
- 既にコミットしてたらmasterで該当コミットをgit cherry-pickしてから
ホストローカルなブランチではgit resetやgit rebase -i masterで該当コミットを抹消。
としてる。
719:636
09/04/07 02:47:46
ファイル構成が大幅に変わってpatchがあてれなくなっていたので更新した
720:デフォルトの名無しさん
09/04/07 04:04:43
gitでhttp:/server/proj.gitからコミットasdf1234....を取りたい
んだけど、どうやればいいの？
全部取ってrevertを使ってみたが訳が分からん。
あまりに説明が無さ過ぎて泣ける。
721:デフォルトの名無しさん
09/04/07 10:35:04
全部取ってるなら
git checkout asdf1234
でいいんじゃないか？
722:デフォルトの名無しさん
09/04/07 18:42:00
>>713
各自用のバージョン管理しないローカル設定ファイル(ignoreされる)を
用意して、テンプレート設定ファイルの各値を上書きするように
ビルドツールを組んで、実行環境が構築されるようにしてやってるよ。
この場合、テンプレートにローカル設定がマージされるので、
ローカル設定ファイルの内容は古くても動く可能性がある。
もし各環境用の設定も全てあなたがメンテしないといけないなら、
各環境用にブランチ作るとかかなー
723:デフォルトの名無しさん
09/04/08 02:47:45
tracがパッケージとして既にあるubuntuか
安定性のcentosか
どっちでリポジトリ関連の鯖たてようかなあ
724:デフォルトの名無しさん
09/04/08 08:56:58
ubuntuのパッケージって結構古いのばっかりじゃなかったっけか。
あと日本語化するならapt使って入れるのはやめといた方がいい希ガス。
725:デフォルトの名無しさん
09/04/08 21:34:44
Ubuntu,Debianはbackportsで多少新しいのが入る。
CentOSはrpmforgeで同様に。
日本語化するならtracをいったん入れる直前までやってtracに必要なパッケージをメモって、
で必要なパッケージを入れて、日本語版Trac入れる、かな。
あと、ちょいとスレ違いなので、Tracの話題ならこっちの方がよいかと。
【バグ管理】 BTS使ってる？【追跡ﾞ】 ２
ｽﾚﾘﾝｸ(tech板)l50
726:デフォルトの名無しさん
09/04/08 23:25:22
メッセージ翻訳担当募集
URLﾘﾝｸ(groups.google.com)
＞なぜかリリースノートには記載されていないのですが（笑）、
＞一応 Mercurial 1.2 版からヘルプ類が日本語化されています。
＞しかし、ちょっと試してみればお分かりのように、まだまだ翻訳網羅率が
＞高くありません。とはいえ、数が数なので、私1人の翻訳では、流石に
＞ペースアップにも限界があります。
727:デフォルトの名無しさん
09/04/09 02:51:34
>726
日本語のmanがかなり古いんだが、そろそろ更新しないのかな？
mercurial wiki上に有るんなら俺が訳してもいいんだが。場所違うし。