git-svn 忽略 Windows 上的颠覆配置文件（自动道具）

Question

This is my first question here, I hope am not doing anything wrong.

As the title suggests, I am trying to work with git-svn on a project which has a central SVN repository. The SVN repository uses auto-props, and if these are not properly set in the local SVN configuration file, the commit is rejected.

I have read everywhere, including here on StackOverflow, that git-svn is smart enough to read and honor the svn configuration file, so if I already configured my Subversion client properly, git-svn should just work. Unfortunately this is not being the case for me.

Here is the content of my SVN config file, the location if which is C:\\Users[myusername]\\AppData\\Roaming\\Subversion\\config . I removed all the comments (and only the comments).

[auth]

[helpers]

[tunnels]

[miscellany]
global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* *.swp ~*
enable-auto-props = yes
use-commit-times = yes

[auto-props]
*.e = svn:keywords=Author Date ID Revision;svn:eol-style=native
*.c = svn:keywords=Author Date ID Revision;svn:eol-style=native
*.h = svn:keywords=Author Date ID Revision;svn:eol-style=native
*.cpp = svn:keywords=Author Date ID Revision;svn:eol-style=native
*.y = svn:keywords=Author Date ID Revision;svn:eol-style=native
*.py = svn:keywords=Author Date ID Revision;svn:eol-style=native
*.ecf = svn:keywords=Author Date ID Revision;svn:eol-style=native
*.xace = svn:keywords=Author Date ID Revision;svn:eol-style=native
*.ace = svn:keywords=Author Date ID Revision;svn:eol-style=native
*.ge = svn:keywords=Author Date ID Revision;svn:eol-style=native
*.eant = svn:keywords=Author Date ID Revision;svn:eol-style=native
*.bm = svn:keywords=Author Date ID Revision;svn:eol-style=native
*.bat = svn:keywords=Author Date ID Revision;svn:eol-style=native
*.sh = svn:keywords=Author Date ID Revision;svn:eol-style=native
*.xeb = svn:keywords=Author Date ID Revision;svn:eol-style=native
Mak* = svn:keywords=Author Date ID Revision;svn:eol-style=native
tcf = svn:eol-style=native
output = svn:eol-style=native
output? = svn:eol-style=native

Committing with SVN works perfectly, and it stops working (the server rejects it saying that a required auto-prop is not set) if I edit this file and set enable-auto-props to no , so this is the right file to edit and it is being parsed. Sadly, git-svn ignores this entirely, and Dcommitting always fail with the same error message, which is the following:

ERROR from SVN:
A repository hook failed: MERGE request failed on '/[url omitted]/Src': Commit blocked by pre-commit hook (exit code 1) with output:
Props 'svn:keywords=author date id revision' missing (or not expected)
Props 'svn:eol-style=native' missing (or not expected)
Props issue on: /[url omitted]/some_file.cpp

this message is repeated several times for all the files with relevant extension that I am trying to commit.

I read in a comment to a StackOverflow answer somewhere that on Windows there might be another copy of the Subversion config file, located in "C:\\Users[myusername].subversion\\config", but this wasn't the for me. Just to be sure, I copied the config file to this path and nothing changed.

I am surprised that this doesn't seem to be a common problem. I was expecting to find loads of people asking the same question on the Internet, but this doesn't seem to be the case. When people ask about auto-props, the answer is always just that git-svn should be honoring the SVN config file, usually followed by "thank you, it works!", so it is likely to depend on something in my installation, but I don't honestly have a clue of how I can troubleshoot that.

Thank you for reading and thank you in advance for your help.

Answer 1

Ok, I found the solution. The guess was that git-svn was ignoring my configuration because it was looking for the configuration file in the wrong place. I decided I wanted to find where git was actually storing git configuration and I found on stack the command git config --global --edit will do this (it will open an editor, from which you can see where the file is located).

It turned out that, unlike Subversion's, the git configuration was on a network drive on my machine, where my domain user profile is stored. I found another copy of the SVN config file on that drive, replaced it with the correct file, and now git-svn works like a charm.

Even though I believe something on my machine must be improperly configured, this solved my problem.