Re: using 'mv' to replace files, subversion does not detect changes

On Sun, 2005-08-07 at 14:41 -0400, Ryan Bloom wrote:
> mv and cp are very different under the covers, which is why this is
> happening. cp always deletes the old file, then it creates a new file
> with the same name, and copies all of the data. mv, on the other
> hand, just replaces the name if the files are on the same filesystem.
> The timestamps for moved files aren't changed.
>
> svn uses the timestamps of files as a clue to determine if it should
> do more investigation into if the file has changed. This is a
> performance optimization that svn (and cvs, and most other version
> control systems) use, because it is much faster to look at timestamps
> than it is to actually compare content.
>
> The easiest work-around, is to just touch the files after you have
> moved them. You could probably modify etc-update to do this for you,
> because it is just a python script. But, why do the moved files have
> an older timestamp than the files in the .svn directory? Generally,
> the moved files should have been placed on the filesystem long after
> your checkout. Can you check the timestamps the next time this
> happens?

Okay, I know for one operation that I did, the files I copied into the
working copy were much older that the checked out copies, so that would
make sense for that.

I'll check the timestamps when using etc-update and see what's going on
there.

Thanks,
Wesley

>
> Ryan
>
> On 8/7/05, Wesley Leggette <lists@kaylix.net> wrote:
> >
> > I am using subversion 1.1.3, and occasionally I'll want to replace a
> > file in a working copy with the contents of a file outside that
> > repository. To replace file A (inside working copy) with the contents of
> > file B (outside working copy) I issue 'mv B /path/to/checkout/A'.
> >
> > The result is that subversion does not detect any change to file A.
> > Neither 'svn status' nor 'svn diff' show anything.
> >
> > However, 'cp' seems to work fine. 'cp B /path/to/checkout/A' will
> > produce the desired result.
> >
> >
> > For normal source code work, I've been sticking with cp B.. rm B, but I
> > also use svn for tracking changes in /etc on my gentoo distribution.
> > There is a tool called etc-update that replaces outdated configuration
> > files with mv, which produces the problem mentioned above. This is where
> > I first noticed the problem.
> >
> >
> > Is this a bug in subversion and is there a practical work-around?
> >
> > Thanks.
> >
> >
> > --
> > Wesley Leggette <lists@kaylix.net>
> >
> > GPG Key: http://www.kaylix.net/kaylix.asc or http://pgp.mit.edu
> > GPG Fingerprint: 9B6F 19FB 5296 5E6C 21FE 7614 2A20 5688 F848 9BDD
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (GNU/Linux)
> >
> > iD8DBQBC9lJeKiBWiPhIm90RAnJ6AJ9Vd8/iWyO2FS1zqz+9Hx5zM96wzACfd5Vg
> > dsgIwKXPAMdcY9PNJuER0M8=
> > =d0YA
> > -----END PGP SIGNATURE-----
> >
> >
> >
>
>

-- 
Wesley Leggette <lists@kaylix.net>
GPG Key:         http://www.kaylix.net/kaylix.asc or http://pgp.mit.edu
GPG Fingerprint: 9B6F 19FB 5296 5E6C 21FE  7614 2A20 5688 F848 9BDD