Re: [PATCH v3] git-p4: recover from inconsistent perforce history

[Andrew Oakley <andrew@adoakley.name>]

On Sun, 10 May 2020 13:03:11 +0100
Luke Diamand <luke@diamand.org> wrote:
> Perforce changed their server to reject this kind of thing in the
> 2017.1 version:
> 
>     Bugs fixed in 2017.1
>     #1489051 (Job #2170) **
>        Submitting a file with the same name as an existing depot
>        directory path (or vice versa) will now be rejected.
> 
> (Of course people will still have damaged repos even today).
> 
> I tried your test with both the 2015.1 and the 2020.1 versions, and it
> worked in both cases - shouldn't it be impossible to get into the
> state that git-p4 now recovers from with a newer p4d?

Yes, there is an option in perforce (submit.collision.check) that stops
new changelists from introducing this problem, and it is turned on by
default.  Unfortunately this option does *exactly* what the description
says, so you can't delete a directory and replace it with a file in the
same changelist - the delete has to happen first.  It's not clear which
behaviour is least bad.

The test case tries to turn the perforce option off so it works on both
old and new server versions.

Thanks