Answers.Body: <p>We use <a href="http://rsync.samba.org/" rel="nofollow">rsync</a>. This can either be run manually with your CLI or you could set up a cron to run it every so often. It's significantly faster than FTP.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-16T15:28:27.397Z
Answers.Text: Which folders do you rsync with?
Answers.UserDisplayName: Jacob Graf
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-16T15:31:58.270Z
Answers.Text: This will depend a bit on how your environment structure is setup, but we just do `public/uploads` and then keep all Assets paths to that folder. Those are the only files that change on a remote environment that wouldn't otherwise be in our repo.
Answers.UserDisplayName: Ryan Shrum
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-16T15:36:01.700Z
Answers.Text: So each of your developers sync to a central development server?
Answers.UserDisplayName: Jacob Graf
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-16T15:54:11.903Z
Answers.Text: Just in terms of the uploads; rsync is run to each dev's local setup. https://www.dropbox.com/s/o7u9w1ft2wi1zw8/rsync.jpg All the other files are handled via Git and go upwards
Answers.UserDisplayName: Ryan Shrum
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-16T15:57:06.743Z
Answers.Text: For my own understanding: @RyanShrum When you say "repo", do you mean git repo? Are you excluding these files from your git repo? If so, why? If they were in git repo, couldn't each developer pull them down to respective local dev environments, and then the shared remote dev DB would know about them?
Answers.UserDisplayName: Andrea DeMers
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-16T15:57:07.860Z
Answers.Text: Got ya so in order for this to work, an upload must take place on a shared development server and cannot happen from the local environment that's using the shared DB, right?
Answers.UserDisplayName: Jacob Graf
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-16T16:00:15.270Z
Answers.Text: @AndreaDeMers - Yes. we've always left upload directories out of our Git repositories, for no other reason than file size.
Answers.UserDisplayName: Ryan Shrum
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-16T16:01:55.750Z
Answers.Text: @JacobGraf You are correct, though I presume you could do something similar between the local environments. I assumed that you were dealing with a shared file server when you referenced a shared DB.
Answers.UserDisplayName: Ryan Shrum
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-16T16:42:37.510Z
Answers.Text: Thanks for your insight Ryan! Anyone else do anything different?
Answers.UserDisplayName: Jacob Graf
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-16T15:25:11.427Z
Answers.LastActivityDate: 2014-07-16T15:25:11.427Z
Answers.UserDisplayName: Ryan Shrum
Answers.Body: <p>I think Ryan's solution is the best, but since you're looking for other ways...</p>
  
  <p><a href="http://www.panic.com/transmit/" rel="nofollow noreferrer">Transmit's</a> sync feature works very well for user upload directories. Sync down or sync up as needed. I use this only for user upload directories (for me <code>html/assets</code>). Everything else is handled with Git, similar to the way Ryan described. I also <code>gitignore</code> the user upload directories (seems the wise thing to do).</p>
  
  <p>Here is a screenshot of Transmit's sync dialogue.</p>
  
  <p><img src="https://i.sstatic.net/Om8Di.png" alt="Transmit sync dialogue"></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-16T17:22:50.120Z
Answers.LastActivityDate: 2014-07-16T17:22:50.120Z
Answers.UserDisplayName: Alex Kendrick
Answers.Body: <p>I just ran across this with a dev enviroment and live enviroment. I ended up setting the asset url as an absolute path pointing to live. So that when entries are created on live, and images are uploaded, dev will then use the urls from live for the images, since I have dev and live both pointing to the same db.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T21:31:10.107Z
Answers.LastActivityDate: 2015-10-30T21:31:10.107Z
Answers.UserDisplayName: Bowenac
Body: <p>I am curious how those of you who use a multi-environment development process handle user upload directories? If you use a remote database and one developer uploads some test content, the shared database will think there are files on the other developers machine and they won't be there. This would also show its face if you access a staging server. The database would be out of sync with the upload directory.</p>
  
  <p>Thanks for your input.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-07-16T21:37:21.983Z
