Re: sourceforge pserver is known bad. Should VCP work around?

On Wed, Feb 18, 2004 at 12:35:55PM -0800, Matt Attaway wrote:
> Probably eventually, but I wouldn't sweat it for now. Most people
> who are doing conversions will have much more reliable networks and
> servers. =)

True.  After sending the question, however, I was thinking that maybe
VCP should retry in the face of those two errors up to some
user-settable limit so we didn't get lots of support calls when people
try pserver access and it goes bonkers but in a recoverable fashion.
You're tilting me against that, and I think you're right; let's let the
users demonstrate this need before beefing it up.

In general, there are two classes of errors for VCP and perhaps there
should be three:

1. Fatal errors.  These break the conversion you're doing and you have
to start over.  This is how any unexpected stderr output from child
processes is handled.  This way, you can't ignore error messages.  But
that's unfortunate if the underlying command is just whining and it's
not a fatal error.

2. Expected errors.  These are errors that VCP is specifically
programmed to look for and either ignore or react to.  For instance,
when establishing a local CVS work space for VCP::Dest::cvs, VCP does a
cvs checkout.  If there's an error and a specific string shows up on
cvs' stderr, VCP knows the module does not exist and does a cvs import
before trying to checkout again.

Question 1: Is it acceptable to break a VCP conversion just because
the underlying command emits stderr?

Question 2: Should there be a user prompt before we bomb out of the
conversion?

Question 3: Should there be a command line and .vcp file option to allow
the user to set policy?

- Barrie