> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: donderdag 7 juni 2012 10:46
> To: Thuan Seah Tan
> Cc: users_at_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
Received on 2012-06-07 11:28:26 CEST