Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-4342

Sleep for timestamps should be determined by libsvn_wc

Attach filesAttach ScreenshotAdd voteVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments


    • Improvement
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 1.7.x
    • unscheduled
    • libsvn_wc
    • None


      libsvn_client currently sleeps at the end of any operation that relies on WC
      timestamps in order for the WC to detect subsequent modifications to files.  But
      sometimes it sleeps when it doesn't need to.
      It seems to me that the tracking of whether we need to sleep should be done
      inside libsvn_wc, as only there do we really know whether we have made a change
      that relies on the timestamp.
      The current code is all in libsvn_client and can only assume that if it called
      something like svn_wc_revert or svn_wc_do_update then it will need to sleep,
      which is a crude assumption (not always true).  Within libsvn_wc we would also
      have the ability to store more detailed information.  For example, we could
      store the latest timestamp that we are relying on, so that at the end of the
      operation we wouldn't have to sleep for a further one second (or whatever period
      is required) but only wait until at least one second starting from when the last
      WC update was, a period which might have already elapsed or partly elapsed in
      some cases.  Another example is we could store more precise information about
      which paths (and therefore which filesystems) are affected, and thus determine
      exactly how long we need to sleep.
      I mentioned this in an email to dev@, subject "[PATCH] Sleep for timestamps in
      the right places", 2013-04-02, archived at e.g.



          This comment will be Viewable by All Users Viewable by All Users


            Unassigned Unassigned
            julianfoad Julian Foad




                Issue deployment