On Fri, 18 Feb 2005 kfogel@collab.net wrote:
> "Peter N. Lundblad" <peter@famlundblad.se> writes:
> > > No, because "bad" log messages get into the repository by means other
> > > than the client: a weird dumpfile, cvs2svn, or any rogue application
> > > using libsvn_fs. We haven't been enforcing things at the fs level.
> >
> > But since lock comments are new, we can enforce this in libsvn_fs for them
> > without backwards compatibility prblems.
>
> Yes, but we should still lossily escape them as they go to the client.
> People do odd things to their databases sometimes, and don't always go
> through our APIs. (Yes, I know that technically that's illegal, and
> not our fault, and all that. But there's no reason for Subversion to
I see this as database corruption. I think a server error is appropriate
in that case.
> fall on its face in that circumstance. And the lossy escaping will
> have no effect if the illegal chars are not present, after all.)
>
OK, I wouldn't veto it:-) But I'd rather see us validate the data while it
is being read and return an error in that case. For example, one could
just insert some invalid UTF8 in a lock comment (very simple in FSFS).
Should we try to escape that too? I don't think so. YOu see where I am
trying to get...
The log case was different, since we allowed bad data (bad IMO at least:-)
in the first place.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 18 16:35:02 2005