/var/www / site root thoughts

[wizonesolutions]

So I got a little caught out by the symlink to /var/www — probably because it didn't happen on my vagrant-parallels box, but that is probably the provider's fault.

I notice the default Apache host is set to /var/www — maybe the idea is that I set up my own vhost anyway, but it'd be nice to know the VM's expectations for this. And nice if there was a script to do it fast.

Mostly cuz if I run vagrant provision again my Apache config changes would be overwritten no? And such. Not that I intend to though :)

[tizzo]

I'm not sure what you mean by the symlink… Are you referring to the file share?

The default apache host is there but we generally don't really use it. We have the tool that deploys our code generate and deploy the apache vhost configuration (in our case that's fetcher). Puppet won't remove configuration files that it doesn't know anything about and so re-provisioning doesn't delete vhosts added in /etc/apache2/sites-available or /etc/apache2/sites-enabled.

[wizonesolutions]

Ah, I see. For Fetcher it seems like I have to set it up on the remote host that I want to import first and then connect to that from my VM?

[tizzo]

Sort of. Fetcher can create a fresh site (drush fetcher-create) or it can
create a local copy of a site already setup in a remote environment. In the
latter case fetcher needs the list of remote sites and information about
their hosts. This can be pulled from a drush alias with some extra
configuration array keys set or it can pull from a web service using
the fetcher
services module http://drupal.org/project/fetcher_services (or you could
roll some other backend, it's pluggable).

I'm actively working on building out some improved documentation for
fetcher. I'll update this issue as I get things together.

On Wed, Oct 9, 2013 at 5:58 AM, Kevin Kaland notifications@github.comwrote:

Ah, I see. For Fetcher it seems like I have to set it up on the remote
host that I want to import first and then connect to that from my VM?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-25959319
.

[wizonesolutions]

Cool, will keep an eye. Something I am really trying to work out is a good, easy way to do two-way file sync and avoid the NFS penalty on Big Enough Sites. Totally unrelated...but randomly wondered if you had thoughts on that.

[tizzo]

I haven't found the NFS penalty to be too bad, but I've also been known to
turn off the NFS share because I live in vim anyway. I should add
documentation on how to turn off the share. There are 2 config changes you
need to make for that to work.

On Thu, Oct 10, 2013 at 11:44 AM, Kevin Kaland notifications@github.comwrote:

Cool, will keep an eye. Something I am really trying to work out is a
good, easy way to do two-way file sync and avoid the NFS penalty on Big
Enough Sites. Totally unrelated...but randomly wondered if you had thoughts
on that.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-26065167
.

[wizonesolutions]

Yeah, I know how to turn off the share, just a pain to get it all syncing sometimes. I use the big brother of PhpStorm + IdeaVim, so it is still nice to have the file syncing.

I think I'm going to kick the tires of vagrant-unison again and see if two-way sync is possible with that. There don't seem to be that many good ways to sync. OwnCloud publishes the tools it uses, which I might look at if push comes to shove. SparkleShare is Git-based, but code is often also Git-based, so that doesn't necessarily work too well.

My hacked-up dumb combo of IDE-syncs-updated-files-to-VM + VM syncs sites/all changes to VM (covers most Drush operations, e.g. drush fu -y, which is what I'd like to say to the state of two-way syncing). But annoying and very un-general. And if I forget about it sometimes it clobbers my changes to stuff.

:/

[tizzo]

Oh, getting it syncing. Right. Yeah, I don't know how much we can improve
on that. Unison (or similar functionality built directly into netbeans or
simliar) is always going to be a bit slow. I just ssh into the server and
use vim. When tricked out with some of the hot new plugins it gives me
everything I want in an IDE, but I know it's not for everyone.

On Thu, Oct 10, 2013 at 3:30 PM, Kevin Kaland notifications@github.comwrote:

Yeah, I know how to turn off the share, just a pain to get it all syncing
sometimes. I use the big brother of PhpStorm + IdeaVim, so it is still nice
to have the file syncing.

I think I'm going to kick the tires of vagrant-unison again and see if
two-way sync is possible with that. There don't seem to be that many good
ways to sync. OwnCloud publishes the tools it uses, which I might look at
if push comes to shove. SparkleShare is Git-based, but code is often also
Git-based, so that doesn't necessarily work too well.

My hacked-up dumb combo of IDE-syncs-updated-files-to-VM + VM syncs
sites/all changes to VM (covers most Drush operations, e.g. drush fu -y,
which is what I'd like to say to the state of two-way syncing). But
annoying and very un-general. And if I forget about it sometimes it
clobbers my changes to stuff.

:/

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-26083610
.

[wizonesolutions]

I like Vim for everything except debugging. Debugging's much easier to do with a dedicated debugging tool.

Yeah, I hear you on the slowness. I actually find that it doesn't measurably shorten the feedback loop, probably since the SSH connection happens locally. I just know that on this one site it finally became tolerable after I moved the files in-VM. By tolerable, I mean that pages load in 5-10 secs instead of 10-20 ;)

Vim's always an option in some contexts, though. Thanks for the thoughts.

[tizzo]

I've been using vdebug https://github.com/joonty/vdebug for debugging. It
takes a little while to get comfortable with the keyboard shortcuts but now
I prefer it to task switching to a slower and heavier IDE like netbeans.

On Thu, Oct 10, 2013 at 5:45 PM, Kevin Kaland notifications@github.comwrote:

I like Vim for everything except debugging. Debugging's much easier to do
with a dedicated debugging tool.

Yeah, I hear you on the slowness. I actually find that it doesn't
measurably shorten the feedback loop, probably since the SSH connection
happens locally. I just know that on this one site it finally became
tolerable after I moved the files in-VM. By tolerable, I mean that pages
load in 5-10 secs instead of 10-20 ;)

Vim's always an option in some contexts, though. Thanks for the thoughts.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-26094565
.