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

Re: [PATCH] Re: log/blame -g and old servers

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-10-19 19:39:31 CEST

On 10/19/07, David Glasser <glasser@davidglasser.net> wrote:
> On 10/12/07, Karl Fogel <kfogel@red-bean.com> wrote:
> > "David Glasser" <glasser@davidglasser.net> writes:
> > > Here's a patch implementing that for ra_svn. (Presumably, the same
> > > patch for DAV will be harder because of the general lack of
> > > capabilities.)
> >
> > As we were discussing in IRC: detecting capabilities will be easier
> > after I commit my patch for issue #2959 (latest patch attached there
> > for inspection).
>
> Now that we have this, do people support adding a mergeinfo capability
> and using this to (among other things) error out on log/blame -g?

I do not understand the argument about erroring out, or why you feel
this is so different from --depth or any of the other features we have
compatibility for. I do not agree with the notion that it is somehow
helping the user to tell them they do not have the right version on
their server. I'd much rather have --depth=empty fail rather than
send me a GB of data that the client just discards for me. (Not
proposing we change this).

> I'm not sure what I feel about Mark's argument about wanting to
> hardcode to the -g equivalent. Maybe the svn_client APIs could return
> a boolean saying whether or not mergeinfo was actually used?

You do not feel this in a command line tool, but for a GUI that
remembers settings and will have users accessing all kinds of
repositories, having errors thrown at me is a problem.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 19 19:39:40 2007

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.