On Tue, Nov 19, 2019 at 9:15 AM sebb <seb...@gmail.com> wrote: > > 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.
It's complicated, and a lot depends on what the use cases we intend to support are. For now, I've updated the Dockerfile to install a compatible version of subversion, and updated DOCKER.md to explain the constraints. I actually developed these files using the /srv directory from the MACOSX instructions. My thoughts are that most people would feel more comfortable doing their browsing and updates in the host environment, so a shared mount would be in order. I definitely would not want to put repository data in images as those are frozen (i.e., updates would be done in separate layers and would take up more space). Similarly, I would not want to put repository data in container space as those go away when the container exits. Putting this data into a docker volume would work (and may be faster), but may be less convenient for people that want to access the data from their host. These constraints are particularly true for the whimsy directory. I'm comfortable exec'ing into the container and editing the files using vim, but others may want to use their Mac IDEs. > But for those who can cope with the possible issue, there could be another > build that uses host data under /svn I do most of my whimsy work on my Ubuntu desktop machine, but I recently updated the MACOSX instructions and have this working on my laptop. I'm more likely to use those instructions than the container instructions, but being able to share a /srv directory would be convenient for me, allowing me to switch between the two. > 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. Agreed, though for testing purposes I have defined a locally hosted subversion repository for the board agenda tests, allowing commits to be tested. > 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. The largest are iclas, cclas, grants, and member-apps. I believe that these are only used by one tool, and primarily to determine if there is a collision. In these days of terabyte hard drives, it isn't a huge issue for me, but may be for others. > > 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! - Sam Ruby
