Hi Scott,

you would be just what the doctor ordered - I'm certain ;)

- and that would automatically make you a Very Merry Man -  at least
you'd make this small bunch exorbitantly merry :)

enough with the off-topic'ness which I'm f(l)amed of - which is
certainly not something I do to making fun of other people (in fact
I'm deeply in debt to Jamis, you and who ever come up with all these
'wonderful toys*' - I just trying to squeze a little fuzzy logic into
this on/off world <:)

on another thread in this group, I have offered my deploy.rb, the
output from cap deploy:cold and what not - but if there is anything
you'd like me to try, investigate - anything at all - please say the
word (but caveat that I'm not really that much of a ruby programmer;
for one I am not able to write my own tests, and I like to think that
until you're writing your own tests, you should keep a very low
profile - so here I am with my nose barely of the mud) :)

cheers,
walt



On 19 Jun, 23:25, "Scott Chacon" <[EMAIL PROTECTED]> wrote:
> I'm largely curious if I am to be considered a Merry Man.  In
> particular, one of Jamis's Merry Men.  Anyhow, this is like the one
> open ticket onGitthat we have right now and since I don't use local
> repos to deploy from, and I haven't received a patch from anybody that
> it does affect, I haven't dug into it yet.  If I have time this
> weekend, since it has come up quite a bit now, I'll try to find some
> time to sit down and recreate this and see if I can't fix it without
> breaking something else.  :)
>
> If anyone has a suggestion that works for them that I could test, that
> would be helpful, otherwise I'll give recreating it a shot.  The
> easiest meantime workaround would be to put thegitrepo on an
> intermediate server that they both have ssh access to, even if it's
> the local or deployed server - just access it via ssh instead of
> file://.
>
> Thanks,
> Scott
>
> On Thu, Jun 19, 2008 at 2:14 PM, walt_d <[EMAIL PROTECTED]> wrote:
>
> > Well, looks like we're quite a bunch here - all tumbling around in the
> > dark, fighting the same piece of code :)
>
> > We could all hold hands and pray that Jamis & his Merry Men Will
> > Return <:)
>
> > On 17 Jun, 11:59, Michiel de Mare <[EMAIL PROTECTED]> wrote:
> >> I have the same problem, so I reverted back to 2.2. The error message
> >> is supremely unhelpful, and doesn't even show whichgitcommand is
> >> being executed. cap -d doesn't work either.
>
> >> On Jun 13, 7:52 pm, "Erik Kastner" <[EMAIL PROTECTED]> wrote:
>
> >> > I believe that this commit caused this 
> >> > behavior:http://github.com/jamis/capistrano/commit/ec9a7fa52c9f417a9a01a7e764b...
>
> >> > I'm trying to think of a workaround, but it comes down to a different
> >> > philosophy about where the knowledge of the repository should live.
> >> > It's either
> >> > old way: machine issuing cap command knows
> >> > new way: machines doing the code check out know
>
> >> > On Fri, Jun 13, 2008 at 1:44 PM, H. Wade Minter <[EMAIL PROTECTED]> 
> >> > wrote:
>
> >> > > I'm deploying a Rails app to the same server that houses thegit
> >> > > repository.  I'm trying to use this in my deploy.rb:
>
> >> > > set :scm, :git
> >> > > set :repository,  "file:///usr/local/git/carpool.git"
> >> > > set :deploy_via, :remote_cache
> >> > > set :branch, "master"
> >> > > set :repository_cache, "git_cache"
> >> > > set :use_sudo, false
>
> >> > > In Capistrano 2.2, this works fine.  However, in 2.3 and the just-
> >> > > released 2.4, I get:
>
> >> > >  * executing `deploy:update_code'
> >> > >    updating the cached checkout on all servers
> >> > > fatal: '/usr/local/git/carpool.git': unable to chdir ornotagit
> >> > >archive
> >> > > fatal: The remote end hung up unexpectedly
> >> > > *** [deploy:update_code] rolling back
> >> > >  * executing "rm -rf /usr/local/www/carpool/releases/20080613174107;
> >> > > true"
> >> > >    servers: ["10.5.88.49"]
> >> > >    [10.5.88.49] executing command
> >> > >    command finished
> >> > > /Library/Ruby/Gems/1.8/gems/capistrano-2.4.0/lib/capistrano/recipes/
> >> > > deploy/scm/git.rb:217:in `query_revision': Unable to resolve revision
> >> > > for 'master' on repository 'file:///usr/local/git/carpool.git'.
> >> > > (RuntimeError)
> >> > >        from 
> >> > > /Library/Ruby/Gems/1.8/gems/capistrano-2.4.0/lib/capistrano/
> >> > > recipes/deploy/scm/base.rb:35:in `send'
>
> >> > > Is there a workaround or anything for this?  Or are file:// repository
> >> > > URLs no longer supported?
--~--~---------~--~----~------------~-------~--~----~
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