On 2/20/2007 9:13 AM, Jan Hendrik wrote:
> Concerning Re: svn does not detect file recodi
> Les Mikesell wrote on 20 Feb 2007, 7:54, at least in part:
>
>> I think what people are requesting is a _option_ to force a correct
>> determination of 'changedness' to cover the situations where the
>> timestamp can't be trusted. As a historical precedent, you might
>> consider the 'rsync' program which needs to make approximately the
>> same determination and thus the same need for an option to do it the
>> fast or
>> the correct way - and note that it does have exactly such an option.
>
> To me it looks this time issue can have much more practical and
> frequent reasons than the occasional deliberate resetting of mtime
> for special cases during FTP synching I have happening here.
>
> Anyway, the current SVN behaviour is in so far even worse as in a
> svn update any modification in such files is not merged, but
> overwritten - read: lost - as I just confirmed in a test, even if the
> filesize has changed by this "non-mtimed" modification. So IMHO
> SVN makes quite a dangerous guess by exclusively relying on
> mtime even in cases where modifications are not only just not
> committed, but could be written over.
I'd call this a bug. You should put together a demo script and submit a
bug report.
It's arguable whether to use mtime or ctime or a full binary compare,
but to ignore changes in file size before a destructive update is
clearly a bug.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 20 16:05:55 2007