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

Re: [PATCH] dup function for svn_info_t

From: David James <james82_at_gmail.com>
Date: 2005-10-11 02:22:52 CEST

On 10 Oct 2005 16:22:12 -0500, kfogel@collab.net <kfogel@collab.net> wrote:
> Chris, this seems not to have made it into Subversion. Do you not
> need it anymore, or do you still want it but just were waiting for
> someone to commit it?
>
> -Karl
This patch looks perfect to me. In the Python bindings, we don't wrap
svn_client_info yet, but when we do, we'll need the svn_info_dup
function.

If you are also happy with the patch, please commit it.

Thanks!

David

>
> "Peter N. Lundblad" <peter@famlundblad.se> writes:
> > On Mon, 13 Jun 2005, Chris Foote wrote:
> >
> > > Branko ─îibej wrote:
> > > > Chris Foote wrote:
> > > >
> > > > >[LOG]
> > > > >
> > > > >Add a function to duplicate the svn_info_t structure.
> > > > >
> > > > >* subversion/include/svn_client.h
> > > > > (svn_info_t): Add note to update svn_info_dup when extending the struct.
> > > > > (svn_info_dup): New function to duplicate an svn_info_t.
> > > > >
> > > > >* subversion/libsvn_client/info.c
> > > > > (svn_info_dup): Ditto.
> > > > >
> > > > >
> > > > Why add a public function that's not used anywhere?
> > > >
> > > So that clients (i.e. one I'm writing) can create safe copies of the struct
> > > that are allocated in a different pool from the one that was used when
> > > calling svn_client_info.
> > >
> >
> > I agree. The struct might be extended, so to be safe, you need such a
> > function.
> > > > >+svn_info_t *
> > > > >+svn_info_dup (const svn_info_t *info, apr_pool_t *pool)
> > > > >+{
> > > > >+ svn_info_t *dupinfo = apr_pcalloc (pool, sizeof(*dupinfo));
> > > > >+
> > > > >+ /* Perform a trivial copy ... */
> > > > >+ *dupinfo = *info;
> > > > >
> > > > >
> > > > Since you're copying the struct anyway, there's no sense in using
> > > > apr_pcalloc.
> > > True, although this is what svn_wc_entry_dup uses.
> > >
> > I don't mind changing that too, even if this is really cycle-counting if
> > anything...
> >
> > Regards,
> > //Peter
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
> >
>
> --
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>

--
David James -- http://www.cs.toronto.edu/~james
Received on Tue Oct 11 02:23:43 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.