>> This was actually discussed in a separate thread [1] some time ago with
>> patches proposed by Thandesha and me.
>> I haven't yet got time to cook a final patch, which addresses both
>> Thandesha's and mine use-cases though,
>> so this wasn't submitted to Junio yet.
>> In the meantime, I
> The last one (i.e. "even if it is verbose, if fileSize is not
> reported, do not write the verbose output") does not look like it is
> limited to the unshelve feature, so it might, even though it is a
> one-liner, deserve to be a separate preparatory patch if you want.
> But I do not feel
about the problematic file and keep
> moving (or should we abort??)
>
> Thanks
> Thandesha
>
> On Tue, Apr 17, 2018 at 2:18 PM, Mazo, Andrey <am...@checkvideo.com> wrote:
>> Luke,
>>
>> Thank you for reviewing and acking my patch!
>> By the way, did y
Luke,
Thank you for reviewing and acking my patch!
By the way, did you see Thandesha's proposed patch [1] to print a warning in
case of the missing "fileSize" attribute?
Should we go that route instead?
Or should we try harder to get the size by running `p4 -G sizes`?
[1]
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' %
>
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
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.
I'll (try to) post it as a reply to this email.
Also, I'd mention that the workaround is trivial -- simply omit the
7 matches
Mail list logo
