Re: [PLUG] Microsoft Sharepoint

How does Subversion handle binary files?

When you first add or import a file into Subversion, the file is examined to determine if it is a binary file. Currently, Subversion just looks at the first 1024 bytes of the file; if any of the bytes are zero, or if more than 15% are not ASCII printing characters, then Subversion calls the file binary. This heuristic might be improved in the future, however.

If Subversion determines that the file is binary, the file receives an svn:mime-type property set to "application/octet-stream". (You can always override this by using the auto-props feature or by setting the property manually with svn propset.)

Subversion treats the following files as text:

Files with no svn:mime-type
Files with a svn:mime-type starting "text/"
Files with a svn:mime-type equal to "image/x-xbitmap"
Files with a svn:mime-type equal to "image/x-xpixmap"

All other files are treated as binary, meaning that Subversion will:

Not attempt to automatically merge received changes with local changes during svn update or svn merge
Not show the differences as part of svn diff
Not show line-by-line attribution for svn blame

In all other respects, Subversion treats binary files the same as text files, e.g. if you set the svn:keywords or svn:eol-style properties, Subversion will perform keyword substitution or newline conversion on binary files.

Note that whether or not a file is binary does not affect the amount of repository space used to store changes to that file, nor does it affect the amount of traffic between client and server. For storage and transmission purposes, Subversion uses a diffing method that works equally well on binary and text files; this is completely unrelated to the diffing method used by the 'svn diff' command.

On 10/5/07, gabriel rosenkoetter <gr@eclipsed.net> wrote:

At 2007-10-05 19:45 -0400, Brent Saner <brent.saner@gmail.com> wrote:
> is there a way for subversion to run the binaries through, say, the
> openoffice libraries to diff them?
>
> (forgive me if i sound like a jerk; i know nothing about programming)

That is technically feasible, but I don't think it would be a very
good design decision, given the memory and processor pig that
OpenOffice is. I mean, it's fine to hork a bunch of the system when
the user is sitting in front of the computer whose resources are
horked, but when the user is hundreds of remote users, you need
commits and checkouts to be cheap, not slow. (Farming the processing
out to a compute farm doesn't work in this case either, because it
still makes the response time of the app unreasonably bad.)

I have been out of the loop on the Subversion feature suite (beyond
plain text, for which it works quite well, and handles directory
structures sanely, as opposed to the way CVS did, which was svn's
raison d'etre), but I do not believe that it's grown any binary
mangling features for MS file formats. (I'd be thrilled to be wrong
about that second bit, of course. Am I?)

--
gabriel rosenkoetter
gr@eclipsed.net

___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug