You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Sasikala Kottegoda <sa...@wso2.com> on 2017/10/19 09:41:50 UTC
svn status does not detect a modification if the same file was touched
Hi all,
I'm using svn version 1.9.3 and I have come across the following:
- A file named a.txt exists inside a folder in the working copy, which
has been copied from somewhere else
- cCopy and replace a.txt with the same file/or modify it by issuing the
'touch' command
- Do an svn status, it shows nothing
- Do an svn info on the file and 'Last Changed Date' shows the same as
the previous file. It does not get modified even though the file was newly
copied.
- But the from java files API, the file is shown with a different
modified date
Why do we not modify the 'Last Changed Date' when the file was newly
copied/touched?
Thank you,
Sasikala
--
Sasikala Kottegoda
*Senior Software Engineer*
WSO2 Inc., http://wso2.com/
lean. enterprise. middleware
Mobile: +94 774835928
[image: https://wso2.com/signature] <https://wso2.com/signature>
Re: svn status does not detect a modification if the same file was
touched
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ralph Seichter wrote on Thu, 19 Oct 2017 18:31 +0200:
> On 19.10.17 18:17, Daniel Shahaf wrote:
>
> > Subversion doesn't use checksums to detect modifications. 'svn status'
> > is based on filesize + mtime only.
>
> I seemed to remember subversion behaved like git in this regard, using a
> checksum (as shown in 'svn info') as an indicator, rather than raw file
> size. Oh well, I'm pretty sure you know first-hand how it works. ;-)
https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/questions.c?revision=1801448&view=markup#l258
:-)
Re: svn status does not detect a modification if the same file was
touched
Posted by Ralph Seichter <m1...@monksofcool.net>.
On 19.10.17 18:17, Daniel Shahaf wrote:
> Subversion doesn't use checksums to detect modifications. 'svn status'
> is based on filesize + mtime only.
I seemed to remember subversion behaved like git in this regard, using a
checksum (as shown in 'svn info') as an indicator, rather than raw file
size. Oh well, I'm pretty sure you know first-hand how it works. ;-)
-Ralph
Re: svn status does not detect a modification if the same file was
touched
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ralph Seichter wrote on Thu, 19 Oct 2017 13:01 +0200:
> On 19.10.2017 12:16, Sasikala Kottegoda wrote:
>
> > In this scenario, svn status does not show anything. Also, the file
> > does not get commited when I issue an 'svn commit'. Is there a reason
> > for that?
>
> Subversion uses a hash of the file content to determine if it has been
> modified. Changing the modification date in the working copy, as you did
> with 'touch', does not alter the content, hence the file is considered
> unchanged.
Subversion doesn't use checksums to detect modifications. 'svn status'
is based on filesize + mtime only. If mtime differs but filesize doesn't, then
a full content diff is done.
> This is deliberate.
Yes, it is, for efficiency reasons. (stat() is cheaper than read())
Re: svn status does not detect a modification if the same file was
touched
Posted by Ralph Seichter <m1...@monksofcool.net>.
On 19.10.2017 12:16, Sasikala Kottegoda wrote:
> In this scenario, svn status does not show anything. Also, the file
> does not get commited when I issue an 'svn commit'. Is there a reason
> for that?
Subversion uses a hash of the file content to determine if it has been
modified. Changing the modification date in the working copy, as you did
with 'touch', does not alter the content, hence the file is considered
unchanged. This is deliberate.
-Ralph
Re: svn status does not detect a modification if the same file was touched
Posted by Sasikala Kottegoda <sa...@wso2.com>.
Hi Andreas,
Thanks for the prompt reply.
In this scenario, svn status does not show anything. Also, the file does
not get commited when I issue an 'svn commit'. Is there a reason for that?
Thank you,
Sasikala
On Thu, Oct 19, 2017 at 3:25 PM, Andreas Stieger <an...@gmx.de>
wrote:
> Greetings,
>
> On 10/19/2017 11:41 AM, Sasikala Kottegoda wrote:
> > A file named a.txt exists inside a folder in the working copy, which
> > has been copied from somewhere else
> >
> > * cCopy and replace a.txt with the same file/or modify it by issuing
> > the 'touch' command
> > * Do an svn status, it shows nothing
> > * Do an svn info on the file and 'Last Changed Date' shows the same
> > as the previous file. It does not get modified even though the
> > file was newly copied.
> > * But the from java files API, the file is shown with a different
> > modified date
> >
> > Why do we not modify the 'Last Changed Date' when the file was newly
> > copied/touched?
>
> Last Changed Date refers to the last change of the version item in the
> repository that the working copy knows about. It does not relate or
> account for local file system changes, neither in identity (inode),
> timestamps (touch) nor content - because this is a local change that
> does not change the versioned item until commit.
>
> Andreas
>
--
Sasikala Kottegoda
*Senior Software Engineer*
WSO2 Inc., http://wso2.com/
lean. enterprise. middleware
Mobile: +94 774835928
[image: https://wso2.com/signature] <https://wso2.com/signature>
Re: svn status does not detect a modification if the same file was
touched
Posted by Andreas Stieger <an...@gmx.de>.
Greetings,
On 10/19/2017 11:41 AM, Sasikala Kottegoda wrote:
> A file named a.txt exists inside a folder in the working copy, which
> has been copied from somewhere else
>
> * cCopy and replace a.txt with the same file/or modify it by issuing
> the 'touch' command
> * Do an svn status, it shows nothing
> * Do an svn info on the file and 'Last Changed Date' shows the same
> as the previous file. It does not get modified even though the
> file was newly copied.
> * But the from java files API, the file is shown with a different
> modified date
>
> Why do we not modify the 'Last Changed Date' when the file was newly
> copied/touched?
Last Changed Date refers to the last change of the version item in the
repository that the working copy knows about. It does not relate or
account for local file system changes, neither in identity (inode),
timestamps (touch) nor content - because this is a local change that
does not change the versioned item until commit.
Andreas