On Tue, 19 Nov 2019 at 17:49, Sam Ruby <ru...@intertwingly.net> wrote:
> 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. > > OK > 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. > I see. > 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. > > Good point. > > 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. > > It's also a lot of data to download, and there might need to be a separate copy if the host version cannot be shared. In the case of iclas, I wrote a script to list the SVN repo contents and create empty files/directories locally. This works well with an empty checkout. > > 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 >
