On Thu, Jun 07, 2012 at 05:08:40PM +1000, Thuan Seah Tan wrote:
> Hi all,
> I am new to subversion and subversion api, and I have a question which I
> hope someone can point me in the right direction. I am trying to do a
> subversion integration in the tool I am working on, and to rename a file, I
> believe I need to call the svn_client_move6 function. That's all good, I can
> see the file is being renamed in Windows Explorer after the call. What
> puzzles me is the svn_client_status5 call straight after. If I have an
> unmodified file A.txt, renaming it to B.txt and back to A.txt should give me
> the node status as "replaced" but text status should remain "normal". I have
> TortoiseSVN installed, and using the file properties dialog, I can see that
> the file goes into "replaced" and "normal" state. But trying to call
> svn_client_status5 straight after the svn_client_move6 returns the file as
> "replaced" and "modified" in the status5 callback. It is only on subsequent
> call to svn_client_status5 (after some arbitrary time) the status is
> correctly marked as "replaced" and "normal". Wondering is there something I
> am doing wrong? This is how I am calling svn_client_status5:
The second move creates a new file A.txt with a new modification timestamp.
To avoid full content comparison, 'svn status' reports a file as modified
if the pristine file's modification timestamp and size differ from the
working file's timestamp and size.
Else, it compares file content to determine whether a file was modified.
There are also cases where the cached timestamp becomes invalid, the
full content is compared regardless of timestamp differences, and the
cached timestamp is then corrected. I believe this is why you're seeing
the node status flip from modified to normal.
For details, take a look at the function svn_wc__internal_file_modified_p()
in libsvn_wc/questions.c. If you set appropriate debugger breakpoints in
there you should be able to observe the code paths taken when the file is
reported as modified vs. when the file is reported as unmodified.
Note also that Subversion sometimes sleeps deliberately to wait for
on-disk timestamp updates. See svn_io_sleep_for_timestamps().
Received on 2012-06-07 10:46:55 CEST