On Tue, 28 Jun 2005, Erik Huelsmann wrote:
> On 6/27/05, Greg Hudson <ghudson@mit.edu> wrote:
> > On Mon, 2005-06-27 at 10:48 -0500, Carl Karsten wrote:
> > > Fill me (and perhaps Erik) in - What is the use case for a script that would be
> > > impacted by this bug?
> >
> > svn update
> > <make a scripted change to a file>
> > svn commit
> >
> > If the scripted change occurs before the system time advances past the
> > FAT resolution, Subversion might not detect that the file has changed,
> > and the commit won't transmit that file.
> >
> > (We could store the size of the unmodified working copy file
> > in .svn/entries, and check whether that has changed as well. That would
> > substantially reduce the impact of this kind of bug. But I'm not sure
> > it's worth the effort and space and code complexity.)
>
> It would also greatly increase 'svn st' speed in case filestamps don't
> match. In the current scenario, the file must be 'detranslated' to be
> able to check its size against the size stored in the .svn/entries
> file. Storing the WC file size would eliminate the need for that step
> in many situations (ie where a change resulted in a file size change).
>
I've been thinking about this, but I'm not sure this will "greatly improve
svn status" because most files are note modified in a typical situation.
So, for most files, you'll get equal file sizes and a forced
byte-by-byte-comparisons. Or do I miss something?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 28 21:32:23 2005