On Sun, 2005-08-07 at 21:12 -0500, Wesley Leggette wrote:
> 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
Couldn't reproduce the problem. I checked etc-update after emerging
mod_ftpd, which has the configuration file mod_ftpd.conf. etc-update
created a temp file before merging the changes:
Aug 7 21:35 ._cfg0000_mod_ftpd.conf
Mar 26 16:47 mod_ftpd.conf
After etc-update, the new mtime was left:
Aug 7 21:35 mod_ftpd.conf
So basically, it worked as expected. `svn status` showed the
modification.
Thinking back, I might never have had this problem WHILE using
etc-update, but it might have been something else I was doing.
Would it still be safer in an automated script to use touch after
moving, or is this usually not a problem? What do people usually do?
Thanks for putting up with this one,
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 <wleggette@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
Received on Mon Aug 8 10:12:53 2005