Sometimes, it’s useful to see what subversion’s actually doing when talking to a server. There’s a
neon-debug-mask option in
~/.subversion/servers. But what values can it take? They’re not documented in the subversion manual.
As always, the source is informative.
/* Debugging masks. */ #define NE_DBG_SOCKET (1<<0) /* raw socket */ #define NE_DBG_HTTP (1<<1) /* HTTP request/response handling */ #define NE_DBG_XML (1<<2) /* XML parser */ #define NE_DBG_HTTPAUTH (1<<3) /* HTTP authentication (hiding credentials) */ #define NE_DBG_HTTPPLAIN (1<<4) /* plaintext HTTP authentication */ #define NE_DBG_LOCKS (1<<5) /* WebDAV locking */ #define NE_DBG_XMLPARSE (1<<6) /* low-level XML parser */ #define NE_DBG_HTTPBODY (1<<7) /* HTTP response body blocks */ #define NE_DBG_SSL (1<<8) /* SSL/TLS */ #define NE_DBG_FLUSH (1<<30) /* always flush debugging */
Or if you’re not a C coder (or had to spent more than 3 seconds working it out like me):
- raw socket
- HTTP request/response handling
- XML parser
- HTTP authentication (hiding credentials)
- plaintext HTTP authentication
- WebDAV locking
- low-level XML parser
- HTTP response body blocks
- always flush debugging
These are summed to enable the features you want. So, if I want requests, responses and bodies, that’s 2+8+128, so I need this in
[global] neon-debug-mask = 138
Of course, interpreting the resulting output is up to you, but if you’re having difficulties, it may give you some clue what’s up. I can immediately see the large “log” command that
git svn rebase is using for instance.
One reply on “neon-debug-mask”
Thanks, this was a great jumping off point, and helped me narrow down my issue.