On Wed, Feb 23, 2011 at 3:54 PM, MDavis <marty1...@gmail.com> wrote: > > I am unsure as to the best practice regarding the repository. Is it > best to create an individual repository for each site?
I would say so, yes. I'm pretty sure one of the main reasons the "one repo per machine" model is popular is due to svn caring more about directories than other things. You could use one repo for all your sites, but you'd probably end up feeling like you were bashing your head against the VCS. > I did create a > repository in one non-essential website; it created a ".git" directory > in the webroot (/home/username/public_html/.git) and at the same level > as pre-existing files. I did both add and commit commands. The > repository was updated successfully. > > Should the repository exist in the webroot or should it be at the same > level? (Perhaps "/home/username/git"?) > > What is the best way to deal with multiple sites on one server? > > Well, there's different ways to go about it. Quite a few people are of the opinion that the version of the site that's hosted shouldn't be in a repo at all, just an export of a specific revision. I prefer the "production" version to be an export, not a repo -- there's generally no need for code history on production. Your needs or preferences may differ. Here's how I deploy multiple sites on one server: (Disclaimer, I am not a guru) The git repo is on my local machine, possibly also on github or some other shared place. I set up VirtualHosts for each site. I go with the "stick em in /home/sitename, create a user and for the site, make sure that whatever needs permissions is in the appropriate group, add my "deployment" public key to the site user's .authorized_keys." I've been considering having apache run each virtual host as the respective user, but again, I'm not a guru. When I want to deploy, I generally create a tag in the repo on my machine, and use fabric ( http://docs.fabfile.org/0.9.4/ ) to export the correct version of the tag, ssh into the machine as the user, do whatever backup needs done, and write in the new version of the files. There are upsides and downsides to deployment methods, and everything else you can make a decision about in the process. I definitely recommend you look into a tool like fabric or capistrano for deployment, it makes things quite a bit easier. Oh, and when you have your process down, you should probably automate it so you don't have to do all that mucking around manually. Have fun! -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
