[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: handling binary file

From: Ming Zhang <mingz_at_ele.uri.edu>
Date: 2006-07-27 23:07:48 CEST

On Thu, 2006-07-27 at 17:04 -0400, Ming Zhang wrote:
> On Thu, 2006-07-27 at 23:02 +0200, Erik Huelsmann wrote:
> > On 7/27/06, Ming Zhang <mingz@ele.uri.edu> wrote:
> > > On Thu, 2006-07-27 at 22:47 +0200, Ryan Schmidt wrote:
> > > > On Jul 27, 2006, at 19:58, Ming Zhang wrote:
> > > >
> > > > > I met a strange problem. I migrate my code tree from sf.net (CVS) to
> > > > > berlios (SVN). Then I found I have almost all binary files are broken.
> > > > > And seems svn can not even detect this. I feel SVN treat all these
> > > > > binary files as textual files.
> > > >
> > > > Are you sure the files aren't already broken in CVS? I haven't used
> > > > CVS, but I understand it's easy to corrupt binary files in CVS by
> > > > forgetting to tell CVS that they're binary.
> > >
> > > i just check out from cvs and these files are ok.
> > >
> > > >
> > > > Subversion treats all files as binary and won't muck with them unless
> > > > you tell it to. For example, if you tell it to do line-ending
> > > > conversion (svn:eol-style property) or keyword expansion
> > > > (svn:keywords property) it will do this, even on binary files; this
> > > > will probably destroy most kinds of binary files, so you should not
> > > > ask Subversion to do these kinds of operations on binary files.
> > >
> > > i never did this. in fact, i just know this today by googling because of
> > > this problem. :P
> > >
> > > >
> > > > There's also the matter of the MIME type (svn:mime-type property).
> > > > Have you set the MIME type of these files to a text/* MIME type or a
> > > > binary MIME type? A good MIME type for PDF files for example would be
> > > > application/pdf.
> > > >
> > > >
> > > > > For example, I have this pdf file Iometer.pdf.
> > > > >
> > > > > $ ll
> > > > > total 1052
> > > > > drwxrwxr-x 4 mingz mingz 4096 May 3 11:02 Docbook
> > > > > drwxrwxr-x 3 mingz mingz 4096 May 3 11:02 Iometer_Files
> > > > > -rw-rw-r-- 1 mingz mingz 988246 May 3 11:02 Iometer.pdf
> > > > > -rw-rw-r-- 1 mingz mingz 68529 May 3 11:02 Iometer.sxw
> > > > >
> > > > > Then I copy the correct file to overwrite it.
> > > > >
> > > > > $ cp ../../../branches/IOMETER-restruct/iometer/Docs/Iometer.pdf .
> > > > >
> > > > > See the file size changed.
> > > > >
> > > > > $ ll
> > > > > total 1056
> > > > > drwxrwxr-x 4 mingz mingz 4096 May 3 11:02 Docbook
> > > > > drwxrwxr-x 3 mingz mingz 4096 May 3 11:02 Iometer_Files
> > > > > -rw-rw-r-- 1 mingz mingz 992633 Jul 27 13:53 Iometer.pdf
> > > > > -rw-rw-r-- 1 mingz mingz 68529 May 3 11:02 Iometer.sxw
> > > > >
> > > > > But svn can not detect the file is changed.
> > > > >
> > > > > $ svn st
> > > > >
> > > > > How to correct this and let svn treat them as binary?
> > > >
> > > > That seems also to point towards improper svn:eol-style or
> > > > svn:keywords properties being used. What do you see if you say "svn
> > > > proplist -v Iometer.pdf"?
> > > >
> > >
> > > $ svn proplist -v Iometer.pdf
> > > Properties on 'Iometer.pdf':
> > > svn:keywords : Author Date Id Revision
> > > svn:eol-style : native
> >
> > > i have this. i guess native is a default good choice?
> >
> > Well, not in this case: you explicitly asked Subversion to treat your
> > binary file as texty... You could remove both properties and then copy
>
> could you explain a bit more on this?

found out via web. thx.

>
>
> > the undamaged file in. Maybe that helps? Also, the date on the file
> > needs to be newer than the date on the file when it is restored
> > through revert.
>
> ok. i will try this.
>
> >
> > HTH,
> >
> > Erik.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 27 23:10:15 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.