Comments.Text: Thanks for the feedback. I "think" I have found a pretty nifty solution to the problem. I have been using Amazon S3 as my assets source which solves the issue. I was recently thinking about switching back to local storage to see if there would be any performance gains but then I thought about the version control issue I asked about. Is anyone seeing any downsides to using Amazon S3 in this situation? By using that, everybody can upload/download and it all stays in sync with the shared development database.
Comments.UserDisplayName: Jacob Graf
Tags: <assets><multi-environment>
Title: Multi-Environment Uploads
ThreadText: # Multi-Environment Uploads
  
  (Asked by: username_0 on 2014-07-16)
  
  I am curious how those of you who use a multi-environment development process handle user upload directories? If you use a remote database and one developer uploads some test content, the shared database will think there are files on the other developers machine and they won't be there. This would also show its face if you access a staging server. The database would be out of sync with the upload directory.
  
  Thanks for your input.
  
  **Tags:** assets, multi-environment
  
  > **Comments:**
  > **username_0**: Thanks for the feedback. I "think" I have found a pretty nifty solution to the problem. I have been using Amazon S3 as my assets source which solves the issue. I was recently thinking about switching back to local storage to see if there would be any performance gains but then I thought about the version control issue I asked about. Is anyone seeing any downsides to using Amazon S3 in this situation? By using that, everybody can upload/download and it all stays in sync with the shared development database.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2014-07-16. Score: 3 | Accepted answer
  
  We use [rsync](http://rsync.samba.org/). This can either be run manually with your CLI or you could set up a cron to run it every so often. It's significantly faster than FTP.
  
  > **Comments:**
  > **username_0**: Which folders do you rsync with?  
  > **username_1**: This will depend a bit on how your environment structure is setup, but we just do `public/uploads` and then keep all Assets paths to that folder. Those are the only files that change on a remote environment that wouldn't otherwise be in our repo.  
  > **username_0**: So each of your developers sync to a central development server?  
  > **username_1**: Just in terms of the uploads; rsync is run to each dev's local setup. https://www.dropbox.com/s/o7u9w1ft2wi1zw8/rsync.jpg All the other files are handled via Git and go upwards  
  > **username_2**: For my own understanding: @username_1 When you say "repo", do you mean git repo? Are you excluding these files from your git repo? If so, why? If they were in git repo, couldn't each developer pull them down to respective local dev environments, and then the shared remote dev DB would know about them?  
  > **username_0**: Got ya so in order for this to work, an upload must take place on a shared development server and cannot happen from the local environment that's using the shared DB, right?  
  > **username_1**: @username_2 - Yes. we've always left upload directories out of our Git repositories, for no other reason than file size.  
  > **username_1**: @username_0 You are correct, though I presume you could do something similar between the local environments. I assumed that you were dealing with a shared file server when you referenced a shared DB.  
  > **username_0**: Thanks for your insight username_1! Anyone else do anything different?  
  
  ---
  
  ### Answer by username_3 on 2014-07-16. Score: 3
  
  I think username_1's solution is the best, but since you're looking for other ways...
  
  [Transmit's](http://www.panic.com/transmit/) sync feature works very well for user upload directories. Sync down or sync up as needed. I use this only for user upload directories (for me `html/assets`). Everything else is handled with Git, similar to the way username_1 described. I also `gitignore` the user upload directories (seems the wise thing to do).
  
  Here is a screenshot of Transmit's sync dialogue.
  
  ![Transmit sync dialogue](https://i.sstatic.net/Om8Di.png)
  
  
  ---
  
  ### Answer by username_4 on 2015-10-30. Score: 2
  
  I just ran across this with a dev enviroment and live enviroment. I ended up setting the asset url as an absolute path pointing to live. So that when entries are created on live, and images are uploaded, dev will then use the urls from live for the images, since I have dev and live both pointing to the same db.
  
  
  ---
  
  