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

another authentication question

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-09-16 03:31:23 CEST

Somebody on this list made a feature request, and I want to know how
important people think this is.

Right now, the client application simply calls svn_client_* routines.
For each subversion "subcommand", there's an equivalent svn_client_
routine. Each svn_client_ routine opens and closes an RA session.

Someone complained that a shell-like application (or a GUI) might want
to open a single RA session, perform many subcommands, and then close
the RA session. In other words, what's being proposed is that the
*application* be in charge of opening/closing an RA session, and that
each svn_client_ routine take a session as an argument.

I've hit a slight snag with this idea. The problem is that opening an
RA session is *actually* defined as "open this URL". Subcommands like
`checkout' and `import' both get a URL on the commandline, but
subcommands like `commit' and `update' depend on looking up the stored
URL in the working-copy-path's entries file.

Thus, suddenly any subversion client app (user of libsvn_client) now
needs to be aware of this requirement; in some cases, it already has
the URL to open. In other cases, it will have to call a (not yet
existent) wrapper in libsvn_client that digs a URL out of libsvn_wc.
Seems like this is turning into a yucky burden on the client app.

So I'm wondering if this really worth the bother; I mean, will any
application *really* want to perform 2 or more subcommands in a row on
a single URL? I'm trying to think of an example. If not, then I
think that each subcommand should just go on independently
opening/closing URLs.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:41 2006

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.