Re: [PATCH v2 7/8] git-p4: decode p4 wildcard characters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 24, 2011 at 1:12 PM, Pete Wyckoff <pw@xxxxxxxx> wrote:
> gitster@xxxxxxxxx wrote on Mon, 21 Feb 2011 15:32 -0800:
>> Pete Wyckoff <pw@xxxxxxxx> writes:
>>
>> > There are four wildcard characters in p4. ÂFiles with these
>> > characters can be added to p4 repos using the "-f" option.
>> > They are stored in %xx notation, and when checked out, p4
>> > converts them back to normal.
>> >
>> > This patch does the same thing when importing into git,
>> > converting the four special characters. ÂWithout this change,
>> > the files appear with literal %xx in their names.
>> >
>> > Be careful not to produce "*" in filenames on windows. ÂThat
>> > will fail.
>>
>> > + Â Â# P4 wildcards are not allowed in filenames. ÂP4 complains
>> > + Â Â# if you simply add them, but you can force it with "-f", in
>> > + Â Â# which case it translates them into %xx encoding internally.
>> > + Â Â# Search for and fix just these four characters. ÂDo % last so
>> > + Â Â# that fixing it does not inadvertently create new %-escapes.
>> > + Â Â#
>> > + Â Âdef wildcard_decode(self, path):
>> > + Â Â Â Â# Cannot have * in a filename in windows; untested as to
>> > + Â Â Â Â# what p4 would do in such a case.
>> > + Â Â Â Âif not self.isWindows:
>> > + Â Â Â Â Â Âpath = path.replace("%2A", "*")
>>
>> I'll queue the patch as-is, but perhaps we can ask for help from people
>> who have access to P4 on both non-Windows and Windows to run a small test
>> to determine what happens in the native client?
>>
>> Â1. On a non-Windows client, add a path with '*' in it to the depot;
>> Â Â perhaps "p4 add" might fail at this point, in which case we don't
>> Â Â need to worry about this issue at all.
>>
>> Â2. Create a p4 client on Windows against that depot, and sync it; unless
>> Â Â the previous step failed, we will see what happens (I would imagine it
>> Â Â either dies or mangles the pathname and warns), so that we have
>> Â Â something to emulate.
>>
>> and then the quoted part can be further refined in a separate patch later.
>
> I tried this myself in a VM when Tor Arvid pointed out the
> problem with Windows:
>
> http://article.gmane.org/gmane.comp.version-control.git/166374
>
> 1. Â"*" is acceptable in filenames, but users must use "p4 add -f"
> Â Âto indicate that they really want that wildcard character in
> Â Âthe filename.
>
> 2. ÂWindows clients fail to create the file in "p4 sync". ÂThe
> Â Âerror is:
>
> Â Âopen for write: c:\Documents and Settings\Administrator\Desktop\file*star:
> Â ÂThe filename, directory name, or volume label syntax is incorrect.
>
> The behavior for git-p4 I chose is to sync the file but leave
> the name with its encoded %2A. ÂIf we think it is better to
> duplicate p4's failure, we can simply try to create the file
> and let the OS produce the same error message.

Yeah, I was thinking... what happens now if we do:

1) Create "my*file" in linux, and submit.
2) git-p4 sync from windows, and get my%2Afile on windows.
3) modify my%2Afile and do git commit.
4) git-p4 submit

I haven't had time to test right now, but maybe p4 will not recognise
my%2Afile (or try to check it in as my%252Afile (replacing the '%'
character) or something like that? (Or maybe I just haven't had enough
coffee today :-/ )

    -- Tor Arvid
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]