Implementing convert setrevmap (for p4.py)

[Frank Kingswood]

Patrick Mézard wrote:
>> Tom pointed out that convert/p4.py does not implement setrevmap and 
>> therefore is not easily used incrementally.
>>     
> Sources do not need to implement setrevmap() to work incrementally. The revision map is automatically filled with the revisions returned by the source during graph discovery. 
For p4.py the perforce repository is scanned during the constructor of 
the class. I guess this can be delayed until later if that is required. 
Scanning the p4 source is extremely slow (despite the company calling it 
"the fast SCM", what a joke), so it would be good to avoid scanning the 
revisions without needing to specify a starting revision.
> It is serialized so the revision graph could be updated incrementally. Two sources do additional work with the revision map:
> - filemap rebuilds some state to avoid rediscovering the converted subgraph details every time
> - subversion uses it to support shallow conversions (from a starting revisions)
>
> So, if the p4 source has issues with incremental conversion, the cause is likely elsewhere. Perhaps the stored identifiers are not stable?
>   
Stored identifiers such as what? You mean the data returned from getchanges?

In Perforce changes are numbered and these are notionally unchangeable. 
But they really aren't as it is possible to delete files from the 
repository ("obliterate from the depot") which will modify the changes 
these files are involved in.

Frank

-- 
------------------------------------------------------------------------
Frank A. Kingswood                      frank at kingswood-consulting.co.uk
Cambridge, United Kingdom                               +44-870-095 0000