Forcing complete binary file comparison for checkin

[Sang Go <sa...@gmail.com>]

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.

How can I get SVN to recognize these changes so that these updated files can
be checked in?
More generally, can SVN be forced to check in a file?
Or can SVN be configured to compare the entire binary content when checking
in?

-- 
Sang.

Re: Forcing complete binary file comparison for checkin

[Karl Fogel <kf...@red-bean.com>]

"Martin Schröder" <ma...@oneiros.de> writes:
> 2008/2/3, Karl Fogel <kf...@red-bean.com>:
>> (It might be nice if we had a --force-check option to commit to tell it
>> to go straight to the content check, skipping the timestamp check.)
>
> Or telling commit to check the checksum and use that instead of the
> timestamp (like --checksum in rsync).

That's exactly what I meant by "content check".

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Forcing complete binary file comparison for checkin

[Martin Schröder <ma...@oneiros.de>]

2008/2/3, Karl Fogel <kf...@red-bean.com>:
> (It might be nice if we had a --force-check option to commit to tell it
> to go straight to the content check, skipping the timestamp check.)

Or telling commit to check the checksum and use that instead of the
timestamp (like --checksum in rsync).

Best
   Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Forcing complete binary file comparison for checkin

[Karl Fogel <kf...@red-bean.com>]

"Andy Levy" <an...@gmail.com> writes:
> That's correct. SVN uses the date/time of the file as the primary
> indication that the file has changed.
>
> Your tools which are changing these files without updating the
> date/time are in the wrong.

I wouldn't say they're necessarily in the wrong; they just disagree
with Subversion about how things ought to be done.

(It might be nice if we had a --force-check option to commit to tell it
to go straight to the content check, skipping the timestamp check.)

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Forcing complete binary file comparison for checkin

[Talden <ta...@gmail.com>]

On Feb 4, 2008 10:34 PM, Lasse Vågsæther Karlsen <la...@vkarlsen.no> wrote:
> Not really commenting on how subversion would or should handle this but IMO
> it's a really badly designed program that modifies a file but hides all
> details about the modification.
>
> Using the date/time stamp is a very typical way to see if a file has been
> modified after a certain point in time.

Unfortunately, with some capture devices (or simply for some of the
less capable consumers of the image files) the only evidence of the
time the image was captured is the modification time of the file - a
poor solution true, but in that circumstance it is understandable that
lossless operations to reorient an image might not want to change the
modification timestamp - of course the reorientation tool probably
shouldn't behave this way by default since most image producers and
consumers add capture information as file-content.

I suppose a new 'svn:inspect-contents' property could be used to
indicate which files need a more expensive contents check and the
working-copy book-keeping could retain a list of those files with this
property to avoid inspecting every files property during a commit,
status or update.

--
Talden

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Forcing complete binary file comparison for checkin

[Lasse Vågsæther Karlsen <la...@vkarlsen.no>]

Not really commenting on how subversion would or should handle this but IMO
it's a really badly designed program that modifies a file but hides all
details about the modification.

Using the date/time stamp is a very typical way to see if a file has been
modified after a certain point in time.

I understand this is outside the realm of this mailing list but I would
strongly suggest modifying the program or reporting that case as a bug. For
instance, none of the image cataloging programs I use would detect that type
of change either, unless the modification was done while the program was
actively holding a change-notification handle on the folder.

So while it might be common to just change the file in place, I would
certainly not agree that it should be common that it makes sure to reset the
last changed timestamps on the file, something it has to explicitly do
because the file system automatically maintains this timestamp for you.

On Feb 3, 2008 11:33 PM, Karl Fogel <kf...@red-bean.com> wrote:

> Blair Zajac <bl...@orcaware.com> writes:
> > Andy Levy wrote:
> >> On Feb 3, 2008 1:49 AM, Sang Go <sa...@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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>


-- 
Lasse Vågsæther Karlsen
mailto:lasse@vkarlsen.no
http://presentationmode.blogspot.com/
PGP KeyID: 0xBCDEA2E3

Re: Forcing complete binary file comparison for checkin

[Karl Fogel <kf...@red-bean.com>]

"Sang Go" <sa...@gmail.com> writes:
> 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.

Just FYI, the checksum would be different.  Otherwise, there really is
no change to the file.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Forcing complete binary file comparison for checkin

[Sang Go <sa...@gmail.com>]

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 <kf...@red-bean.com> wrote:

> Blair Zajac <bl...@orcaware.com> writes:
> > Andy Levy wrote:
> >> On Feb 3, 2008 1:49 AM, Sang Go <sa...@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.

Re: Forcing complete binary file comparison for checkin

[Karl Fogel <kf...@red-bean.com>]

Blair Zajac <bl...@orcaware.com> writes:
> Andy Levy wrote:
>> On Feb 3, 2008 1:49 AM, Sang Go <sa...@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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Forcing complete binary file comparison for checkin

[Blair Zajac <bl...@orcaware.com>]

Andy Levy wrote:
> On Feb 3, 2008 1:49 AM, Sang Go <sa...@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.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Forcing complete binary file comparison for checkin

[Andy Levy <an...@gmail.com>]

On Feb 3, 2008 1:49 AM, Sang Go <sa...@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.

Your tools which are changing these files without updating the
date/time are in the wrong.

> How can I get SVN to recognize these changes so that these updated files can
> be checked in?

Make the date/time change. If you can't change tools/get the tools you
use fixed, use touch to change the file's timestamp by 5 seconds.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org