Re: cvs2git enforces SVN file naming on conversions

Daniel Hagerty wrote:

       ^^^^^^^ What kind of strange name is that? :-)

> I've been playing with converting some company cvs repositories with
> cvs2git.  I ran into a problem with one of them, with the error 
> message:
> 
> ERROR: File '.../file\rname,v' would result in an illegal SVN 
> filename: Character '\r' in filename 'file\rname' is not supported by
>  Subversion.
> 
> Perhaps this is true for subversion, but git doesn't care.

Thanks for your email and the patches.

Indeed, git seems more tolerant of weird characters in filenames.
(Whether it is advisable to use such characters is another question :-) )

I found in the git-fast-import manpage:

> A <path> string must use UNIX-style directory separators (forward
> slash /), may contain any byte other than LF, and must not start with
> double quote (").
>
> If an LF or double quote must be encoded into <path> shell-style
> quoting should be used, e.g. "path/with\n and \" in it".
>
> The value of <path> must be in canonical form. That is it must not:
>
> * contain an empty directory component (e.g. foo//bar is invalid),
> * end with a directory separator (e.g. foo/ is invalid),
> * start with a directory separator (e.g. /foo is invalid),
> * contain the special component . or .. (e.g. foo/./bar and foo/../bar
>   are invalid).
>
> It is recommended that <path> always be encoded using UTF-8.

Presumably NUL characters are also forbidden in path names, as these are
not allowed by posix.

Nothing is said about backslash characters '\'.  Presumably if they are
allowed, they have to be escaped too ('\\').  On the other hand, given
that Windows uses backslash as a path separator, it would be madness to
include them in a filename.

I tried "git fast-export" on a repository containing pathological
filenames, but it doesn't do any escaping at all, producing (at least in
the case of LF) an unreadable dumpfile.

But in any case, your point that git is not so picky about filenames is
well taken.

> Attached are two patches that produce "works for me".  As I didn't 
> test what git will and won't let me put into a filename beyond \r,
> the regexp is probably still too narrow, but easy to fix.
> 
> The first patch refactors common.py so that it can import context.py.
> The second is the actual change to use a different regexp for
> verify_svn_filename_legal when targetting git, based on a new 
> git_target variable in the context object.

Unfortunately, your patches are against the 2.3.x branch of cvs2svn
rather than trunk, and don't apply to trunk.  Instead, I am working on a
solution that is somewhat more general, allowing for the possibility
that bzr and hg might have different rules:

I have added a method OutputOption.verify_filename_legal(), which is now
used for checking the validity of filename components.  Since
OutputOption is extended by classes specific to each VCS, it can easily
be overridden with VCS-specific rules.  This part is already committed
to trunk.

I will try to find out the exact rules for git and code them in
GitOutputOption.verify_filename_legal().

I would also like to add a new PrescanPass, which runs first.  This pass
would do a quick scan of the CVS repository and check all filenames.
This prevents the problem that filename problems are currently detected
during CollectRevsPass, which is quite slow for large repositories.  The
PrescanPass can give quick feedback about repository problems.  It can
eventually be extended with other quick checks.  This will also remove
the need for contrib/find_illegal_filenames.py, which was already
trivially broken and would have been more broken by the change to
VCS-specific filename checks.

No promises for when this is done, but it doesn't sound like this is
holding you up.

Thanks for the feedback!
Michael

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

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