Hmm. You shouldn't need capistrano on any server but the one you are
deploying from. I'm not sure installing it on the remote server(s)
would have any effect at all...
- Jamis
On May 7, 2008, at 7:32 PM, BenHill wrote:
>
> Hi, Folks.
>
> Actually, chalk this up to my own stupidity. I hadn't upgraded
> capistrano on the production server. I did that and everything is
> working for me.
>
> Ben
>
> On May 6, 7:29 am, zmalltalker <[EMAIL PROTECTED]> wrote:
>> The small patch
>>
>> execute << "#{git} fetch #{remote} && #{git} fetch --tags
>> #{remote} && #{git} reset --hard #{revision}"
>>
>> worked like a charm for me, +1.
>>
>> Marius
>>
>> On May 6, 3:36 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
>> wrote:
>>
>>> I added a note to ticket, waiting for reply from Alex
>>
>>> On Tue, May 6, 2008 at 3:22 PM, Patrick Lenz <[EMAIL PROTECTED]
>>> overload.de>
>>> wrote:
>>
>>>> Hi Jamis,
>>
>>>> basically you'd just need to reverse the patch in ticket #6,
>>>> should I
>>>> just reopen that one and attach a note?
>>
>>>> Best,
>>>> Patrick
>>
>>>> On May 6, 2008, at 3:09 PM, Jamis Buck wrote:
>>
>>>>> Fair enough. I'm still new to git (and haven't needed to use git
>>>>> with
>>>>> capistrano yet), so I'll rely on the experience of those who do in
>>>>> this case. I'm traveling to Chicago today, returning Saturday,
>>>>> so my
>>>>> time will be pretty thin. Is there anyone that would be able to
>>>>> put a
>>>>> ticket for this up on lighthouse and possibly providing a patch?
>>
>>>>> - Jamis
>>
>>>>> On May 6, 2008, at 5:58 AM, Mislav Marohnić wrote:
>>
>>>>>> Indeed, "git push --tags" pushes only tags, so "git fetch --tags"
>>>>>> may fetch only tags. This hasn't occurred to me.
>>
>>>>>> The --tags option isn't needed because Capistrano uses SHA1 IDs
>>>>>> exclusively on remote. It gets the ID from a local tag/branch
>>>>>> name.
>>
>>>>>> So, +1 for removing --tags.
>>
>>>>>> 2008/5/6 Patrick Lenz <[EMAIL PROTECTED]>:
>>
>>>>>> After a bit of investigation I think this is indeed the cause.
>>>>>> The
>>>>>> manpage for git-fetch[1] is a little ambiguous about this, but I
>>>>>> think
>>>>>> it really does say that with the --tags option it will only fetch
>>>>>> tags
>>>>>> whereas without that option it will fetch tags and regular
>>>>>> revisions.
>>
>>>>>> This change[2] went in as a patch provided by Alex Arnell on
>>>>>> Lighthouse, so he might want to speak up regarding his case where
>>>>>> tags
>>>>>> were unavailable with the regular fetch mode. According to the
>>>>>> manpage
>>>>>> git would not download tags that don't point to any branch heads
>>>>>> being
>>>>>> tracked, so this might as well be a local configuration issue or
>>>>>> issue
>>>>>> with the Git version he used (and I don't know which).
>>
>>>>>> If that's not the case, git.rb line 187 could be changed to:
>>
>>>>>> execute << "#{git} fetch #{remote} && #{git} fetch --
>>>>>> tags
>>>>>> #{remote} && #{git} reset --hard #{revision}"
>>
>>>>>> to be on the safe side by fetching both revisions and tags
>>>>>> explicitly.
>>>>>> That does feel a little hard on the performance side though, so
>>>>>> it's
>>>>>> worth investigating whether or not the --tags part is really
>>>>>> necessary
>>>>>> for the general public.
>>
>>>>>> Best,
>>>>>> Patrick
>>
>>>>>> [1]http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html
>>>>>> [2]
>>>> http://github.com/jamis/capistrano/commit/838f6abd74b4d4244111a698ab8
>>>> ...
>>>>>> [3]
>>>> http://capistrano.lighthouseapp.com/projects/8716/tickets/6-git-modul
>>>> ...
>>
>>>>>> On May 6, 10:07 am, Patrick Lenz <[EMAIL PROTECTED]>
>>>>>> wrote:
>>>>>>> Actually I think this is related to git fetch --tags being
>>>>>>> used now
>>>>>>> which apparently *only* fetches tags as opposed to fetching all
>>>>>> commit
>>>>>>> objects in addition to tags when a successive deploy is made.
>>
>>>>>>> Here's what's happening on my server:
>>
>>>>>>> if [ -d /APPROOT/shared/cached-copy ]; then
>>>>>>> cd APPROOT/shared/cached-copy &&
>>>>>>> git fetch --tags origin &&
>>>>>>> git reset --hard 4777556990b3b6ce51a0452234886bda9dff8e00;
>>>>>>> else
>>>>>>> git clone GITREPO APPROOT/shared/cached-copy &&
>>>>>>> cd APPROOT/shared/cached-copy &&
>>>>>>> git checkout -b deploy
>>>>>> 4777556990b3b6ce51a0452234886bda9dff8e00;
>>>>>>> fi
>>
>>>>>>> So what's happening is that on a successive deploy git reset
>>>>>>> doesn't
>>>>>>> have access to the newer revision present at the origin
>>>>>>> repository
>>>>>> as
>>>>>>> git fetch fails to retrieve these new revisions when invoked
>>>>>>> with
>>>>>> the
>>>>>>> --tags option. Dropping that option (or manually executing that
>>>>>>> command on the server) works fine. I'm sure this went in for a
>>>>>> reason
>>>>>>> so it'd be pointless to now drop it completely.
>>
>>>>>>> Jamis?
>>
>>>>>>> On May 5, 8:16 pm, "Mislav Marohnić"
>>>>>>> <[EMAIL PROTECTED]>
>>>>>>> wrote:
>>
>>>>>>>> Can you observe the output and find the git command that
>>>>>> triggered this
>>>>>>>> error?
>>
>>>>>>>> There is probably a problem with query_revision, but the error
>>>>>> itself didn't
>>>>>>>> come from Capistrano.
>>
>>>>>>>> On Mon, May 5, 2008 at 1:33 AM, BenHill <[EMAIL PROTECTED]>
>>>>>>>> wrote:
>>
>>>>>>>>> After deploying 2.3, I suddenly get this error when deploying:
>>
>>>>>>>>> "Needed a single revision"
>>
>>>>>>>>> ..the problem goes away when I roll back to 2.2.
> >
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
