If anyone has the inclination, a patch would be welcome, so long as it did not complicate the common case.
- Jamis On Jan 30, 2008, at 5:06 PM, John Joseph Bachir wrote:
I just experienced some unpleasant behavior when combining remote_cache and (trying to) switch branches. The moral of the story: maybe capistrano could intelligently detect a change in :repository, and either do something intelligent, or at the very least fail and tell the user to do a manual svn switch on the server. Would the capistrano devs be open to such a patch? ------- Read on for a description of the problem........... (making up numbers to make the situation easier to understand) My site was deployed with trunk at revision 10. I had a branch, release_1, which was a copy of trunk at revision 15. revision_1 was /created/ in changeset 18. Trunk was currently at revision 20. I am using remote_cache.In my deploy.rb, I changed :repository to point to release_1 and deployed.I assumed that one of two things would happen [1] capistrano would intelligently see the difference in paths and perform a switch [2] capistrano would get confused and encounter an error. Here is the command capistrano ended up with: * executing "if [ -d /srv/rails/redken/shared/cached-copy ]; then svn update -q -r18 /srv/rails/redken/shared/cached-copy; else svn checkout -q -r18 http://code.digitalpulp.com/svn/redken/redken/branches/release_1 /srv/rails/redken/shared/cached-copy; fi" servers: ["redkenweb"] Which of course ends up with: svn update -q -r18 /srv/rails/redken/shared/cached-copy, which completely ignores any notion of a new release url. John -- John Joseph Bachir http://blog.johnjosephbachir.org http://lyceum.ibiblio.org http://dissent.cc http://jjb.cc --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
smime.p7s
Description: S/MIME cryptographic signature
