On Wednesday 14 February 2007 01:30, L. Wayne Johnson wrote:
> If they are using FAT and long file names the problem is
> significantly worse than the time stamp. Long file names use
> multiple directory entries per name, the number depends on the
> length of the name. Not only can you get file fragmentation but you
> can get file name fragmentation as well. As files with different
> lengths names are deleted and created the names become interleaved
> and the pieces of the name can get rather far apart possible in a
> different block...
Makes sense to me that we need the "--force" option or whatever,
because flaws already exist where in some cases the timestamp is
known to be unreliable.
Still, the less accurate time (two-second resolution) should not
matter. We are not talking about syncronizing between client and
server, just between the working file and the pristine coppy in
".svn". The compared dates therefore will both have the same style of
stamping. So the only problem I see is still if a tool abuses the
modification timestamp deliberately.
The thing most interresting to me is that the only reason I know of a
tool deliberately suppressing the current timestamp, or changing it
back, is to actually say, "this file didn't really change". So
naturally it didn't want svn to detect a change. In other words, it
is trying to say that the last change of this zip file was indeed the
latest timestamp of files contained, or that this file was being
corrected to the content that should have been at that timestamp
(which is what throws off svn if it already detected the mistaken
change but not the correction change).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 14 19:37:40 2007