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

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

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 30 Jul 2013 05:08:19 -0700

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.

Bert From: Philip Martin
Sent: 30/07/2013 12:10
To: Alexander Lüders
Cc: dev_at_subversion.apache.org
Subject: Re: SVN 1.7/1.8 "commit after delete" performance issue
Alexander Lüders <alu_at_entimo.de> writes:

> Hi Philip,
> thanks for the response.
>> Passing the deleted file means that the path based optimisations are not
>> available in 1.7/1.8 and so svn_io_sleep_for_timestamps sleeps for
>> longer.

> That sounds like a fair assumption to me. Do you see any oportunity
> to implement some kind of optimization for the deletion case? Or is
> it something that cannot be fixed easily?

1.6 used svn_wc_get_actual_target but the current code no longer calls

When we come to do the sleep for a single target that is not a working
copy root we need to use the parent directory when the target has been
deleted. I'm not sure what criteria we should use:

  - call svn_wc__node_is_not_present to detect status==not-present

  - svn_io_check_path to detect no detect kind==svn_node_none

  - svn_wc__is_wcroot to detect is_wcroot==FALSE

There is a similar problem with

   svn up wc/node

when the update removes 'node' although this case it's only an
inefficiency not a regression.

Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
Received on 2013-07-30 14:09:15 CEST

This is an archived mail posted to the Subversion Dev mailing list.