wow. thanks. that gave me some good ideas. i think u were right about rsync. it was pretty easy to set up. assuming the name of my app is myapp, i just put the following alias in my ~/.bash_profile on my local machine. alias mapush='rsync -e ssh -av --exclude=".DS_Store" ~/Projects/myapp/myapp.com/ matt@xxxxxxxxxxxxxxxxxx:projects/myapp.com/' btw, is there a way to make aliases that are local to certain directories? like typing mapush works from any directory. what if i just wanted the alias to be push and only work from within ~/Projects/myapp? is that possible? those aren't the actual paths i used. but u get the point. then i just type mapush and it does it. and i just use a local git repository in ~/Projects/myapp/.git to track local changes since none are made on the server... so i don't need a git repo there like u said... it's pretty fast. but will rsync be okay if i decide to move files around a bit? i know git is pretty good about that. and what if i delete certain files? will rsync delete them... like git does? guess i'll figure those questions out in time. thanks! -matt On Mon, Aug 3, 2009 at 2:58 PM, Wesley J. Landaker<wjl@xxxxxxxxxxxxx> wrote: > On Monday 03 August 2009 12:09:26 Matt Di Pasquale wrote: >> yes... i've thought of that. that's a good idea. i just love git and >> i've never really used rsync. how do i do that? >> i'll go google it.. > > Rsync can do a lot of things, but the usual easy way to do it is to do > something like this to send files via rsync over an ssh connection: > > rsync -av /some_dir/ user@host:/some_dir/ > > This is essentially the same as using scp, but rsync saves a lot of network > bandwidth by only sending the changes between the source and destination. > >> i guess it would also be nice to use git though incase i decide i want >> a collaborator, right? > > Setting things up to have a collaboration is kind of orthogonal to > installing a production version of your app, but you could use the same > server (and possibly the same git repository) for both things if you wanted > to. > > Here an example of one way to do it: > > On the server you could have a normal git repository in, say, > /home/me/myapp, and it always has the "production" branch checked out. So > now the following directories are interesting: > > /home/me/myapp -- repository branch w/ "production" checked out > /home/me/myapp/.git -- the actual bare git repository > /home/me/myapp/example.com/ -- the files that the web server should see > > Now, you can use symlinks (or web-server configuration) to point the > webserver to the right locations, for example: > > http://example.com/myapp/ -- link to /home/me/myapp/example.com/ > http://example.com/myapp.git/ -- link to /home/me/myapp/.git/ > > Now, collaborators can pull from the http://example.com/myapp.git and get > the whole project, but access to http://example.com/myapp/ sees the > example.com subdir as it's root, and everything works normally (assuming > webserver configuration & permissions are correct). > > Now you work on whatever branches you want, and push to the server whenever > you want for collaboration using whatever branches you want. As far as the > webserver is concerned, nothing changes when you do a push. > > Then, when you are ready to change the website, you put your production > changes on the "production" branch, push them, and make sure they are > checked out on the server (git push doesn't automatically check out the > files), e.g.: > > client$ # just made changes in production branch and want them "live" > client$ git push > > server$ cd /home/me/myapp > server$ git reset --hard > >> how would u set it up? > > Personally, I might set something like this if I had a good reason, but > otherwise, I'd host my git repository for collaboration separately, and just > use rsync to install production files on the server. For one thing, that > needs less prerequisites and setup on the server, so it's good if you don't > fully control the server. > > Either way, a "production" branch is a good idea so you know logically > exactly what and when you released things live. > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html