> 1) CVS's handling of binaries is a bit fragile, in that it's > fairly easy to accidentally lose the "-kb" setting. If that > happens, subsequent commits will put garbage revisions into > the repo (subsequent updates of older revisions, which were > committed correctly, will yield garbage working files, but > that's recoverable; the garbage commits aren't). > I've never actually seen this happen. I have seen people forget to add the -kb flag when adding new files but this can be managed successfully by greating a CVSROOT/cvsrwrappers file which covers all the extensions you will be handling.
> 2) CVS can't automatically merge changes. This matters more or > less depending on (a) how frequently the files change (hence > the gif vs. spreadsheet discussion), and (b) how hard it is > to merge changes manually, or through semiautomatic tools > external to CVS. > This can be a bit of a problem. Using watches and cvs edit makes things bearable in this respect. > > 4) As you noted, deltas for binary files tend to grow more > quickly than those for text files, since the former don't > "diff" as well; thus, the ,v files get bigger, faster. > Personally, I don't really care; disk is cheap. But others > have different circumstances. > There is one other thing to consider about this. To do operations on the ,v files CVS reads them into memory. As the file gets larger so does the demand on your CVS server. As long as you don't have really large files that change a lot you should be okay with this for a while. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
