As one of the few people working on kde-accessibility these days, I took it upon myself to check those rules. This was a bit harder than I imagined it would be, and harder than it should be due to lack of documentation (or possibly my lack of reading the existing documentation?) and some nuances of the rule syntax and kde's svn history itself. Just thismorning I finished this and want to share some things I learned here for others doing the same for other modules.
#1 match lines should end with a / in most cases.
if you are matching a path in svn, you have to remember to add the trailing / or you will get cryptic svn errors about being unable to get data of a non-object or somesuch. Thanks to argonel for pointing this out to me the other day.
#2 action recurse rules are tricky but necessary.
I first copied konversation's rules to start kdeaccessibility's ruleset, then merged in kdeaccessibility parts of kde-rules-main. There was a problem though, svn2git would get stuck when it got to creating the 4.0.0 tag, because the 4.0 branch didn't exist. Then I noticed a rule I had missed from kde-rules-main
match /(branches|tags)/KDE/([^/])/after adding that though, the import would fail even earlier than before, because the above match would match files as well as folders, so entries with /branches/KDE/4.0/README which cannot recurse (because it's not a folder...)
The answer was to make the recurse match only what it needed to, so to create the 4.0 branch I set it to match /branches/KDE/4.0/ with a min-revision and max-revision of when /branches/KDE/4.0/ was created.
Problem with that match is that it didn't match 4.1 or others, since the match is a regex this was easy to fix, just make the match terminate with $ so it only matched svn revisions that are folders 4.0, 4.1, etc. etc.
I'll start looking into another module's rules next, so we can get this migration to git done. Any opinion which module I should look into next (kdeaccessibility was a good choice as its apps never spent time in kdereview or playground...)