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

Re: svn_client_args_to_target_array and peg revisions -> no good

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 02 Jun 2009 17:06:39 +0100

On Tue, 2009-06-02 at 15:35 +0100, Stefan Sperling wrote:
> On Tue, Jun 02, 2009 at 01:38:22PM +0100, Julian Foad wrote:
> > Stefan Sperling wrote:
> > > On Sat, May 30, 2009 at 11:51:09AM +0100, Stefan Sperling wrote:
> > > > I'll need more time diving into the matter to pin-point the exact
> > > > cause of the problem.
> > >
> > > Still talking to myself here, but just following up with latest
> > > thoughts in case anyone is listening.
> >
> > Hi Stefan. I'm listening!
> Great! :)
> Thanks for your comments. I agree that a quick short-term
> fix could be made. I'd say we could add peg-rev parsing to all
> subcommands (not just 'add') and port those changes back to 1.6.x.
> On trunk, we can do the "proper" fix, transforming the target
> array from an array of strings to an array of (name, reg-rev) pairs.
> While I got you here, can you explain to me why we moved
> client_args_to_target_array functionality from libsvn_subr
> into libsvn_client?
> I can't find the rational for the move in the log message of r30753.
> See also r33317 which partly restored the functionality in libsvn_subr
> as svn_opt__args_to_target_array(), so that e.g. svnadmin doesn't
> need to link to libsvn_client.
> Why can't we just put things in one place?

Ah... That looks like a mistake. The email in which I advocated it is
<http://svn.haxx.se/dev/archive-2008-03/0188.shtml>. I think my flawed
reasoning was that "clients" meant "programs that use the Subversion
libraries", forgetting that it really meant "programs that communicate
remotely to a Subversion server".

- Julian

Received on 2009-06-02 18:07:13 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.