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.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 5 14:44:20 2007