FWIW, I would leave the shared folder setup as-is. I use this vagrant setup regularly for other projects and I’ve never noticed a performance penalty - it’s always felt as responsive as accessing local files. I would think people kind of expect this setup when using vagrant (if they’ve used it before anyway). And if we change it, we’ll only end up replacing the `git clone` instructions with nfs mount or rsync instructions.
On Wednesday, April 2, 2014 at 6:40 PM, Dave Brondsema wrote: > I'm working on building a new vagrant image, since the last image we built was > back in August. Our instructions [1] specify doing a git clone of the repo > (and > I actually missed that and got tripped up by lack of source!). But would it > make more sense to include the git repo within the machine image? That'd make > it easier to get up and running (especially if you don't have git installed on > the host). Code getting stale wouldn't be an issue since our Vagrant > instructions specify to run update.sh (http://update.sh) which includes a git > pull. > > The downside is that the allura source wouldn't be in a shared vagrant folder > for easy access with your favorite editor, it'd have to be edited with vim > inside the vagrant box. But shared vagrant folders are pretty slow anyway, so > its probably better to recommend development via a different shared method > (vagrant supports NFS or rsync now). See speed comparison at [2]. > > A different option would be to recommend downloading an official release > instead > of git clone. > > Yes? No? > > [1] > https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/ > [2] http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines > > -- > Dave Brondsema : [email protected] (mailto:[email protected]) > http://www.brondsema.net : personal > http://www.splike.com : programming > <>< > >
