Re: Subversion, binary files, hex editors and file modification time

Oliver Paulus wrote:
>> Why is the hex editor behaving badly? If it changes the file, the
>> modification time should be changed too.
> I do not know why - but there are some programs (hex editors) with this
> behaviour.
>
>> Because reading the entire file would be much, much slower.
> I know but my problem is that the users have a modified version of the file
> within the working copy which cannot be commited to the repository AND the
> users do not know that they have changed it. They believe that they have
> the "not modified" version from the repository.

Oliver, I'm sure you understand what you are asking for here. At worst,
you're asking for Subversion to disregard file modification time as a valid
modification determinant, which has the result of causing a whole lotta
performance pain for the vast majority of users whose tools aren't broken in
the way that the hex editor(s) you describe are. At best, you're asking
Subversion developers to maintain code which optionally allows individual
users to enable for themselves this mod-time-ignoring feature.

But let's consider user classes and ultimate aims here. There is certainly
a class of user who is aware of this bug in their hex editor tool, but
doesn't really know what to do about it. That's the one class where this
change to Subversion might help. There's another class of folks who are
aware of the bug and can immediately spot workarounds (such as wrapping
their hex editor command-lines with a script that first 'touch'es the
versioned file and then calls the hex editor) -- this code would never be
used by them. And then there are the folks that aren't even aware of this
bug in their hex editors -- this code does them no good either, as they
don't realize they have a problem.

Now, I'm sensitive to the needs of that one class of users that this helps,
but something tells me that rather than have all those users rising up in
one voice against each and every piece of software that checks file
modification timestamps (which is done for the *benefit* of those users),
that unified voice aimed at the maintainers of the broken hex editor tools
might actually serve a better end goal. I imagine Subversion is not alone
in this situation -- that other version control systems, backup/restore
software, and so on all suffer in the scenario where misbehaving user tools
are falsifying file metadata.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand