On Tue, 19 Nov 2019 at 13:34, Sam Ruby <ru...@intertwingly.net> wrote:
> On Tue, Nov 19, 2019 at 8:17 AM sebb <seb...@gmail.com> wrote: > > > > On Tue, 19 Nov 2019 at 12:26, sebb <seb...@gmail.com> wrote: > > > > > docker:update had issues pulling down various svn repos, e.g. > > > > > > svn: E170013: Unable to connect to a repository at URL ... > > > svn: E125009: Invalid config: unable to load certificate file > > > '/Users/sebb/.subversion/Thawte_Premium_Server_CA.pem' > > > > > > I was able to remove the Invalid config error by changing /Users/sebb > => > > > /root > > > However I then got the error: > > > > > > svn: E000111: Error running context: Connection refused > > > > > > I assume that is because my SVN is set to grab passwords from the macOS > > > keychain > > > > > > > > Turns out that SVN was down at the time. > > > > Once I copied the cert to the expected place it worked OK. > > > > I've just realised that the /srv/svn directory is mounted from the host > OS. > > So checkouts in the image actually update the host working directory. > > Given that, it seems to me it would make more sense to do the check-out > on > > the host under /srv, and mount that instead. > > Two issues: > > 1) From time to time subversion makes changes to the file format. It > could be the case that the version of subversion you have on the host > is not compatible with the version of subversion in the container. > In which case having the checkout on the host filing system is risky. It would be safer to have the data all within the container, and not accessible from the host. AFAICT it should not take any more space overall. But for those who can cope with the possible issue, there could be another build that uses host data under /svn 2) Doing the checkout on the host only defers the problem. A number > of whimsy processes access svn (checkouts and commits). > > It might be useful to be able to disable commits for testing purposes. This is also true of LDAP. Regarding the SVN checkouts, maybe it would make sense to start by checking out only the top-level files/directories for some of the less-used/larger trees. > Also there does not seem to be a visual editor included in the docker > build. > > > (I had to use sed) > > > It would be useful to have vi(m) or such. > > I've been doing an "apt install vim" when needed, but, yes, it would > be nice to have vim already installed. There probably are a lot of > affordances that would be helpful. At one point I tried an "apachectl > status" and that failed as there wasn't a browser installed that it > could use to fetch the status. I no longer recall what other commands > I tried to use to check network status and the like only to find that > they weren't installed. > > - Sam Ruby > > P.S. Thanks for helping work through this! >
