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

From: Andrew Oakley <andrew@adoakley.name>
Date: May 10, 2020, 14:13 UTC
Message-ID: <20200510151354.16ce2ab1@ado-tr.home.arpa>
In-Reply-To: <CAE5ih793qKyOSE-hkOw7+nFmM3XTRxxrXv0FD2+WWXjGbVHkoQ@mail.gmail.com>

On Sun, 10 May 2020 13:03:11 +0100 Luke Diamand <luke@diamand.org> wrote:

Show 13 quoted lines

> 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