Bitbucket integration

[Thomas Kluyver]

Hi all,

I'd be interested to see TortoiseHg have some interface with Bitbucket, as it's probably the most popular mercurial host. I'm willing to spend some time working on this.

Some use cases:
- I have a repository on BB that I want to get a local copy of. Rather than fiddling with copying/pasting URLs, I could select it by name in the GUI and click clone.
- I start a project locally and want to put it on BB. Rather than switching to the website to create a repository, I can create & push in one step from TortoiseHg.
- I find a bug in a project hosted on Bitbucket. When I clone it, I can select a checkbox that will also fork it on BB* and add my fork to the remote paths. When I'm done, it lets me create a pull request*.

* The Bitbucket API doesn't seem to support these steps yet, but I'm sure if we pestered them, they'd look at it.

So I'd like to ask:
- Does this sound like a reasonable feature for TortoiseHg?
- Has anyone already done anything relevant?
- What kind of UI would you like to see for this? Should it be integrated into the relevant dialogs, or in a separate view?

Thanks,
Thomas

[Adrian Buehlmann]

I'm not really a fan of integrating with one particular hosting service
that closely. Bitbucket may be an important player, but it's not the
only one.

[Thomas Kluyver]

On 16 June 2012 17:37, Adrian Buehlmann <adr...@cadifra.com> wrote:
> I'm not really a fan of integrating with one particular hosting service
> that closely. Bitbucket may be an important player, but it's not the
> only one.

I'm not suggesting removing any ability to communicate with other
hosts, and I'm all in favour of adding similar features for competing
services. But having some integration with mercurial hosting would
make TortoiseHg a more useful tool. Bitbucket is a sensible place to
start, because of its popularity and simple API.

Thomas

[Adrian Buehlmann]

Adding similar features for the other competitors is serious wormbox I'd
prefer not to open.

TortoiseHg should stay a generically useful tool and not to be infected
with any specifics of one or a few popular hosting services.

TortoiseHg and Bitbucket should largely stay ignorant of each other. The
only common ground is mercurial.

[Thomas Kluyver]

On 16 June 2012 18:26, Adrian Buehlmann <adr...@cadifra.com> wrote:
> TortoiseHg should stay a generically useful tool and not to be infected
> with any specifics of one or a few popular hosting services.

'Infecting' TortoiseHg is absolutely not what I have in mind. Again, I
don't want to make it any less useful as a general tool for managing
mercurial repositories. But I imagine a lot of users are working with
repositories on Bitbucket, and I'd like it to be a better tool for
them.

I appreciate the principle, but I think useful features should be
given a higher priority. It seems silly to force users to keep an
awkward workflow because developers want some kind of neutrality.

If you're not willing to have this in the core, does TortoiseHg have
any kind of extension system where integration could be implemented?

Thomas

[Adrian Buehlmann]

On 2012-06-16 20:02, Thomas Kluyver wrote:
> On 16 June 2012 18:26, Adrian Buehlmann <adr...@cadifra.com> wrote:
>> TortoiseHg should stay a generically useful tool and not to be infected
>> with any specifics of one or a few popular hosting services.
>
> 'Infecting' TortoiseHg is absolutely not what I have in mind. Again, I
> don't want to make it any less useful as a general tool for managing
> mercurial repositories. But I imagine a lot of users are working with
> repositories on Bitbucket, and I'd like it to be a better tool for
> them.

Perhaps your infection is well intended. But the net result is that we
would have features specific for service X, where X would be any of the
open ended list, currently containing: Bitbucket, CodePlex, Kiln, Google
Code, whatever?

> I appreciate the principle, but I think useful features should be
> given a higher priority. It seems silly to force users to keep an
> awkward workflow because developers want some kind of neutrality.

Then make the workflow less awkward on a generic basis. TortoiseHg
shouldn't need to know that Bitbucket needs to be treated like this and
CodePlex needs to be treated differently. If those hosting providers can
agree to establish some generic, hoster-inependent API, then this would
perhaps be a different matter. But I don't see how this would possibly
happen.

> If you're not willing to have this in the core, does TortoiseHg have
> any kind of extension system where integration could be implemented?

Not that I know of.

Please also note that I'm not the one who has the final saying here.
Project lead is Steve. Actually, I haven't been that active on
TortoiseHg for quite a while now.

So this is just my opinion. But I'd rather not go the route of making
TortoiseHg just another GUI for Bitbucket or CodePlex or whatnot.

[Eduard-Cristian Stefan]

On 2012-06-16 20:26, Adrian Buehlmann wrote:
> Adding similar features for the other competitors is serious wormbox I'd
> prefer not to open.
>
> TortoiseHg should stay a generically useful tool and not to be infected
> with any specifics of one or a few popular hosting services.
>
> TortoiseHg and Bitbucket should largely stay ignorant of each other. The
> only common ground is mercurial.

PyCharm, for example, uses a plugin to integrate with Bitbucket,
while the Github integration is built-in.
Maybe some kind of plugin for TortoiseHg would be enough.

OTOH, lately a lot of projects are choosing Github
simply for their facilities (so they are choosing git).
IMHO, a bit of extra support for Bitbucket would give mercurial
a better chance. Again, nothing official, but please don't reject
integration proposals.

Have a nice day,
Eduard

[Angel Ezquerra]

I think that Adrian has a good point and is right to be concerned that
we should not customize TortoiseHg too much for a single repository
host. However I think that we may be able to integrate some _optional_
functionality which could perhaps make it easier to work with certain
hosts, while keeping the main workflow unchanged.

I think mercurial does a good job in giving users the tools to extend
its functionality via extensions. I wonder, would it be possible to
create a _mercurial_ extension that would make working with mercurial
repos simpler, even if you were not using TortoiseHg? For example you
could add a command to get a list of your repos, of your forks, to
send pull requests, etc.

If such an extension were created, maybe then the boundaries between
the extension and the regular mercurial and TortoiseHg functionality
would be clearer. That could reduce the chance of "infecting" the rest
of the TortoiseHg code as Adrian put it. It would then be easier to
make the case of integrating some support for this mercurial extension
into TortoiseHg, just as we have done for other extensions (e.g. mq,
pbranch, projrc)?

In addition, I think it would be nice to have some generic means of
extending TortoiseHg. We would have to think hard about what that
would mean though.

Angel

[Yuya Nishihara]

Mercurial's extension mechanism should also work for TortoiseHg.

https://bitbucket.org/yuja/hgext-workarounds/src/19463993ab0e/hgext/thgseparatetasktabs.py

But note that internal functions of TortoiseHg is much unstable than
Mercurial's. Also, extending object by "class Foo(bar.__class__)" hack may
not work for QObject in some cases.

I think it's okay to provide a generic hook point for this sort of
integration if any.

Just FYI, there is an extension for bitbucket:
https://bitbucket.org/birkenfeld/hgbb/

Regards,

[Steve Borho]

The Bitbucket folks asked me about features like this some time ago.
In my view, we should support our hosting services ecosystem as well
as possible, even to the point of adding a new top level Workbench
menu named "Hosting".

Each hosting site can do as much or as little as they like.

--
Steve Borho