>--- Forwarded mail from [EMAIL PROTECTED] >> > > No. Not on extension, but based on *regular >> expressions*, or at least >> > > shell-style pattern matching expressions. >> Extensions are too >> > > simplistic. (c.f. CVSROOT/cvswrappers, CVSROOT/cvsignore) >> > >> > Extensions would work fine, pattern matching is overkill. >> >> Neither is suitable or sufficient. >> >> The actual type must be explicitly recorded in every delta, >> or at least >> the initial delta and every delta following a "dead" delta.
>on earth, extension matching would be fine. Unless you have rogue >developers that "try" and break the system by changing file formation while >keeping extensions the same (save it as a jpg, but it is really a gif >format) you should not have a problem. If you do have rogue developers, or >even developers that can't follow simple instructions such as "hey, if it is >not a jpeg then don't save it as a jpeg!" then you have much larger >problems. >ie. maybe the inmates of San Quinton do not make the idea >development team. I think Greg's point here is that there are times when a file is removed and later replaced with a new one that contains a different type of data. Case in point: ASCII text file names foo.doc is replaced by a Microsoft Word document containing the same content and is stored with the same name. It could be argued that this practice is unsound, but it does happen. There's no good solution to this problem using the current CVS design, but Greg suggests a workaround that works well enough in some common cases. There are other times when the data type is the same but the content is completely unrelated, in which case the diff/merge should be avoided altogether. But CVS punts this scenario. >--- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
