Perfarce extension for 1.6

[Augie Fackler]

On Wed, Jun 16, 2010 at 1:17 PM, Frank A. Kingswood
<frank at kingswood-consulting.co.uk> wrote:
> 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.

Using my *highly* unscientific method of searching "$tool
site:twitter.com" as a rough popularity metric, hg-git and
hgsubversion are orders of magnitude more popular than perfarce
(though hg-git wins more because Google search treats dashes as
spaces.) I'm also not convinced raw popularity is a reason for things
being in core - after all, TortoiseHG is more popular than any of
these extensions, is more heavily coupled to the core of hg, but is an
external project.

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

It's really not that much work. tip of hgsubversion works flawlessly
with all versions of hg back to 1.3, and it's not all that hard. I've
also got a buildbot set up to run the tests against each version of hg
every time a new version of hgsubversion is pushed, and against tip of
hg anytime hg is pushed.

The reality (I suspect, anyway) is that you're still likely to be
close to the only one testing perfarce, so if it breaks regularly now
that's not terribly likely to change - I know I don't keep VCSes I
don't actively bridge into installed. There's just no point. So if I
break (say) convert's Bazaar support, I'll never know - someone else
will have to find the breakage. Perforce as a proprietary system
strikes me as being even less likely to be installed and therefore a
testable configuration.

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

These latter two arguments hold true for hgsubversion, but you've also
missed mpm's point (as I understood it): you're proposing including a
more complex tool than the component in hg that already gets the most
bug reports *and* that we're the least well-equipped to fix ourselves.

I honestly feel that the general complexity of the bridging extensions
makes them ideal candidates for figuring out how to properly handle
out-of-tree versioning of extensions. I'd like to think that
hgsubversion does a pretty decent job of supporting old releases, and
since it's not been that hard for either hgsubversion or hg-git, I
don't buy the premise that it's an onerous burden.

>
> Frank
> --
> ------------------------------------------------------------------------
> Frank A. Kingswood                      frank at kingswood-consulting.co.uk
> Cambridge, United Kingdom                               +44-7545-209 100
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>