Guidance for author mapping (3.3.14)

[oliver_kfs.org (kfsone)]

Running subgit mirror with https, config below. I see some users being remapped to my username in svn when their commits hit the master (Trunk) branch. Note that my username is the one in the config’s auth section.

The first user I looked at is not in the authors map or in the passwd file, so I read the documentation on author mapping.

I tried setting/changing mapGitCommitter (and restarting the translation process) but that had no effect; I tried adding the user to the authors mapping (and restarting the translation process) also had no effect.

Question 1

• Now that I am done with the initial import, would it be safe to switch to automatic mapping?

Question 2:

• Do I understand correctly that to continue with an authors mapping file, I need to have every new git user added to the authors mapping file AND the passwd file AND restart the background conversion process?

Question 3:

• For author mapping, does the passwd entry for each user need to be genuine, or only for the user used to making the https connection?

Question 4:

• Is it possible that having my username in the server URI is the cause of this, what do I look for in the logs to determine that subgit is making the change?

Thanks,

-Oliver

# This is SubGit configuration file.
[core]
        shared = false
        logs = subgit/logs
        authorsFile = subgit/authors.txt
        authorsFileEncoding = UTF-8
        defaultDomain = superevilmegacorp.com
        pathEncoding = UTF-8

[translate]
        eols = false
        ignores = true
        externals = true

[svn]
        url = https://oliver@svn/svn/repos/Project
        trunk = Trunk:refs/heads/Trunk
        branches = Branches/*:refs/heads/svn/branch/*
        branches = Tags/*:refs/heads/svn/tag/*
        fetchInterval = 60
        connectTimeout = 45
        readTimeout = 900
        httpSpooling = true
        keepGitCommitTime = false
        auth = default
        triggerGitGC = 100
        minimalRevision = 122441

[auth "default"]
        userName = oliver
        passwords = subgit/passwd
        useDefaultSubversionConfigurationDirectory = false
        subversionConfigurationDirectory = /var/opt/gitlab/.subversion
#       sshKeyFile = /var/opt/gitlab/.ssh/id-rsa-blank
#       sshKeyFilePassphrase =

[daemon]
        pidFile = subgit/daemon.pid
        idleTimeout = infinity
        classpath = subgit/lib

[hooks]
        directory = custom_hooks

[ildar.khusainov]

Hello Oliver,

• honestly, I’m not sure what do you mean saying it’s safe to switch to automatic mapping: SubGit always uses the automatic mapping in case it’s not able to find an appropriate mapping for a username. It’s possible, of course, to remove explicit mapping and thus switch to the automatic mapping completely, but it may lead to a mess with the names and incorrect license counting, we usually recommend the opposite, sticking with the explicit mapping.
• yes, if a user name (which for Git is name and email) is not present in the mapping, then it should be added to the authors file so that this new name is mapped to an SVN username; but at the same time no, there is no need to add that user in the passwords file – the passwords file’s purpose is to provide SubGit with an SVN credentials so that it’s able to login and read/write from/to the SVN repository. The passwords file only contains SVN user names, not Git ones; it is possible to set multiple names there and in this case SubGit will be using particular SVN user name to access SVN server, but such a setup is not mandatory, it is enough to set only one SVN username and password pair in the file. Restarting the background conversion process is not mandatory in case of authors file editing, the authors file changes are being applied on the fly.
• the passwords file does not relate to authors mapping directly, this file is aimed to store SVN credentials used to access SVN server. In case when multiple SVN credentials pairs are set in the passwords file, SubGit will check authors mapping file to find which SVN name is a Git user mapped to and will use this SVN username to access the SVN server – and that’s the only relation the passwords file has to the authors mapping. So, if the intend is only change authors mapping, there is no need to touch the passwords file at all.
• having a username in URI, probably, better to avoid, but if the same username is set in the passwords file, it shouldn’t be a problem. Regarding the issue when some commits appear in SVN authored by the SVN user set for SubGit access – this most probably is caused by an SVN specifics described in our authors mapping article:

If SubGit uses one dedicated SVN account (in cases of cached SVN credentials, only one provided SVN account or if no matching SVN accounts found in sugit/passwd) it works a little different. It connects to SVN, creates a new revision and sets the revision’s author equal to the SVN username it uses to log in. The problem is that this username usually is not correct author name - it might be, but commonly it differs. So SubGit then connects the SVN server second time and changes the newly created revision svn:author property to the correct author name.
And some additional configuration may be needed here, namely:

• if SVN server 1.7.20, 1.8.12 or 1.9.0 or later is used and it’s being accessed over http(s):// protocol
• or if the SVN server is being accessed over svn:// protocol
  then pre-revprop-change hook has to be enabled in the SVN repository. That requirement is introduced by SVN and that’s why we need to make some changes on SVN side.
  The hook per se is pretty simple: it just an executable file, script or binary, that may even do nothing, just start and exit. So you can just create as simple script as
• Linux and OS X:

  #!/bin/sh
  exit 0;

• Windows:

  @echo off
  exit 0

place it into SVN repository hooks directory:

    SVN_REPOSITORY/
        hooks/
            pre-revprop-change     # for Linux and OS X
            pre-revprop-change.bat # for Windows

make the file executable in Linux/MacOS

chmod +x pre_revprop_change

Hope this will help.

[oliver_kfs.org (kfsone)]

| Hope this will help.

Yes, thank you :) I’d missed the piece about needing to make a second connection, and was focusing on trying to stop it changing the name in the first place :)

this looks similar to the auth.userName and auth.password options we have described above and you may be wondering why the password file exists and why there are more than one username/password pair. The answer refers to authors mapping and how SubGit sets SVN revision author name during Git commit to SVN revision translation:

...
if, for any reason, there is no such user in the password file, SubGit uses any other available SVN account, creates new revision and sets the revision author name to this SVN username.

which, makes sense that it would need the password there.

Thank you Ildar,

• Oliver