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

Re: Better patch for fixing svnadmin hotcopy handling of symlinks

From: Nico Kadel-Garcia <nkadel_at_comcast.net>
Date: 2006-08-07 20:33:39 CEST

Garrett Rooney wrote:
> On 8/5/06, Nico Kadel-Garcia <nkadel@comcast.net> wrote:
>> I wrote about this before: the "svnadmin hotcopy" tool does not
>> successfully replicate symlinks in the repositories.
>> Someone sent me a nice patch for the "repos.c" file, which added the
>> capability of duplicating symlinks, but I also had to add a patch to
>> io.c in order to actually have the function called as the walk
>> through the directories lists files and directories to move.
>> I'm attaching a copy of the patch against the current trunk for
>> subversion, I'll also include it in the issue tracker page I created.
> The patch seems mostly reasonable, but the bit where you fprintf to
> stderr in the case of something you don't understand is just wrong.
> We can't just spew stuff to stderr in a library function like that,
> there's no way to tell if anyone's even looking at stderr, this could
> be embedded in a GUI app or something. If we NEED a way to warn
> without erroring, we have to do it via some sort of callback/baton
> pair, otherwise treat it as an error and return an svn_error_t just
> like any other problem. Or just look at the other potential cases and
> figure out if they need to be handled, if not just ignore them.

A reported error is *fine* with me! I wasn't sure what best to inject, and
I'm always ware of functions relying on being called only with correct
arguments. There should have been a reported error in the first place,
rather than a silently failed function. Do you know the best syntax for that

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 7 20:34:47 2006

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

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