Robin H. Johnson wrote: > Presently, the CVS interface scripts are always built, and their > test-suites run based on a binary named 'cvs' happening to return zero. > If there something other than the real CVS there, bad things happened > during the test-suite run. This explanation seems quite odd to me. Are you saying we can't rely on the 'cvs' name being "taken" and should live in fear that someone will implement an incompatible utility with the same name? Did that actually happen? I would find it easier to believe Building and testing git's cvs support is slow, because ... So give users with no interest in cvs interoperability a way out. By defining NO_CVS you can avoid this time-consuming piece of the build process. Or for a different patch: Add a NO_CVS knob so users with no interest in cvs support can avoid polluting their $(libexecdir) with unwanted entries. Or: Introduce a new NO_CVS knob. If set, the CVS interop scripts will be replaced by unimplemented.sh so sysadmins and distributors can hopefully get a nice, clear error report instead of confusion when users try to run them with cvs not installed. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html