SVN Integration not working after upgrade to 1.1.213 from 0.9.161 "Object Moved to..."

Topics: General, Installing BugNET
Sep 26, 2012 at 2:26 PM

We previously had SVN integration up and running but since our upgrade to the latest 1.1.213 it no longer functions. When running the post-commit hook manually from the command line we get the following output: 

INFO - Starting post-commit...INFO - Executing IssueTrackerIntegration.UpdateIssueTrackerFromRevision("E:\Repositories\ghp", "1631")INFO - Running svnlook...DEBUG - Running Commandline: C:\Program Files (x86)\VisualSVN Server\bin\svnlook.exe info -r 1631 "E:\Repositories\ghp"DEBUG - svnlook output: C:\Program Files (x86)\VisualSVN Server\bin\svnlook.exeinfo -r 1631 "E:\Repositories\ghp"magnus2012-09-26 14:18:07 +0200 (on, 26 sep 2012)13SP-170: Fixed
DEBUG - Looking for search pattern in revision:1631 and repository:E:\Repositories\ghp...INFO - Found 3 matches...INFO - Getting svn log message.DEBUG - Running Commandline: C:\Program Files (x86)\VisualSVN Server\bin\svnlook.exe log -r 1631 "E:\Repositories\ghp"INFO - Logging in to BugNET webservices...INFO - Creating new issue revision...DEBUG - LogMessage:<a href="IssueDetail.aspx?id=170#top"><b>SP-170</b></a>: Fixed
ERROR - An error occurred adding a new issue revision to BugNET: The request failed with the error message:--<html><head><title>Object moved</title></head><body><h2>Object moved to <a href="/Account/Login.aspx?ReturnUrl=%2fWebServices%2fBugNetServices.asmx">here</a>.</h2></body></html>
    at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)   at BugNET.SubversionHooks.WebServices.BugNetServices.CreateNewIssueRevision(Int32 revision, Int32 issueId, String repository, String revisionAuthor, String revisionDate, String revisionMessage)   at BugNET.SubversionHooks.IssueTrackerIntegration.UpdateIssueTrackerFromRevision(String repository, String revision)INFO - Finished IssueTrackerIntegration.UpdateIssueTrackerFromRevision

Sep 26, 2012 at 2:51 PM
Edited Sep 26, 2012 at 2:52 PM

This seems like some kind of authentication issue due to the fact it is redirecting you to the Login.aspx page

Can you browse http://URL_TO_BUGNET/WebServices/BugNetServices.asmx  

Click on the LogIn link

From there enter in a valid login/pass to bugnet and hit Invoke this should open up a new result window and either have a true / false in it.

From there you can close the result window and then click on the CreateNewIssueRevision link

Enter in everything (must be a valid Issue id (number format only)) the rest can be anything and press Invoke

If all works you should be able to browse the issue in bugnet and in the revision tab see what you entered.

If this is the case then something is wrong with your SVN hook configuration or the webservice reference may need updating in the SVN hook code (not sure why it would need that but it might be a possibility).

There is also a permission set on the web service call where if the project is private and the user IN NOT a member of the project (for the issue) access is denied.  That is something you may have to check.

Sep 26, 2012 at 3:15 PM

Hi and thank you for your reply!


I can browse there, I get true for both the login and CreateNewIssueRevision methods.

The project is public and the user I use is set as super user

I doubt the issue is the SVN hook configuration since first of all it´s exactly the same as before the upgrade (which worked perfectly) and also I´ve tried running the post-commit.bat file directly from the commandline on the server with exactly the same result. So I guess that leaves two options:

  1. Error in BugNET.SubversionHooks.exe.Config
  2. Webservice reference needs updating

1. This file I´ve taken straight from my old working configuration, the username and password surely are correct, what else could be wrong here?

2. How do I do that?



Sep 26, 2012 at 5:31 PM

Did you use the username / password in the config file to test the web service methods?  The username and password would be what authenticates to the webservice and the user it uses to do the permission check.

2. You would need to download the source code and change the settings for the web service url in the app.config to match your URL of the web service then right click on the web service in visual studio and select update.

However I am not sure if that would fix the issue, it almost seems that the web service session has timed out before the actual call to create the issue revision.

In the past have you noticed how long it takes from the time you commit to the time the revision showed up in the issues revisions list?  The only other thing I can think of is the svnlook.exe commands are taking a long time to execute.

Sep 26, 2012 at 5:40 PM

Hi again,

Yes, I used the same username and password I use in the config xml. Also, in the log we do see this:

INFO - Logging in to BugNET webservices...

INFO - Creating new issue revision...

If I change the username and password to something incorrect it stops after the first line and never attempts to create new issue revision. It seems weird if I would need to update using the source, then the binary deployment seems useless. 

Regarding timing I´m not sure how long it used to take.... Right now the whole process (including error message) takes approximately 2,5 seconds so if it is timing out it seems like a pretty quick timeout...

Sep 26, 2012 at 7:01 PM

Welcome to my world of debugging software.... lol

I did a search for " web service object moved" and found lots of people having issues, most have random solutions here are the ones I found interesting, not sure if they will help or not. 

Other than that I am at a loss as to why it's all of a suddenly happening.  Since the web service works on it's own and the hook has no issue logging into the web service it's quite a mystery.

Wish I could be more help...

Sep 27, 2012 at 9:57 AM

Hi and thanks again for giving me some reading suggestions!

After reading your links and parsing a bnit of the source code for the Subversion hooks and playing with the settings I´m now fairly confident that it never actually is able to authenticate itself against the webservice :( . I was incorrect in my previous statement that if changing the username and password I never get to the second INFO line (Creating new issue revision), that was when I was still trying to use "BugNetWindowsAuthentication"=False in the xml config. When having this set to true it seems the subversion hooks doesn´t actually login until it calls the create new issue revision.  So it´s definately a "simple" authentication issue so is there anything I can do and try to change? I´m using a Windows Server 2k8 r2 and run bugnet as a separate website, I´m up for using either windows authentication or plain text or anything just as long as I can get this mess up and running again....


Sep 27, 2012 at 11:47 AM

Hi again,

Just as a final note: thanks to wrhighfield for responding. In the end I sort of gave up, created a new website (parallel to the one we use daily), set it to only use forms authentication, set the xml configuration to not use windows authentication and connected it to the same db as the "real" site... and it works.... Not ideal but at least it´s working... Perhaps someday I´ll take the time to investigate more why it doesn´t work against the real site using windows authentication but unfortunately I simply can´t spend anymore time on this...

So, if anyone experience the same issues I have one solution could be to set up a parallel bugnet site using using forms authentication and specify the hooks to not use windows authentication... 

Sep 27, 2012 at 2:49 PM

Yeah this does not sound like an ideal situation.

If you want could you contact me though codeplex and give me the following information:

  • Your subversion settings (at the project level and application settings level in bugnet)
  • Your ideal subversion hook config (how you would want it to work or the old one that worked)
  • how you setup the svn hook (any permissions you set, integrating it with SVN)
  • Your subversion configuration (using file access vs VisualSvn Server or another and it's config)

Of course no need to give me any passwords or company specific info you can describe the settings (i.e. username for the super user in bugnet or user on windows machine who has admin rights, etc.)

I can take a look at it and see if there are issues with the code and impersonation (which is what is happening Windows Auth environment).  Not sure when I would look at it but I can poke and see.

I have been working on a Mercurial hook and would be interested to see if it will have some of the same issues that the SVN one will have.