Greg Hudson <ghudson@MIT.EDU> writes:
> I may have misunderstood the code, not realizing that
> svn_client__get_revision_number doesn't always fully resolve the
> revision number (it evaluates HEAD by making a query, but returns
> SVN_INVALID_REVNUM if the revision isn't specified at all).
Ah.
> > The client cannot know the HEAD revision without asking the server.
> > Therefore, if we want to avoid issuing a bogus request, we must ask
> > the server for the HEAD revision first. That causes an extra network
> > turnaround (see r1864), which in most cases is a useless burden,
> > because it's a rare repository where HEAD == 0
>
> Well, I think it's inelegant for any valid, non-erroneous user operation
> to involve producing and ignoring an error; it suggests that something
> is wrong. Perhaps what's really wrong here is that ra_lib->get_log has
> the wrong defaults, but we can't easily fix that.
>
> So, while I think it's more elegant to spend a network turnaround in
> order to avoid the possibility of producing a spurious error (in
> general, a small constant number of network turnarounds is no big deal),
> it's certainly not "insane" to think otherwise. So, my comment can be
> changed from a strong preference to a mild preference.
Ok, thanks for the quick response.
I guess all I can say is, I don't find it inelegant. The generation
and catching of an error is entirely an internal implementation
detail, the same way it is in, say, svn_io_open_unique_file(). It's
simply an efficient way to get the desired result. (Well, in
svn_io_open_unique_file() it's also a matter of correctness, but I
think the example still holds.)
Extra network turnarounds bother me much more, as they can start to be
significant on a high-latency network. "A million here, a million
there, pretty soon you're talking about real money..."
So I hope Michael will just do part (b) of his patch.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 2 22:00:06 2004