Ugh. Of course update.sh won't be there if the repo is missing, but I meant having some sort of script in the VM image that handles checking out the repo and running the setup steps (including update.sh). Alternatively, could be a wrapper script that handles cloning the repo and initializing the VM (similar to ievms).
On Thu, Apr 3, 2014 at 10:15 AM, Cory Johns <[email protected]> wrote: > +1 for shared folder, as well, but could we possibly make update.sh handle > the git clone from the vagrant side if the code is missing? > > > On Thu, Apr 3, 2014 at 6:41 AM, Wayne Witzel III <[email protected]>wrote: > >> +1 shared folder. Like Tim said, it is what people who are used to >> developing with Vagrant expect. FWIW I've also never felt the shared >> folders in Vagrant were slow. >> >> >> On Thu, Apr 3, 2014 at 1:31 AM, Igor Bondarenko <[email protected]> >> wrote: >> >> > +1 for leaving shared folder setup as is >> > >> > >> > On Thu, Apr 3, 2014 at 7:12 AM, Tim Van Steenburgh < >> > [email protected] >> > > wrote: >> > >> > > 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 >> > > > <>< >> > > > >> > > > >> > > >> > > >> > > >> > >> > >
