On 3/5/07, Les Mikesell <lesmikesell@gmail.com> wrote:
> Erik Huelsmann wrote:
>
> >>
> >> > We have the constant argument that the modification date time is
> >> > unreliable, unfortunately this statement
> >> > is driven by programs like subversion that throw this information
> >> > away, thus making the modification date time unreliable.
> >>
> >> While at the same time relying on just this - and only on this - for
> >> commit!
> >
> > Absolutely not!
> >
> > Subversion has a heuristic to determine whether it may need to commit
> > a file or not. Loosing the mtime (ie damaging) is no problem for
> > subversion: the timestamp will have changed and this means the file
> > needs to be further inspected to see if a commit is required.
> >
> > See, that's why Subversions behaviour isn't problematic from a 'mtime
> > is unreliable' pov: as soon as the mtime gets 'damaged', the file will
> > be further inspected. This means slowing down the commit, but nothing
> > more. 'Damaging' the mtime, as you can see, is not a problem for
> > Subversion.
>
> Unless, of course, the 'damage' happens to be setting the mtime to
> exactly match the pristine copy under .svn (or probably vice versa) so
> that no further inspection happens at all even if the file is changed.
> That sounds like a big problem to me.
But chances are slim this actually happens: of all 2^31 seconds in a
time_t, the damage would have to fall exactly on that second...
Just kidding.
These posts bare no relation to the original subject in the thread
anymore. I think the Original Poster has gotten a response and we can
call this thread concluded.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 5 15:09:34 2007