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

RE: svn commit: r33602 - trunk/subversion/libsvn_client

From: Bert Huijben <bert_at_vmoo.com>
Date: Sun, 12 Oct 2008 17:10:44 +0200

> -----Original Message-----
> From: Julian Foad [mailto:julianfoad_at_btopenworld.com]
> Sent: Sunday, October 12, 2008 5:08 PM
> To: Bert Huijben
> Cc: dev_at_subversion.tigris.org
> Subject: RE: svn commit: r33602 - trunk/subversion/libsvn_client
>
> Bert Huijben wrote:
> > > > Implement this by passing a svn_boolean_t* use_sleep to all
> function
> > > that
> > > > require a sleep for timestamp integrity. The calling function
> will
> > > then call
> > > > svn_sleep_for_timestamps() when use_sleep is set to TRUE.
> > >
> > > In the implementation, notice that many of our functions have far
> too
> > > many arguments for a human mind to keep track of already. Instead
> of
> > > passing another argument, would it be better to put the "needs
> sleep"
> > > variable in the merge command baton which appears to be already
> passed
> > > around to the required places?
> > >
> > > (I see places where the baton is named "merge_options", and that
> name
> > > would then want to be improved because it would no longer contain
> just
> > > options, but that's not a problem.)
> >
> > Merge options and the baton are two completely different things. The
> > merge_options parameter is an array of string parameters passed to
> the diff3
> > tool.
>
> Oops, sorry, I didn't look hard enough. Yes, "merge_options" is not the
> baton. I meant the merge_cmd_baton_t. And I see that only some of the
> functions take this baton.
>
> > [...] (But this cleanup is unrelated to this
> > performance work; there some other candidates for inclusion).
>
> Sure, but any clean-up is valuable in this complex source file, and
> it's
> easier and more likely to happen now than later. I'll commit the
> attached patch when the test suite completes successfully if you've no
> objection.

It certainly is valuable to clean this up.

+1 and thanks for looking into this! :)

        Bert
>
> Thanks.
> - Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-12 17:11:04 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.