You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Thuan Seah Tan <th...@fmod.org> on 2012/06/07 09:08:40 UTC
Status after svn_client_move6
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:
err = svn_client_status5(NULL, mSvnClientContext, filename, &info_revision,
svn_depth_files,TRUE, TRUE, TRUE, TRUE, TRUE, NULL, status5_callback,
&statusBaton, mRootAprPool);
Any advice or pointer is appreciated.
Thuan
RE: Status after svn_client_move6
Posted by Thuan Seah Tan <th...@fmod.org>.
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@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:stsp@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
RE: Status after svn_client_move6
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@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
Re: Status after svn_client_move6
Posted by Stefan Sperling <st...@elego.de>.
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().