Dealing with binary files that haven't been kb'ed

  I am trying to convert a CVS repository that includes
binary files that
should have been kb'ed but have not been to Subversion
using cvs2svn
version 1.2.1. I am running into a problem with an archive
(.a) file that
checks out appropriately from CVS (and is usable, for what
that is worth),
but I am not sure how to deal with this when converting the
repository to
svn. The problem that I am having is that Carriage Returns
(0x0a) that
appear in my binary file when I check out on CVS are being
converted to
line feeds (0x0d) in the resulting file that I checkout from
subversion.

  I have created a mime types file that specifies that .a
files should
have a mime type of application/octet-stream and I have also
specified the
--eol-from-mime-type flag, assuming that my .a files would
be imported
with svn:mime-type=application/octet-stream and no
svn:eol-style set. Is
this a reasonable assumption? What I am actually seeing is
that the
mime-type is being set as described, but that the
svn:eol-style is also
being set to native (and, for whatever reason, the 0xa bytes
are being
changed to 0xd's -- are these being charged on conversion
or on svn
checkout from unix?). Is there something else that I should
be doing to
bring my file into Subversion in such a way that it will
preserve the
behavior of CVS? Or, if it sounds like there is a bug here,
what
information should I provide to the list to help track it
down?

____________________________________________________________
_____
Express yourself instantly with MSN Messenger! Download
today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471
ave/direct/01/


------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: users-helpcvs2svn.tigris.org

Michael Tucker wrote:
>  I am trying to convert a CVS repository that includes
binary files that
> should have been kb'ed but have not been to Subversion
using cvs2svn
> version 1.2.1. I am running into a problem with an
archive (.a) file that
> checks out appropriately from CVS (and is usable, for
what that is worth),
> but I am not sure how to deal with this when converting
the repository to
> svn. The problem that I am having is that Carriage
Returns (0x0a) that
> appear in my binary file when I check out on CVS are
being converted to
> line feeds (0x0d) in the resulting file that I checkout
from subversion.
> 
>  I have created a mime types file that specifies that
.a files should
> have a mime type of application/octet-stream and I have
also specified the
> --eol-from-mime-type flag, assuming that my .a files
would be imported
> with svn:mime-type=application/octet-stream and no
svn:eol-style set. Is
> this a reasonable assumption? What I am actually seeing
is that the
> mime-type is being set as described, but that the
svn:eol-style is also
> being set to native (and, for whatever reason, the 0xa
bytes are being
> changed to 0xd's -- are these being charged on
conversion or on svn
> checkout from unix?). Is there something else that I
should be doing to
> bring my file into Subversion in such a way that it
will preserve the
> behavior of CVS? Or, if it sounds like there is a bug
here, what
> information should I provide to the list to help track
it down?

I don't see any obvious mistakes in what you tried to do.

Why don't you just change the CVS files to -kb (using
"cvs admin -kb")
before the cvs2svn conversion?  The -kb property applies to
the file,
not to the revision, so if you set it today it should affect
the whole
CVS history and therefore the whole cvs2svn conversion.

Other ideas:

1. Try a more recent version of cvs2svn (ideally, the trunk
version).

2. Read the recent mailing list thread by somebody with a
similar
problem.  (You wouldn't happen to be migrating from CVSNT,
would you?)

3. Provide us with at least one CVS "*,v" file
that is converted
incorrectly, and the exact command line that you used to do
the
erroneous conversion, so that we can try to figure out the
underlying
problem.

Michael

------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: users-helpcvs2svn.tigris.org