Perforce server 2007.2 (and maybe others) doesn't return "fileSize"
attribute in its reply to `p4 -G print` command.
This causes the following traceback when running `git p4 sync --verbose`:
"""
Traceback (most recent call last):
File "/usr/libexec/git-core/git-p4", line 3839, in
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]
https://public-inbox.o
My fix is for the case where p4 -G sizes not returning the key and
value for fileSize. This can happen in some cases. Only option at that
point of time is to warn the user about the problematic file and keep
moving (or should we abort??)
Thanks
Thandesha
On Tue, Apr 17, 2018 at 2:18 PM, Mazo, And
Thandesha,
If I read your patch correctly, it adds a warning in case `p4 -G print` doesn't
return "fileSize" (not `p4 sizes`).
I don't see `p4 sizes` being used by git-p4 at all.
As I said earlier, for our ancient Perforce server, `p4 -G print` _never_
returns "fileSize".
So, it's definitely not
Ah. I didn't realize the script is not using p4 sizes to get the size.
I assumed that it is using p4 sizes. Now I am looking at it using p4
-G print.
However, when the stack trace happened, I verified what is wrong and
found out that the fileSize key is not returned for "p4 -G sizes"
command.
So
5 matches
Mail list logo
