A rule *that matches a directory* should end in a slash.
Say a SVN change arrives containing changes to /boost/bind/bind.hpp.
If you have a rule matching /boost/bind, svn2git will tell git-fast-import
to create a file called "/bind.hpp" (the trailing part of the SVN path that
wasn't matched by the regex). git-fast-import will then crash and burn
because paths in the fast-import stream must not have leading or trailing
In addition, this would match (say) /boost/bind.hpp and put it into a file
called ".hpp" which you probably don't want. Or anything else that happens
to start with 'bind'.
If your rule has a trailing slash, then "/boost/bind/bind.hpp" with the rule
regex "/boost/bind/" leaves "bind.hpp" to use as the path in the git
repository, and everything goes well.
Now, on exporting individual files. Let's say you want to put
/boost/bind.hpp into the repository as well. If you just make a rule
for "/boost/bind.hpp$" (the $ is usually a good idea when matching files!),
it would match the entire SVN path, and the unmatched trailing part to use
as git path would be empty. To avoid this, you have to use the 'prefix'
statement inside the rule to give it a filename (svn2git will append the
path it got, but as I said, it's empty):
Usually you would use captured subpatterns to your advantage here, by
matching /boost/(bind.hpp) and using \1 as the prefix.