Hi Frank,
I was recently working with cvs2svn (I presume that's what you used, but
maybe you didn't) and found I had the same problem.
I ended up re-running cvs2svn with these flags:
$ cvs2svn --dump-only --mime-type=/usr/local/etc/mime.types
--eol-from-mime-type --no-default-eol --keywords-off ~/newcvsrepo
This worked fine when I loaded it - I wiped out my project and started
from scratch again (perhaps there's a better way, I don't know). Notice
that I passed it a pointer to the mime.types file. You may want the
keywords on, but I found it was putting them on the jpeg files and
figured I would, overall, do better with out them.
If you do want keywords enable on the files you can also do that on the
client side for specific file types in the .subversion/config folder.
Though that involves all the clients having that in their configs...
Also, check out the cvs2svn users list off of cvs2svn.tigris.org, if you
haven't already.
I have no clue how to fix the files in place, or if you even can...
Hope this helps,
Bethany
Frank Baker wrote:
>
> We recently converted a product documentation repository from CVS to
> Subversion, retaining an 8-year history on the files. Unfortunately, it
> turns out that many of the image files had not been properly flagged as
> binary in the CVS repository. We were lucky in CVS as the images
> continued to present properly, but they are corrupted in the SVN
> extraction.
>
> I can easily fix the problem going forward by deleting the image files
> ('svn remove <imagefile>') then adding and committing an uncorrupted
> version of each image. Going forward, this would be fine; but (1) old
> revisions (i.e., from prior to the CVS-SVN conversion) checked out from
> the SVN tree will have the corrupted version of the file and (2) this
> approach disrupts the history feature of the 'svn log' function.
>
> An attempted fix that did not work was to set the property list ('svn
> propset') to specify an appropriate MIME type, 'image/gif' in this
> case. This failed when SVN determined that the file was not consistent
> with the target MIME type. Of course, given that the file was already
> corrupted, that seems a reasonable course of action. (My hope had been
> to change the MIME type then commit a clean version of the file; I
> couldn't get that far.)
>
>
> THE QUESTION: Is there a way to fix these image files in place or
> retrospectively so that prior revision levels can include uncorrupted
> images?
>
>
> Thanks for any assistance.
>
> Regards,
> -- Frank Baker
>
> Note: If we cannot clean up the older revision levels, we can still get
> our work done. It would be nice to be able to get all revisions, old
> and new, from one repository. But we made the CVS-SVN move at an
> easily-identified point in the development cycle, so we can extract
> earlier revisions from the CVS repository (which we are likely to keep,
> anyway) and use the SVN repository for subsequent revision levels.
> Also, most of these images had never changed; revisions were almost
> exclusively in the accompanying text, and that appears to be in good shape.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 2 22:48:29 2005