You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2004/06/24 18:21:35 UTC

Re: Unix-only code (was Re: svn commit: r10060 - trunk/subversion/libsvn_fs)

On Thu, 2004-06-24 at 13:55, John Peacock wrote:
> > No, but are there really that many people trying to build Subversion on
> > VMS?  It's about correctness, not numbers.

> But that is exactly my point.

No, it's a convenient rhetorical trick.  I agree that the WIN32 test is
incorrect, but you want to ditch it for another incorrect solution,
using "but how many people really care if it's incorrect?" as an
argument.

> The fact that the existing code makes that overly broad assumption
> doesn't make it right.

It makes it right in the context of this particular change.  If we've
fallen into a particular pattern of bad-but-convenient behavior, it
makes perfect sense to take advantage of that as long as it won't make
it any harder to dig ourselves out of the hole at such a time as it
becomes necessary.

> It's about correctness, not numbers. ;)

*I* never used numbers as an argument (except to demonstrate the fallacy
of your argument).


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Unix-only code (was Re: svn commit: r10060 - trunk/subversion/libsvn_fs)

Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> On Thu, 2004-06-24 at 13:55, John Peacock wrote:
>>The fact that the existing code makes that overly broad assumption
>>doesn't make it right.
> 
> 
> It makes it right in the context of this particular change.  If we've
> fallen into a particular pattern of bad-but-convenient behavior, it
> makes perfect sense to take advantage of that as long as it won't make
> it any harder to dig ourselves out of the hole at such a time as it
> becomes necessary.

I'm not arguing against the patch in question; I am arguing about the 
"we know it's suboptimal but the codebase already makes these poor 
assumptions so why not continue doing it that way" mindset.  If it is 
possible to add new code the correct way now (meaning it won't have to 
be fixed later), that should always be preferred to adding it knowing 
that it will have to be adjusted "at such time as it becomes necessary."

I just happen to be sensitive to this because I forsee having to clean 
up someone else's mess.

John


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org