Re: git-p4: exception when cloning a perforce repository

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

 



On 18 Jan 2014, at 19:22, Pete Wyckoff <pw@xxxxxxxx> wrote:

> damien@xxxxxx wrote on Thu, 16 Jan 2014 17:02 +0100:
>> 
>> On 16 Jan 2014, at 15:45, Pete Wyckoff <pw@xxxxxxxx> wrote:
>> 
>>> Oh cool, that helps a lot.  P4 is just broken here, so we can get
>>> away with being a bit sloppy in git.  I'll try just pretending
>>> "empty symlinks" are not in the repo.  Hopefully you'll have a
>>> future commit in your p4 repo that brings back bn.h properly.
>> 
>> Thanks !
>> I would love to use git instead of perforce if possible :)
>> 
>>> Still not sure about how I'll test this.
>> 
>> I can test for you, no probleme with that.
> 
> Any chance you can give this a go?  I've a bigger patch in
> a longer series, but this should be the minimal fix.  If it
> works, I'll ship it to Junio.

Yeah it seems to work fine !
I’ve finally imported all 152620 changesets :)

Thanks !

(git pull from this morning + patch)


> 
> Thanks,
> 
> 		-- Pete
> 
> ----8<--------
> 
> From 8556ab04dd126184e26a380b7ed08998fd33debe Mon Sep 17 00:00:00 2001
> From: Pete Wyckoff <pw@xxxxxxxx>
> Date: Thu, 16 Jan 2014 18:34:09 -0500
> Subject: [PATCH] git p4: work around p4 bug that causes empty symlinks
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Damien Gérard highlights an interesting problem.  Some p4
> repositories end up with symlinks that have an empty target.  It
> is not possible to create this with current p4, but they do
> indeed exist.
> 
> The effect in git p4 is that "p4 print" on the symlink returns an
> empty string, confusing the curret symlink-handling code.
> 
> In p4, syncing to a change that includes such a bogus symlink
> creates errors:
> 
>    //depot/empty-symlink - updating /home/me/p4/empty-symlink
>    rename: /home/me/p4/empty-symlink: No such file or directory
> 
> and leaves no symlink.
> 
> Replicate the p4 behavior by ignoring these bogus symlinks.  If
> they are fixed in later revisions, the symlink will be replaced
> properly.
> 
> Reported-by: Damien Gérard <damien@xxxxxx>
> Signed-off-by: Pete Wyckoff <pw@xxxxxxxx>
> ---
> git-p4.py | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/git-p4.py b/git-p4.py
> index 5ea8bb8..e798ecf 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -2075,7 +2075,14 @@ class P4Sync(Command, P4UserMap):
>             # p4 print on a symlink sometimes contains "target\n";
>             # if it does, remove the newline
>             data = ''.join(contents)
> -            if data[-1] == '\n':
> +            if not data:
> +                # Some version of p4 allowed creating a symlink that pointed
> +                # to nothing.  This causes p4 errors when checking out such
> +                # a change, and errors here too.  Work around it by ignoring
> +                # the bad symlink; hopefully a future change fixes it.
> +                print "\nIgnoring empty symlink in %s" % file['depotFile']
> +                return
> +            elif data[-1] == '\n':
>                 contents = [data[:-1]]
>             else:
>                 contents = [data]
> -- 
> 1.8.5.2.320.g99957e5
> 
> 

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