Thanks for all the replies. Looks like my best bet would be to do the status check at a later stage and revert if necessary.
Thuan -----Original Message----- From: Bert Huijben [mailto:b...@qqmail.nl] Sent: Thursday, June 07, 2012 7:28 PM To: 'Stefan Sperling'; 'Thuan Seah Tan' Cc: users@subversion.apache.org Subject: RE: Status after svn_client_move6 > -----Original Message----- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: donderdag 7 juni 2012 10:46 > To: Thuan Seah Tan > Cc: users@subversion.apache.org > Subject: Re: Status after svn_client_move6 > > 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(). What you might see is that the file is somehow still blocked for reading when you are calling status on it. If the timestamps don't match (see anser Stefan), then a compare is performed. But if the file is (temporarily) not readable, because some other process blocks that the file is marked as 'modified'. This other process could be a file indexer, a virusscanner, a disk status monitor, etc. What you see later is probably that the file was closed and the status succeeds again. Bert
