Re: $Log$ handling

On 02/28/2013 02:52 AM, Matt Ackeret wrote:
> This sure seems like a FAQ, but I can't figure it out.
> 
> I'm converting my project with
> 
> /Users/Shared/cvs2svn-2.4.0/cvs2svn --use-cvs --encoding=UTF-8 --dumpfile=cvs2svn-dump /tmp/PROJECT
> 
> then end up with differences like this:
> <       $Log: FILE.h,v $
> <       Revision 1.4  2007/06/06 22:43:53  USER
> ---
>>  * $Log: not supported by cvs2svn $
> 
> In the Extraction options info for --use-internal-co, it says $Log$ is not
> handled.  So I thought that meant that in the other two cases (---use-rcs and
> ---use-cvs), it was handled.

Short answer: if you have been diligent about marking your binary files
as binary in CVS (i.e., with the "-kb" option), then use cvs2git's
"--default-eol=native" option.  If not, you've got a more complicated
problem.

Long answer:

By default, CVS treats all files as text.  Since CVS doesn't normalize
text line endings when files are put into the repository, there is a
minimal risk of corrupting a binary file when committing (basically only
if it has one of the "$Keyword$ strings in it) and if a problem is
noticed on checkout, the binary option can be set retroactively to fix
the problem.  So CVS is pretty stupid, but it is forgiving of mistakes.
 Since many people only use their repo under one OS, they might never
have problems with their files even if they never marked their binary
files as binary, so in the real world there are tons of binary files in
CVS that are not marked as binary.

However, Subversion *requires* text files to be normalized when they are
committed to Subversion, so cvs2svn *has to* normalize EOLs in any text
files.  This would very likely corrupt, in a way that cannot be fixed
retroactively, any files that in fact are binary but not labeled as binary.

Therefore, we made the conservative decision that cvs2svn would do *no*
EOL translation unless the user specifically instructs it otherwise.

But by default we *do* leave keyword expansion turned on for files that
are not marked as binary.  The risk of corrupting a binary file via
keyword expansion is much less than that of corrupting a file via EOL
normalization, and a text file with its keywords *not* expanded is very
misleading (the keywords are usually expanded as for the *previous*
revision of the file).

So for a file that is marked as "text" in CVS with the
--default-eol=binary (the default value for that option), we want EOL
normalization *off* but keyword expansion *on*.  The only way to tell
CVS not to do EOL normalization is via the "-kb" option, so we have to
use that.  But that option also turns off CVSs keyword expansion, so we
have to do the keyword expansion ourselves.  And our keyword expansion
code doesn't handle the "$Log$ keyword.  That is the reason for what you
observe.

If you set --default-eol=native, then cvs2svn will turn EOL
normalization *on* for such files, and then it can use CVS's "-kkv"
option, which also does keyword expansion.  Then you will get your $Log$
keywords expanded by CVS, but if you have any binary files that have not
been marked as binary in CVS, they will likely be corrupted.

> I also have an older version cvs2svn-1.5.0, from the last time I was converging
> a repository.  Maybe this has changed since then?  (I sure thought the old
> repository used $Log$, though maybe someone removed all of them before I
> converted it.)
> 
> How can I make this "just work", so it does expand and my svn & cvs 
> versions match?

The default behavior has been made more conservative since 1.5.0.  Using
"--default=native" will give you approximately the old behavior.

> (As for the other problem I had, I still haven't figured that one out.. I'm
> just removing that test from my local copy of the repository before I run
> cvs2svn.. Strangely, there is another file with a space in it, and my cvs is
> _not_ a shell script.. so there does seem to be something stranger going on,
> but I haven't been able to figure it out.)

Please dig into it.  Does the same problem occur if you convert just the
single file?  If so, please submit that file (with proprietary
information removed, if necessary) along with the supporting information
needed to make a usable bug report [1].

We want to understand (and if necessary fix) this problem, if not for
yourself then for other future users.  So please make the effort to
submit a usable bug report [1], just as many earlier generations of
users have submitted bug reports that benefited you.

Michael

[1] http://cvs2svn.tigris.org/faq.html#reportingbugs

-- 
Michael Haggerty
[email protected]
http://softwareswirl.blogspot.com/

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=3050008

To unsubscribe from this discussion, e-mail: [[email protected]].