Perfarce extension for 1.6

[Frank A. Kingswood]

Matt Mackall wrote:
> I think most of that still applies. In particular:
> 
> - there's an implicit promise that we'll support it [1]
> - we've got about one Perforce expert
> - it opens the door to the other two bridge extensions

Okay, let me explain my motivation and answer some of your questions.

Currently there are about a hundred users that pull from my repository, 
and added to that an unknown number of users that use the version 
included with tortoisehg. This is not a huge number of users, but 
clearly there is a demand for perfarce.

With Mercurial core being developed I'm having to test and mark as 
compatible perfarce versions vs Mercurial versions. As Mercurial 
development continues I'll have to decide whether to support older 
versions (to help users on a particular Red Hat release) or drop them, 
or something. This is creating work for me, although perhaps not much.

Development of perfarce itself has stabilized, as it is now 
feature-complete and not many bugs are being found.

> The convert extension gets a disproportionate number of bugs filed
> against it, many of which are well outside the expertise of most of us
> because they're really about other systems. These bridge tools are each
> more ambitious than what convert's trying to do so I can only expect
> that the bugs will be hairier and the core developers more powerless to
> address them.

I was hoping to eventually subsume the functionality of the convert p4 
source with perfarce - one benefit is that it does not require a 
two-pass operation, but just processes one revision after another. This 
makes the perfarce pull operation less brittle. There's also much better 
tracing in perfarce, so if something does go wrong it is easier to spot.

Frank
-- 
------------------------------------------------------------------------
Frank A. Kingswood                      frank at kingswood-consulting.co.uk
Cambridge, United Kingdom                               +44-7545-209 100