Bitbucket integration - TortoiseHg Developers

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Bitbucket integration
Received-SPF: pass (google.com: domain of ezque...@gmail.com designates 209.85.214.179 as permitted sender) client-ip=209.85.214.179;
MIME-Version: 1.0
Sender: ezque...@gmail.com
In-Reply-To: <4FDCD765.1070...@gmail.com>
References: <2f72841e-2bfa-4003-8919-4f1ec250c6d7@googlegroups.com>
	<4FDCB657.1080...@cadifra.com>
	<CAOvn4qiv2-0uXzg9=aF25Ojpe_ONq4P8iAYUiYgn59hYJDS...@mail.gmail.com>
	<4FDCC1DA.8030...@cadifra.com>
	<4FDCD765.1070...@gmail.com>
Date: Sat, 16 Jun 2012 21:36:40 +0200
Message-ID: <CAMefLFGqWg9gGe+N4RUQsSWvTirHdS3STgS8_XW_OHTRxvW...@mail.gmail.com>
Subject: Re: [thg-dev] Bitbucket integration
From: Angel Ezquerra <angel.ezque...@gmail.com>
To: thg-dev@googlegroups.com
Cc: Adrian Buehlmann <adr...@cadifra.com>, Thomas Kluyver <tak...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 16, 2012 at 8:58 PM, Eduard-Cristian Stefan
<alexandrul...@gmail.com> wrote:
> 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,
> =A0Eduard

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
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
