mark benedetto king <mbk@boredom.org> writes:
> The way it currently works (which could be fixed by simply removing code)
> is that if it doesn't recognize any of the header fields in a particular
> record, it decides that the record is bogus. We could have it ignore
> these sorts of records, instead. If we do that, it will be less likely
> that we'll need to increment version numbers in the future (we'll be able
> to add new record types without fear).
In other words, we insist that there be at least one recognized header
(we don't care which one) in a record, and there can also be any
number of unrecognized headers?
Let's just drop that "one" to "zero" :-). If a record can't be
processed because some required header is missing, that's different --
then we must error. But if no headers in particular are required,
then there's no reason to error, even if no headers were recognized.
> I'm indifferent. What do you think?
Just that
1. We should always error when there's a problem.
2. We should never error when there isn't a problem.
Choking because of "UUIE" would violate (2).
Choking because "UUID" is *absent* is a separate question. If UUID is
required for dump format version 2, then we should error. But if it
is not required, then we shouldn't.
Since it's not really a showstopper if the UUID is absent, personally
think we shouldn't error, even if the format version is 2. If we're
flexible about these things, then maybe we'll never have to upgrade
the format version number again :-), our loaders will just DTRT all
the time. (Of course, if someone passes --force-uuid and no UUID is
found, that has to be an error.)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 11 06:29:40 2003