Thanks for everyone's input. From the discussions, it sounds like that a
"--force-check" option would resolve this issue (and probably a lot of other
strange cases).
I wanted to also offer a little more background into why the file size, date
and time are not modified, but the binary content is modified. Whenever
compressed images are modified, image quality is reduced, but JPEG offers a
feature to rotate the image without any reduction in quality. That is why
the file size is identical (and I imagine the checksum would be the same as
well), but the actual contents are different.
As for the file date and time stamp, the software program offers the ability
as an option to force the date and time stamp to remain unaltered. This
allows the user to determine the original date and time stamp of the
picture, for sorting purposes. There are other methods of sorting, but it
is very flexible to be able to sort pictures from multiple source (i.e.
different prefixes -- DSC_####, IMG_####, etc) using standard Windows
detailed list view.
Sang.
On Feb 3, 2008 5:33 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> Blair Zajac <blair_at_orcaware.com> writes:
> > Andy Levy wrote:
> >> On Feb 3, 2008 1:49 AM, Sang Go <sanghgo_at_gmail.com> wrote:
> >>> SVN does not seem to detect changes in binary files that have changed,
> but
> >>> the file date, time, nor size has changed. This occurs when doing
> lossless
> >>> rotation of JPEG images where the file date and time are forced to
> retain
> >>> the original date and time.
> >>
> >> That's correct. SVN uses the date/time of the file as the primary
> >> indication that the file has changed.
> >
> > I'm pretty sure that svn 1.5 will also check the file size.
>
> Note that in this case, the sizes are also the same -- apparently, the
> program in question just does stuff to regions inside the file,
> without changing the file's size. (I think that's a common technique
> for dealing with really big files: you just do seeks-and-writes for as
> long as you can, and only after space usage gets really inefficient do
> you do an expensive resizing.)
>
> -Karl
>
--
Sang Go.
Received on 2008-02-04 19:52:45 CET