Well, I don't imagine there's anything analogous to "svn switch" for, say, git. It does seem like individual SCMs will have entirely different concepts involved.
For example, having a remote SVN cached checkout which just does an "svn update" or "svn switch" from the main repository -- this makes sense for SVN, as long as you make sure the revision matches that of the local checkout. (I forget whether Cap does that by default, or whether that's something else I hacked together...) For a distributed system like git -- or bzr, or hg, etc -- it seems like the simplest thing to do would be to push changes from the current local checkout to the same cached copy. And it seems like, once you had it cached on one server, it would make sense to push it from that server to the rest -- simple example is, bandwidth between EC2 instances is free. In fact, I think someone's done a GitRemoteSharedCache or something like that. Now, if it was my project, I wouldn't mind dictating an SCM, but as long as you're going to support all of them, it seems like the best strategies for each are going to at least be specific to a flavor of SCM (distributed vs centralized), if not specific to that exact SCM. (I like to auto-tag in SVN, and then deploy that tag -- and production deploy tags are clones of staging deploy tags. The way in which I do this would be madness in CVS, at least, and I doubt it'd make much sense in Git.) On Wed, Apr 30, 2008 at 11:06 PM, Jamis Buck <[EMAIL PROTECTED]> wrote: > Aaaaand a month later, Jamis resurrects the thread! Sorry to let is sit in > my inbox so long. > > I like this idea, Ezra. My only concern would be implementing it in such a > way that we could make it work with the generic SCM interface. Then again, > maybe I'm trying too hard? Perhaps some of these strategies really are going > to be specific to individual SCM's? > > - Jamis > > On Mar 21, 2008, at 10:38 AM, Ezra F wrote: > > > > I may be oversimplifying, but why can't we run an svn switch instead > > of an svn update? If the repository hasn't changed to a different > > branch, svn switch -r<x> will have the same effect as the current svn > > update, if the repository has changed, it will update the code to the > > specified revision on the specified branch (from my perspective, the > > desired behavior). > > > > From the example that initiated this thread, we'd replace the: > > svn update -q -r18 /srv/rails/redken/shared/cached-copy > > with > > svn switch > > http://code.digitalpulp.com/svn/redken/redken/branches/release_1 > > -q -r18 /srv/rails/redken/shared/cached-copy > > > > Ezra > > > > > > On Mar 9, 2:44 pm, Szymon Jeż <[EMAIL PROTECTED]> wrote: > > > > > On 31 Sty, 05:07, Jamis Buck <[EMAIL PROTECTED]> wrote: > > > > > > Yup, remote_cache just does an svn up and copy--it has absolutely no > > > > intelligence built-in for branching and so forth. I'm sorry that bit > > > > you. > > > > > > > > > > If anyone has the inclination, a patch would be welcome, so long as > > > > it > > > > did not complicate the common case. > > > > > > > > > > - Jamis > > > > > > > > > > I have an idea. > > > Lets cache the whole repository on the remote server. Not only one > > > branch(trunk, tag). > > > # in your application deploy recipe > > > # instead of > > > # set :repository, "your_repo_url/my_app/trunk" > > > # write > > > set :repository, "your_repo_url/my_app" > > > # and set a branch variable > > > set :branch, "trunk" # the user can change it acording to varialbes > > > set via the CLI or based on the current stage etc. > > > > > > And lets copy not the whole shared_path/cached-copy but the specified > > > branch from the cached copy to the release_path > > > #in capistrano/recipes/deploy/strategy/remote_cashe.rb > > > # add this method > > > def repository_cache_branch > > > File.join(repository_cache, configuration[:branch] || "") > > > end > > > # and change the original copy_repository_cache method to this > > > def copy_repository_cache > > > logger.trace "copying the cached version to > > > #{configuration[:release_path]}" > > > run "cp -RPp #{repository_cache_branch} > > > #{configuration[:release_path]} && #{mark}" # repository_cache > > > replaced by repository_cache_branch > > > end > > > > > > Here is the diff patchhttp:// > > > www.szymon.jez.net.pl/files/remote_cache.rb.diff > > > > > > The changes made in this patch are backwards compatible. They don't > > > affect the way people were using remote_cache. When the variable > > > branch is not set and the variable repository is pointing directly to > > > a branch it will work as always. > > > > > > I tested this with my production app using capistrano-2.2.0 > > > > > > I think it could be applied to capistrano's trunk. > > > Szymon > > > > > > PS. Thanks everyone(especially James) for contributing to Capistano > > > it's a great tool. > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
