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:bert_at_qqmail.nl]
Sent: Thursday, June 07, 2012 7:28 PM
To: 'Stefan Sperling'; 'Thuan Seah Tan'
Cc: users_at_subversion.apache.org
Subject: RE: Status after svn_client_move6
> -----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-08 00:47:55 CEST