Toby, thank you for including the patch. > Thanks Jonathan, I'll make your suggested change. My original intent > was > to have informative messages go to STDOUT and debugging info go to > STDERR but I'm not sure that was correctly adhered to or communicated > to anyone else (plus the distinction between the two is often subjective).
Yes, I figured as much about the intent. At first blush it did seem a good idea to me too to send informative messages to STDOUT and errors/debug to STDERR, but thinking about it more, it does not make much sense : they are all messages, they have a very strong dependency on relative ordering so they must all go to the same stream. The name STDERR itself is confusing since it seems to imply that non-error-related output should go to STDOUT. In fact I think the only thing vss2svn could rightfully write to STDOUT would be the subversion dump file, since it is the only actual "output" of the script (if that makes any sense). But I like the way it is now, always going to a file. In short, if the issue were serious enough to warrant changes throughout the vss2svn code, I would advocate always writing to STDERR, or even to a log file (vss2svn.log ?) just like it is done for the dump file. After all the only sane way to launch vss2svn involves redirecting its output to a log file, so the script might as well enforce this "best practice". But I think just making STDOUT hot hits a nice 80/20 point for this issue. At least I'm not going to work any further on it. Cheers, --Jonathan _______________________________________________ vss2svn-users mailing list Project homepage: http://www.pumacode.org/projects/vss2svn/ Subscribe/Unsubscribe/Admin: http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org Mailing list web interface (with searchable archives): http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
