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