[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r12738 - in trunk/subversion: include libsvn_subr mod_dav_svn

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-01-16 04:29:02 CET

kfogel@collab.net writes:

> "Peter N. Lundblad" <peter@famlundblad.se> writes:
> > With "fixing symptoms" I was referring to the use of a function that
> > doesn't actually make sure that the paths are canonical. It fixes the
> > assertion failures (symptom), but doesn't fix the real problem (making
> > sure that paths are in canonical form). When you use a function, you
> > should make sure it does what you want. Since this function is internal,
> > and undocumented, this means reading the code:-)
>
> Okay, okay -- no need to lecture Mike Pilato on how to be a good
> programmer, he's plenty thorough already. Anyone can misread some
> code, all you need to do is point out the bug and let him fix it. No
> need to go beyond that.
>
> Regarding the overall approach: I feel that Julian Foad's point about
> being strict now and loosening later if we want is a good one.

Wow, take a day trip, and see what you miss out on...

For the record, yes, in a way I was fixing symptoms. It turns out
that most bugs have symptoms, and most symptoms that bugs have are the
kind you want to fix. But I didn't make a single change to
Subversion's code that wasn't in line with what I feel the Complete
Right solution should be. I just didn't have time to go all the way.
In other words, were I to take this fix to the fullest, strictest
place I think it should go, I wouldn't be reverting a single piece of
code, just teaching the already-existing is_canonical() to be quite a
bit more thorough.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 16 04:34:20 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.