[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[mhc:00489] Re: mhc-cvs.el
>> On Mon, 17 Apr 2000 01:59:36 +0900
>> nom@xxxxxxxxxxxxxxxxxxx (Yoshinari NOMURA) said as follows:
>実は僕も最初、この方法を考えました。面倒な事は CVS やその下の
>SSH が全部やってくれそうなので、楽ですよね。
そう思います。そのほかの利点として、スケジュールの変更履歴を完全に保持
できるのも魅力ではないでしょうか。
ただし、現行のように MH 形式でスケジュールを管理していると、CVS 管理さ
れるファイル数が異様に多くなることが予想されるので、レポジトリの管理が
うっとうしくなるかもしれない、という危惧はあります。月単位で mbox 形式
にする、というようなのは駄目でしょうか?
>あと、もう一つ考えてるのは rsync での同期です。
独自に同期システムを持つ場合には、複数のシステムで同時にスケジュールを
変更して conflict が発生した場合に、それを解消するシステムも用意しなけ
ればなりませんから、非常に厄介なことになると思います。
>PDA (Palm) とかが間に入って来ると、もうちょっと考えないといけな
>いかな、と思ったりしています。最後は、いわゆる Palm とかがやって
>いるのと同じ方法での同期。
えーっと、私は ruby が読めませんし、PDA も使っていないので、ちょっと良
く分からないのですが。
mhc2palm は、CVS レポジトリからスケジュールのローカルコピーを作成して、
それを使って Palm に送信するように変更します。そして、palm2mhc は、
Palm から受け取った変更点についてローカルコピーに反映してから CVS レポ
ジトリに commit する、というように実装すれば特に問題はないのではないで
しょうか。
>ところで、CVS で conflict が起こったときはどうしましょうか。
これは、どの程度、頑張って処理するかという設計方針の問題になってくると
思います。きちんと面倒をみるなら、conflict が発生したことを検出して、
修正してもらうためのフロントエンドを MHC で提供するべきでしょう。手を
抜くなら、とりあえずは既存の pcl-cvs などを活用すれば良いのではないで
しょうか。
それと、MHC 自体も CVS 管理に移行されませんか? CVS 管理の方が、作者の
方の労力も節約できると思うのですが…。
--
土屋 雅稔 ( TSUCHIYA Masatoshi )
http://www-nagao.kuee.kyoto-u.ac.jp/member/tsuchiya/