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

Re: svn commit: r30205 - trunk/notes

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Fri, 04 Apr 2008 18:25:29 -0400

"David Glasser" <glasser_at_davidglasser.net> writes:
> Though actually it varies. In the CLI, -N does what I described. But
> various other layers translate recurse to depth differently. eg, the
> "add" exception doesn't exist in svn_client_add3. In svnserve's
> 'status' handler, non-recursive goes to empty. Etc.

I updated the document in r30301. See the diff; I think all that was
really needed was to say "here's how -N behaves" and "see individual doc
strings for API compatibility", so that's what I did.

> I think we need to go back to what we had before where the conversion
> macro has a clear role name:
> Then it's absolutely obvious if a given use of the macro is consistent
> or not. The status quo is a mess.

Well, the status quo is a mess for trying to answer certain kinds of
questions, but the other way is a mess for other kinds of questions. I
kind of prefer the macros to just say what they do, and then we use a
particular macro wherever we want its particular functionality.

> (Unless there's some reason that the special-casing of these
> operations should be different at the UI, the client API, and the RA
> API levels?)

Hysterical raisins? :-)

Seriously, I suspect in every case the decision was compatibility. That
is, we have to preserve whatever inconsistencies we had before, in a
backwards-compatible way. (That's another reason why the current macro
names are better: the alternative leaves the reader wondering whether
it's talking about the CLI command, the client command, or the RA


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-05 00:25:41 CEST

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.