Re: SVN 1.7/1.8 "commit after delete" performance issue

[Alexander Lüders <al...@entimo.de>]

Hi all,

first of all thanks for your investigation. Seems to me like there is no 
trivial fix of the problem.
How to proceed now? Shall I file a bug report?

Greetings
Alex

Am 30.07.2013 17:58, schrieb Bert Huijben:
> Passing null will always have the full wait time, so just picking some
> path has a better user experience. When multiple paths are passed they
> are usually all in the same (wc and) file system.
>
> Bert From: Philip Martin
> Sent: 30/07/2013 14:53
> To: Bert Huijben
> Cc: Alexander Lüders; dev@subversion.apache.org
> Subject: Re: SVN 1.7/1.8 "commit after delete" performance issue
> Bert Huijben <be...@qqmail.nl> writes:
>
>> Just pick the parent of the first delete or something like that. The
>> path should be a valid path on the same file system, nothing special.
>> It is just used for guessing the timestamp granularity.
> I suppose that might work for commit, but it's not clear how it would
> work for update.  Instead how about something like this:
>
> Index: subversion/libsvn_client/commit.c
> ===================================================================
> --- subversion/libsvn_client/commit.c	(revision 1508338)
> +++ subversion/libsvn_client/commit.c	(working copy)
> @@ -1027,8 +1027,14 @@ svn_client_commit6(const apr_array_header_t *targe
>    cleanup:
>     /* Sleep to ensure timestamp integrity. */
>     if (timestamp_sleep)
> -    svn_io_sleep_for_timestamps(base_abspath, pool);
> +    {
> +      const char *wcroot_abspath;
>
> +      SVN_ERR(svn_wc__get_wcroot(&wcroot_abspath, ctx->wc_ctx, base_abspath,
> +                                 pool, pool));
> +      svn_io_sleep_for_timestamps(wcroot_abspath, pool);
> +    }
> +
>     /* Abort the commit if it is still in progress. */
>     svn_pool_clear(iterpool); /* Close open handles before aborting */
>     if (commit_in_progress)
> Index: subversion/libsvn_client/update.c
> ===================================================================
> --- subversion/libsvn_client/update.c	(revision 1508338)
> +++ subversion/libsvn_client/update.c	(working copy)
> @@ -701,7 +701,17 @@ svn_client_update4(apr_array_header_t **result_rev
>
>    cleanup:
>     if (sleep)
> -    svn_io_sleep_for_timestamps((paths->nelts == 1) ? path : NULL, pool);
> +    {
> +      const char *wcroot_abspath;
>
> +      if (paths->nelts == 1)
> +        SVN_ERR(svn_wc__get_wcroot(&wcroot_abspath, ctx->wc_ctx, path,
> +                                   pool, pool));
> +      else
> +        wcroot_abspath = NULL;
> +
> +      svn_io_sleep_for_timestamps(wcroot_abspath, pool);
> +    }
> +
>     return svn_error_trace(err);
>   }
>

Re: SVN 1.7/1.8 "commit after delete" performance issue

[Alexander Lüders <al...@entimo.de>]

That's great. Thank you very much.

Am 09.08.2013 12:26, schrieb Philip Martin:
> Alexander Lüders <al...@entimo.de> writes:
>
>> How to proceed now? Shall I file a bug report?
> It's already fixed on trunk and I've just proposed it for 1.8.
>

Re: SVN 1.7/1.8 "commit after delete" performance issue

[Philip Martin <ph...@wandisco.com>]

Alexander Lüders <al...@entimo.de> writes:

> How to proceed now? Shall I file a bug report?

It's already fixed on trunk and I've just proposed it for 1.8.

-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data