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

Re: [PATCH] Issue #2287 - Make svn_client_log() take a peg revision

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-10-11 02:44:35 CEST

kfogel@collab.net wrote:
> takes a targets array instead, which means that the behavior of the
> peg revision needs w.r.t. multiple targets needs to be worked out.
> There are two ways of calling log, IIRC:
> $ svn log LOCAL_PATH1 [LOCAL_PATH2 ...]

Not exactly. Only one local path is allowed in the "svn" client.

   $ svn log LOCAL_PATH

Why? Because svn_client_log2() doesn't work properly with more than one, and
it was difficult to fix so I didn't fix it. In those days I wasn't considering
the possibility of other clients using the API. Oops. :-(

When I say "doesn't work properly", I'm sure that was the case and don't
believe it has been fixed. I can't state the exact misbehaviour off the top of
my head, but I recall it being bad enough that I wouldn't want anyone to try to
use it, and that's why I disabled it (in the client).

> and
> $ svn log BASE_URL [SUB_PATH1 ...]
> In the first case, I think we already default to using the revision of
> the first path when no -r is specified. But what to do if multiple
> peg revs are passed? What about if some of the paths have peg revs
> and others don't?
> In the second case, I guess we can get away with just allowing a peg
> rev on BASE_URL and not on any of the sub-paths.

Yes, that sounds like the only sane behaviour for the URL case.

> Thoughts?

Uh... For our own client, a problem doesn't arise :-)

Seriously, I think the best medium-term solution is to disallow multiple local
targets in svn_client_log3(). They don't work properly in _log2() anyway so it
shouldn't cause many clients any hardship.

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 11 02:45:39 2005

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.