Benjamin Pflugmann <benjamin-svn-dev@pflugmann.de> writes:
> > > 1. I already have a WC in WC1 with a file called browse.html with a modified
> > > date of 11/8/2002.
> > > 2. Check out a fresh working copy in another directory: WC2. This gives
> > > all the files a modified date of 11/12/2002.
> > > 3. Copy browse.html from WC1 to WC2. The modified date stays the
> > > same (11/8/2002).
> >
> > Well, heck, that's the bogosity right there. Is that normal on win32?
> > When you copy a file, the timestamp doesn't change?? I've never heard
> > of such a thing.
> >
> > > 4. svn st and svn st -u both return no changes to WC2.
> > >
> >
> > Right. The first check we make is whether the timestamp has changed.
> > If the timestamp hasn't changed,
>
> The timestamp has changed from the point of view of WC2. It may be
> true that, for the copied file, the timestamp stayed the same
> (11/8/2002).
>
> But before the copy, WC2/browse.html was of 11/12/2002, afterwards it
> is 11/8/2002. So no, the timestamp has changed with regard to WC2.
Does the "create time" of the file change when it is copied in this
way? If the "create time" stays the same and the "modified time"
changes such that the result is a file that was "modified" before it
was "created" then svn_io_file_affected_time() is not going to work.
Given that two people have reported this bug, I assume that's what is
happening.
I wonder if svn_io_file_affected_time() should simply return the mtime
on Windows? This may be the correct behavior on Unix as well, I'm not
sure the docstring's argument about tracking permissions is correct,
which bit of Subversion needs to know that they changed?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 12 22:14:58 2002