perforce gateway

[Steve Borho]

On Tue, Dec 15, 2009 at 11:49 PM, Frank A. Kingswood
<frank at kingswood-consulting.co.uk> wrote:
> Steve Borho wrote:
>>>
>>> In which P4 context ("client spec") is this being done? The user only has
>>> a
>>> hg repository, right? And the gateway repository created by 'hg convert'
>>> is
>>> also not a P4 workarea.
>>
>> Ah, this is a good question.  I've been using a p4 conversion script
>> for a few years now that works right out of a p4 client.  It
>> incrementally checks out each p4 changelist and checks it into
>> Mercurial.  Brute-force but it works.  I have not used the p4 support
>> in the convert extension yet.
>
> Right, so you have a P4 workarea that is also at the same time a Mercurial
> repository. I find this gives a lot of trouble with read-only files.
>
>> This gateway would not work for every p4 setup, that's for sure.  I
>> thought about doing this entirely on the client side.  Instead of
>> doing the merge on the gateway box, an extension on the user machine
>> would allow you to "push" to a local p4 client.  Something like this:
>>
>> [p4push]
>> client = myclient
>> server = server:port
>>
>> [paths]
>> default = http://p4mirror/hg/repo
>> default-push = p4://path/to/p4client/
>>
>> The extension would monkey-patch 'push' and 'outgoing' and look for
>> p4:// urls, isolate the outgoing changesets, and then apply those
>> changes to the specified client as above and simply leave them there
>> for the user to commit (using whatever message they like).
>
> Yes, this is tempting. The user could still fold changes together if he uses
> MQ to do it, and could push several changesets to P4 in one go.
>
> But I think it would probably not work quite like you describe, because of
> course in P4 you can not have multiple pending changelists that affect the
> same files, so leaving all changes pending would fail. I think this may not
> be a problem in such a workflow because the user could polish (to whatever
> extent he wants) the changesets until they're good to go into P4 using MQ.
>
> IMHO the P4 URI would probably look more like
>        default-push = p4://server:1666/client-spec-name
> because everything else can be determined from the client spec.
>
> A detail that the user must not overlook in this case is that his client
> spec must match the client spec that was used to generate the hg repository
> in the first place. I suppose that hg convert could drop a .p4config file in
> the converted repository to help.
>
>> However, this doesn't record the 'push' commit in p4 as a merge of any
>> kind on the mercurial side, so the user would have dangling hg heads
>> after each push.   In the end, the gateway approach seemed cleaner.
>
> Doing it all in the client looks really clean. It solves the client-spec
> issue, for example. All that is missing is adding the Hg revision ids to the
> P4 log message, right?

While I have your attention on this thread, might I ask for an
improvement in the p4 conversion back-end?

Incremental conversions are currently unnecessarily expensive.  It's
searching the p4 revision history from the beginning, perhaps finding
a couple new revisions, then adding just those new revisions.  On a
moderately loaded server this is like 15 minutes of searching history
and 15 seconds of retrieving new changelists.

Could it start the search at the last known converted revision?

--
Steve Borho