From: Thandesha VK <thanvk@gmail.com>
To: Luke Diamand <luke@diamand.org>
Cc: "Mazo, Andrey" <amazo@checkvideo.com>,
"git@vger.kernel.org" <git@vger.kernel.org>,
"gvanburgh@bloomberg.net" <gvanburgh@bloomberg.net>,
"larsxschneider@gmail.com" <larsxschneider@gmail.com>,
"miguel.torroja@gmail.com" <miguel.torroja@gmail.com>
Subject: Re: [BUG] git p4 clone fails when p4 sizes does not return 'fileSize' key
Date: Wed, 18 Apr 2018 07:59:13 -0700 [thread overview]
Message-ID: <CAJJpmi8rxJ506HaxWFYmeJ8g2Z+Lvyuei0i6O1pv1fQ7_wC8Rg@mail.gmail.com> (raw)
In-Reply-To: <CAE5ih79Psc_dVOW54nszxFb+ma4k2bxnnUXJGiCx_qfSrwQitQ@mail.gmail.com>
Just to be clear - git-p4 does not use the p4 "sizes" command anywhere AFAIK.
We are just talking about the output from "p4 print" and the
"fileSize" key, right?
--> Correct.
Does that happen with the 17.2 version of p4?
-->Correct.
print() probably makes more sense; can we try to use the function form
so that we don't deliberately make the path to python3 harder (albeit
in a very tiny way)
-->Sure.
If your server isn't reporting "fileSize" then there are a few other
places where I would expect git-p4 to also fail.
-->Most of other places are already doing key check in the hash. Looks
like this line was missed out.
On Wed, Apr 18, 2018 at 4:08 AM, Luke Diamand <luke@diamand.org> wrote:
> On 17 April 2018 at 20:12, Thandesha VK <thanvk@gmail.com> wrote:
>> I have few cases where even p4 -G sizes (or p4 sizes) is not returning
>> the size value even with latest version of p4 (17.2). In that case, we
>> have to regenerate the digest for file save it - It mean something is
>> wrong with the file in perforce.
>
> Just to be clear - git-p4 does not use the p4 "sizes" command anywhere AFAIK.
>
> We are just talking about the output from "p4 print" and the
> "fileSize" key, right?
>
> Does that happen with the 17.2 version of p4?
>
>> Regarding, sys.stdout.write v/s print, I see script using both of them
>> without a common pattern. I can change it to whatever is more
>> appropriate.
>
> print() probably makes more sense; can we try to use the function form
> so that we don't deliberately make the path to python3 harder (albeit
> in a very tiny way).
>
>>
>> On Tue, Apr 17, 2018 at 11:47 AM, Mazo, Andrey <amazo@checkvideo.com> wrote:
>>> Does a missing "fileSize" actually mean that there is something wrong with the file?
>>> Because, for me, `p4 -G print` doesn't print "fileSize" for _any_ file.
>>> (which I attribute to our rather ancient (2007.2) Perforce server)
>>> I'm not an expert in Perforce, so don't know for sure.
>
> My 2015 version of p4d reports a fileSize.
>
>>>
>>> However, `p4 -G sizes` works fine even with our p4 server.
>>> Should we then go one step further and use `p4 -G sizes` to obtain the "fileSize" when it's not returned by `p4 -G print`?
>>> Or is it an overkill for a simple verbose print out?
>
> If your server isn't reporting "fileSize" then there are a few other
> places where I would expect git-p4 to also fail.
>
> If we're going to support this very ancient version of p4d, then
> gracefully handling a missing fileSize will be useful.
>
>>>
>>> Also, please, find one comment inline below.
>>>
>>> Thank you,
>>> Andrey
>>>
>>> From: Thandesha VK <thanvk@gmail.com>
>>>> Sounds good. How about an enhanced version of fix from both of us.
>>>> This will let us know that something is not right with the file but
>>>> will not bark
>>>>
>>>> $ git diff
>>>> diff --git a/git-p4.py b/git-p4.py
>>>> index 7bb9cadc6..df901976f 100755
>>>> --- a/git-p4.py
>>>> +++ b/git-p4.py
>>>> @@ -2566,7 +2566,12 @@ class P4Sync(Command, P4UserMap):
>>>> relPath = self.stripRepoPath(file['depotFile'], self.branchPrefixes)
>>>> relPath = self.encodeWithUTF8(relPath)
>>>> if verbose:
>>>> - size = int(self.stream_file['fileSize'])
>>>> + if 'fileSize' not in self.stream_file:
>>>> + print "WARN: File size from perforce unknown. Please verify by p4 sizes %s" %(file['depotFile'])
>>> For whatever reason, the code below uses sys.stdout.write() instead of print().
>>> Should it be used here for consistency as well?
>>>
>>>> + size = "-1"
>>>> + else:
>>>> + size = self.stream_file['fileSize']
>>>> + size = int(size)
>>>> sys.stdout.write('\r%s --> %s (%i MB)\n' %
>>>> (file['depotFile'], relPath, size/1024/1024))
>>>> sys.stdout.flush()
>>>>
>>>>
>>>> On Tue, Apr 17, 2018 at 10:33 AM, Mazo, Andrey <amazo@checkvideo.com> wrote:
>>>>> Sure, I totally agree.
>>>>> Sorry, I just wasn't clear enough in my previous email.
>>>>> I meant that your patch suppresses "%s --> %s (%i MB)" line in case "fileSize" is not available,
>>>>> while my patch suppresses just "(%i MB)" portion if the "fileSize" is not known.
>>>>> In other words,
>>>>> * if "fileSize" is known:
>>>>> ** both yours and mine patches don't change existing behavior;
>>>>> * if "fileSize" is not known:
>>>>> ** your patch makes streamOneP4File() not print anything;
>>>>> ** my patch makes streamOneP4File() print "%s --> %s".
>>>>>
>>>>> Hope, I'm clearer this time.
>>>>>
>>>>> Thank you,
>>>>> Andrey
>>>>>
>>>>> From: Thandesha VK <thanvk@gmail.com>
>>>>>> *I* think keeping the filesize info is better with --verbose option as
>>>>>> that gives some clue about the file we are working on. What do you
>>>>>> think?
>>>>>> Script has similar checks of key existence at other places where it is
>>>>>> looking for fileSize.
>>>>>>
>>>>>> On Tue, Apr 17, 2018 at 9:22 AM, Andrey Mazo <amazo@checkvideo.com> wrote:
>>>>>>> Huh, I actually have a slightly different fix for the same issue.
>>>>>>> It doesn't suppress the corresponding verbose output completely, but just removes the size information from it.
>>>>>>>
>>>>>>> Also, I'd mention that the workaround is trivial -- simply omit the "--verbose" option.
>>>>>>>
>>>>>>> Andrey Mazo (1):
>>>>>>> git-p4: fix `sync --verbose` traceback due to 'fileSize'
>>>>>>>
>>>>>>> git-p4.py | 8 ++++++--
>>>>>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>>>>>>
>
> Thanks
> Luke
--
Thanks & Regards
Thandesha VK | Cellphone +1 (703) 459-5386
prev parent reply other threads:[~2018-04-18 14:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-16 23:35 [BUG] git p4 clone fails when p4 sizes does not return 'fileSize' key Thandesha VK
2018-04-17 16:00 ` Mazo, Andrey
2018-04-17 16:22 ` Andrey Mazo
2018-04-17 16:22 ` [PATCH 1/1] git-p4: fix `sync --verbose` traceback due to 'fileSize' Andrey Mazo
[not found] ` <CAE5ih7-iQsBxM3Gn4B1Q9WZ2A0=eTHn9nt3a0LVURppOCQsAWA@mail.gmail.com>
2018-04-17 21:18 ` Mazo, Andrey
2018-04-17 21:24 ` Thandesha VK
2018-04-17 21:38 ` Mazo, Andrey
2018-04-17 22:29 ` Thandesha VK
2018-04-17 17:21 ` [BUG] git p4 clone fails when p4 sizes does not return 'fileSize' key Thandesha VK
2018-04-17 17:33 ` Mazo, Andrey
2018-04-17 18:01 ` Thandesha VK
2018-04-17 18:47 ` Mazo, Andrey
2018-04-17 19:12 ` Thandesha VK
2018-04-18 11:08 ` Luke Diamand
2018-04-18 14:59 ` Thandesha VK [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJJpmi8rxJ506HaxWFYmeJ8g2Z+Lvyuei0i6O1pv1fQ7_wC8Rg@mail.gmail.com \
--to=thanvk@gmail.com \
--cc=amazo@checkvideo.com \
--cc=git@vger.kernel.org \
--cc=gvanburgh@bloomberg.net \
--cc=larsxschneider@gmail.com \
--cc=luke@diamand.org \
--cc=miguel.torroja@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).