http://weblogs.asp.net/jgonzalez/archive/tags/ssl/default.aspxTags: sslenCommunityServer 2007 SP1 (Build: 20510.895)http://weblogs.asp.net/jgonzalez/archive/2007/03/30/problems-updating-an-svn-external-in-subversion-using-https-ssl-via-cruisecontrol-net.aspxFri, 30 Mar 2007 05:51:24 GMTc06e2b9d-981a-45b4-a55f-ab0d8bbfdc1c:2149812likwidlikwid0http://weblogs.asp.net/jgonzalez/rsscomments.aspx?PostID=2149812http://weblogs.asp.net/jgonzalez/archive/2007/03/30/problems-updating-an-svn-external-in-subversion-using-https-ssl-via-cruisecontrol-net.aspx#commentsI have been diligently working on the build process here at work and I<br/>ran into an interesting problem. There is plenty of information on<br/>the matter on Thoughtworks website, but I wanted to post it here as a<br/>reference.<br/><br/>The problem is an interesting one, I don't know if I can explain it<br/>well enough, but I will try.<br/><br/>We have a couple of dependencies on third party files in our product.<br/>These third party files are part of our source code repository via a<br/>feature called Externals. I would say this is somewhat equatable to a<br/>symlink for Subversion. We can reference a different subversion<br/>repository as a directory in our repository.<br/><br/>Suppose I have a repository like this:<br/><br/>svnroot<br/> trunk<br/> MyCoolCode<br/><br/>I put all of my local project files into the "MyCoolCode" directory.<br/>Let's say someone has a really cool utility library that I want to<br/>include in my project as well. There are several options, but<br/>svn:Externals allows me to check out the code from a remote repository<br/>down into my local files. This makes managing the consumption of an<br/>external project much easier.<br/><br/>Back to the problem....I happen to be pulling this external codebase<br/>from an svn repository that is over https. So when I execute the svn<br/>update command from a command line for the first time, I get a warning<br/>or prompt stating that I need to either Reject, Accept Temporarily or<br/>Accept permanently the https certificate. This is all fine and dandy<br/>and it works when I do it manually, but my ccnet service is currently<br/>running under the LocalSystem account. I am just testing some things<br/>out with the build process in general, normally I would create a<br/>service account to run it under. What I ended up having to do was<br/>launch a cmd.exe running under the LocalSystem account and then run<br/>the svn update command again and permanently accept the http<br/>certificate.<br/><br/>A bit of a beating if you ask me. The links below made it pretty easy<br/>to solve the issue.<br/><br/><a href="http://confluence.public.thoughtworks.org/display/CCNET/Subversion+Source+Control+Block?showComments=false">http://confluence.public.thoughtworks.org/display/CCNET/Subversion+Source+Control+Block?showComments=false</a><br/><a href="http://confluence.public.thoughtworks.org/display/CCNET/The+Server+Service+Application">http://confluence.public.thoughtworks.org/display/CCNET/The+Server+Service+Application</a><br/><a href="http://blogs.msdn.com/adioltean/articles/271063.aspx">http://blogs.msdn.com/adioltean/articles/271063.aspx</a><br/><br/>[tags:subversion, svn, external, externals, build process, build,<br/>ccnet, cruisecontrol.net, http, ssl]<img src="http://weblogs.asp.net/aggbug.aspx?PostID=2149812" width="1" height="1">buildbuild processccnetcruisecontrol.netexternalexternalshttpsslsubversionsvn