Hello,

I didn't know that git could store symlinks ?
Depending on the deployment recipe I guess there could be problems with relative
symlinks due to the fact that the 'current' deployed directory in default
capistrano structure is a symlink to a folder located in the releases dir.

The most common (at least I think so) is to create a task (with a callback after
the code deployment; I personally use «after "deploy:symlink"») that will add
the required symlinks in the public dir that links to real folders located in
the 'shared' dir, which is already used for pids and logs.

François Montel a écrit :
> I'm setting up capistrano with an existing project that has folders
> under /public, where files uploaded from users are stored (ie, /public/
> photos) that is not under version control. It's not part of the code
> and it's continually being updated, so I don't want it in my git repo
> (it's marked with git ignore so it isn't included).
> 
> The way capistrano seems to work is by checking out a new copy of the
> git repo every time deploy:update is run. So even if I copy the user
> data into the folder structure created by capistrano the first time I
> deploy, the next time I update, a new version will be checked out of
> the repo and that user data won't be there.
> 
> What's the preferred way to handle this? I could think of a couple of
> options:
> 
> 1. Store the files (ie, photos) in a folder outside of my app
> structure, and symlink it to public/photos. That symlink would be in
> my git repo so every fresh checkout would still point to the same user
> file folder.
> 
> 2. Maybe after my initial deploy, I shouldn't be using deploy:update
> more, but my own recipe that just performs git pull and restarts
> passenger. After all, I don't really want capistrano to perform a
> whole new checkout every time I update the code (that's time
> consuming). I just want it to update it with git pull. (Capistrano has
> nice rollback features, but I can roll back with git if I need to.)
> 
> Perhaps there are other or better ways to handle this.
> 
> Thanks for the help!
> 
> PS. Capistrano 2.3 has a scm: none option, but that seems to be for
> when the whole app is not under version control; not in the case of
> subfolders as mentioned above.
> > 


--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---

Reply via email to