git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Thandesha VK <thanvk@gmail.com>
To: "Mazo, Andrey" <amazo@checkvideo.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
	"luke@diamand.org" <luke@diamand.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: Tue, 17 Apr 2018 12:12:45 -0700	[thread overview]
Message-ID: <CAJJpmi-Uq8vfSOYaH+quMA87=P=66+JMGGvuLByAKQUy-fpDxg@mail.gmail.com> (raw)
In-Reply-To: <BYAPR08MB3845A66624486DD1D534050EDAB70@BYAPR08MB3845.namprd08.prod.outlook.com>

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.
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.

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.
>
> 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?
>
> 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(-)
>>>>>
>>>>>
>>>>> base-commit: 468165c1d8a442994a825f3684528361727cd8c0
>>>>> --
>>>>> 2.16.1
>>>>>
>>>>
>>>> --
>>>> Thanks & Regards
>>>> Thandesha VK | Cellphone +1 (703) 459-5386
>>
>>
>>
>> --
>> Thanks & Regards
>> Thandesha VK | Cellphone +1 (703) 459-5386



-- 
Thanks & Regards
Thandesha VK | Cellphone +1 (703) 459-5386

  reply	other threads:[~2018-04-17 19:13 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 [this message]
2018-04-18 11:08             ` Luke Diamand
2018-04-18 14:59               ` Thandesha VK

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='CAJJpmi-Uq8vfSOYaH+quMA87=P=66+JMGGvuLByAKQUy-fpDxg@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).