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

Re: [PATCH] Issue #692: Handle "svn log" with empty repos

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-07-02 21:20:09 CEST

On Fri, 2004-07-02 at 13:02, kfogel@collab.net wrote:
> But in any case, I don't understand his comment: "We have every
> ability to avoid requesting a log of r0 through r1 when the head
> revision is 0, so there is no reason to issue a bogus request and
> catch the error."
>
> Uh, how exactly do we have this ability?

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).

> 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 2 21:28:26 2004

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.