アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
ソースコードの管理方法 (スコア:0)
そんな俺はソースコードのフォルダにBAKって名前でフォルダを作ってその中にソースぶち込んで終わりだったりする
あとは必要に応じてBAKhogehogeとかにしてさらにフォルダを作ったりとか
ちなみに世代管理とかしてないです
したほうが便利なのかなと思いつつ、過去のものはなかったことにしてます^^
それから圧縮も一つにまとめたりとかもしてないな・・・
んでバックアップはソースを入れるフォルダごとDVD-RAMとかの各メディアに同期させてます
Re:ソースコードの管理方法 (スコア:1)
>そんな俺はソースコードのフォルダにBAKって名前でフォルダを作ってその中にソースぶち込んで終わりだったりする
>あとは必要に応じてBAKhogehogeとかにしてさらにフォルダを作ったりとか
>ちなみに世代管理とかしてないです
複数人でのプロジェクトだと
・メール通知を設定すれば、commitログで誰がどのソース弄ったかがわかる。
・利用者全員がリポジトリをまとめてチェックアウトしていれば
(一人のHDDや最悪サーバのリポジトリが飛んだ場合でも)ほかの人のHDD内に
自分の成果物が残っていることが期待できる。
という点でそれなりに安心できる、という利点がありました。
もちろん、「commitログに変更内容を必ず書く」とか
「ある一定タイミングでかならずチェックアウトする」とか
運用ルールを決めておく必要があり、それが守られているなら
という前提はありますが。
個人の小規模プロジェクトでcvsの環境をそろえようと思うと
それなりに面倒なので、やっぱり「ディレクトリごっそり.BAKでいいや」
になりますね。
# 正直「ソース管理ツール」として便利というよりも、
# 「チーム内での意思疎通ツール&自分用メモ」
# という側面が強かったのかも。
『それも私がやれと?』
BAK屋さんはRCSをどうぞ (スコア:0)
という辺りで悩んでるかたならば、
ちょうどいい落としどころはRCSだと思います。
CVS/SVNと違ってリポジトリをいちいち建てなくていいし。
(./RCS/ってフォルダを掘るのが正式だが、それも面倒ってなら、それすら無くてもいい)
ci file1.xxx
ってやると、
(そのファイルのためだけの)バージョン保存ファイルが
RCS/file1.xxx,v
ってファイル (RCS/を掘ってなければ ./file1.xxx,vになる)
が出来る。それだけ。
以降はこのファイルが順次大きくなってくだ