Well, it’s harmed me at least. Consider the case where you’re editing files on a ‘remote’ machine prior to committing them via a central machine ‘closer’ to the CVS repository(*).

Consider the following: you cvs update, rsync ‘away’ to another machine and do some editing there, cvs update again (whoops), then then rsync ‘back’ (disaster). You’ve now got ‘CVS/entries’ that say you’ve got the most recent files on the central system, but you’ve actually just rsync’d old versions of the files back. CVS will think you’re trying to ‘un-modify’ all the files back to where they were when you first CVS updated.

If you always keep the CVS meta files with the files they relate to, that sequence of events will simply result in CVS complaing you have state files.

Trust me. If you think you can simply just remember where you are and always update/sync in the right order, you’re kidding yourself. If you’re rsyncing checked-out CVS trees, its far too easy to mess up: blow the cost: sync your CVS meta data!

(*) pserver seems like a solution here, but consider the case where you need to test code on more than one platform *before* committing the code.

from my development server to the live server where the paths are the same.

I list a bunch of files in rsync-exclude.txt like images used only in production, files like CHANGELOG, etc. This file gets added to my CVS repository with each project.

I don’t use the –cvs-exclude because i tag my project before a release/upload and `cvs export -r TAGNAME project` so you won’t have CVS/ directories, etc.

The -n option is great and I encourage you use it before running it without. It will print you a list of all the files it wants to upload, allowing you to double check that you are about to upload anything by accident.

http://www.cis.upenn.edu/~bcpierce/unison/

It’s for synchronizing and also implements the rsync-algo for efficient bandwidth usage.

Try this link for a nice shell script and a modified version of rsync that can handle HFS+ resource forks. .