> On May 29, 2014, 7:58 a.m., Mark Chu-Carroll wrote: > > Why? > > > > Right now, I do a lot of debugging of the client using vagrant. My typical > > workflow is: > > - Make the change in my git workspace. > > - Commit it to a branch. > > - vagrant ssh into the virtual cluster > > - git pull /vagrant mybranch > > - build client > > - test > > > > If we eliminate that .git file, then the aurora copy in the vagrant host > > can no longer be used for pulls. We can't just use the /vagrant copy, > > because that's got a ton of state. > > > > With this change, to do a similar dev workflow, I'd need to create a git > > workspace cloned from /vagrant, and also add new stuff to copy the > > resulting aurora/aurora2 pexes into the original /vagrant copy. It makes > > the workflow more complicated, and I'm not clear on what benefits it > > produces in exchange. > > > > > > > > > > Bill Farner wrote: > The workflow would be slightly different than you describe. To update > builds in the VM, you would run "vagrant provision", and rsync will pick up > the changes. Does that sound reasonable? > > Mark Chu-Carroll wrote: > It's a *lot* slower. Trying it out with a simple change in the client, > the round-trip time for a change using git is under five seconds, for git > commit, git pull, and pants to build the client. > > Running vagrant provision took one minute and 20 seconds for an > equivalent process. > > It's just a minute - but between the different things I'm working on, I > literally did that more than 20 times today. > > It's a very significant increase in time, for an uncertain benefit. What > do we gain by eliminating that .git from the provisioned copy of the > workspace? If we're really getting something out of eliminating the git > metadata from the provisioned vagrant image, then it might be worth the > price. But if not, then why are we making work harder? > > > > > Bill Farner wrote: > > It's a *lot* slower. Trying it out with a simple change in the client, > the round-trip time for a change using git is under five seconds, for git > commit, git pull, and pants to build the client. > > Yup, it's bound to be slower as-is given that there are more builds > taking place. Looks like the only way to pass arguments to the provisioner > script is via environment variables. How would you feel about that to let > you rebuild only specific components? > > > If we're really getting something out of eliminating the git metadata > from the provisioned vagrant image, then it might be worth the price. > > My intent is to standardize on the workflow within the vagrant > environment, leaning on vagrant to hide details of copying code and building. > >
Seems like a giant kludge to work around something that isn't a problem. We've got a clean workflow that's fast, easy, and does a good job. Why not just document it, instead of trying to retrofit vagrant provisioning into doing something that it wasn't meant to do? If you really dislike using git for this, why not just write a companion script that does the rsync, instead of kludging the provisioner? - Mark ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22008/#review44255 ----------------------------------------------------------- On May 29, 2014, 12:43 a.m., Bill Farner wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/22008/ > ----------------------------------------------------------- > > (Updated May 29, 2014, 12:43 a.m.) > > > Review request for Aurora and Mark Chu-Carroll. > > > Repository: aurora > > > Description > ------- > > Exclude .git from rsync copy in vagrant. > > > Diffs > ----- > > examples/vagrant/provision-dev-cluster.sh > ce936c19a42f4968d4706e6ef38c25db01ae2c5d > > Diff: https://reviews.apache.org/r/22008/diff/ > > > Testing > ------- > > vagrant up > > > Thanks, > > Bill Farner > >
