CVS, specially, running the CVS server on the dev machine, and invoking the CVS client on the production box. Sure, it might be overkill, but not only do you get to do what you want, but you also get a code repository and the ability to develop on several boxes if possible.
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
| [reply] |
One does not need to use CVS for version control. I used RCS and RCS.pm last year. I found RCS.pm to be very reliable even though it is several years old and only has a version number of 0.09. RCS.pm allowed me to use Perl to script various repetitive changes to the controlled files.
But I wonder whether version control is a complete answer for two files which have not previously been under version control and so may no longer be n'sync. Rather than saying "bye, bye, bye" to one of the two files I would use diff or a similar file compare utility to actually look at the two files. Then after unifying any unwanted forks in the development path I would put the whole shmear under version control.
| [reply] |
For development code, version control is definitely The
Right Answer. For data files look at rsync. | [reply] |