> I see what happened: my revspec couldn't cope with the fact that you
> branched fix5845 off rlcompleter-config.
Ah, I hadn’t thought of that. (I had to branch because of the former
issue with the hyphen; this is a pathological case.)
> In any case, I have now changed the revspec to use Baptiste
> I mean that my linked repo didn’t have all changesets from
> hg.python.org/cpython. I don’t think it should matter, but I don’t know
> why the diff was empty, so I thought this information might help.
[...]
> See http://bugs.python.org/file21398/c43e264256e4.diff : this
> corresponds to a merge
> Make sure to submit issues to the meta tracker, please.
Right, I’ll do that. Since you have questions in this message, for now
I’ll continue here.
>> - The first patch was empty (note that the repo was not up to date).
> This I don't understand. What repo was not up to date?
I mean that my li
> Work has been started on that, thanks! Roundup should soon support the
> workflow described in the devguide for feature work, which will be awesome.
Make sure to submit issues to the meta tracker, please.
> I’ve tried to use a clone with a named branch for
> http://bugs.python.org/issue5845 an
Le 22/03/2011 22:47, Nick Coghlan a écrit :
> On Tue, Mar 22, 2011 at 10:53 PM, Éric Araujo wrote:
>> You have to use one public repo per bug, as roundup will only use the
>> default branch to compute the diff. Maybe adding support for named
>> branches so that you can have one repo used for many
On Wed, Mar 23, 2011 at 8:53 PM, wrote:
>
> Nick> Now, consider my own current hg setup ...
>
> This is the first soup-to-nuts description of an individual setup I've seen.
> Is it documented somewhere? If not, could you maybe add it as a complete
> example to the developer's guide? I have t
Martin> Yes, it will turn into a giant bowl of spaghetti - that's the
Martin> whole point of "Distributed" version control systems.
skip> No, you don't understand. Just the repositories I will have to
skip> deal with will turn into a big bowl of spaghetti. I could care
skip>
Nick> Now, consider my own current hg setup ...
This is the first soup-to-nuts description of an individual setup I've seen.
Is it documented somewhere? If not, could you maybe add it as a complete
example to the developer's guide? I have the local setup similar to what
you describe, but ha
Senthil> You will have to 'push' your changes to those so that they are
Senthil> publicly visible and then point that url in the bug-tracker.
>>
>> I can see this turning into a giant bowl of spaghetti. How in the
>> world are people supposed to understand how all these repos
Am 23.03.2011 03:47, schrieb Terry Reedy:
> On 3/22/2011 9:51 PM, "Martin v. Löwis" wrote:
>>> Pressing that button seems to create a duplicate patch, which is not
>>> good. Given that there is no connection between the repository names
>>> (which seem to be duplicated) and the resulting file name,
On 3/22/2011 9:51 PM, "Martin v. Löwis" wrote:
Pressing that button seems to create a duplicate patch, which is not
good. Given that there is no connection between the repository names
(which seem to be duplicated) and the resulting file name, there is no
way to tell whether to press the button o
> Pressing that button seems to create a duplicate patch, which is not
> good. Given that there is no connection between the repository names
> (which seem to be duplicated) and the resulting file name, there is no
> way to tell whether to press the button or what the result will be.
Don't worry a
On 3/22/2011 8:53 AM, Éric Araujo wrote:
I still don't understand what that's supposed to look like. Is it supposed
to be a URL which refers to my local repository?
No, to a repository published somewhere (hg.python.org, bitbucket (make
a server-side clone of mirror/cpython), any other hosting
On Wed, Mar 23, 2011 at 1:37 AM, wrote:
> Doesn't that just complicate my setup? Let's just consider the cpython repo
> (is that the right term? maybe branch instead?). Today, I have a local
> repository named "cpython" which refers to ssh://h...@hg.python.org/cpython as
> its default. Now you
On Tue, Mar 22, 2011 at 10:53 PM, Éric Araujo wrote:
> You have to use one public repo per bug, as roundup will only use the
> default branch to compute the diff. Maybe adding support for named
> branches so that you can have one repo used for many bug reports would
> be useful.
Since I run my s
> Senthil> You will have to 'push' your changes to those so that they are
> Senthil> publicly visible and then point that url in the bug-tracker.
>
> I can see this turning into a giant bowl of spaghetti. How in the world are
> people supposed to understand how all these repositories are
>> I still don't understand what that's supposed to look like. Is it
>> supposed to be a URL which refers to my local repository?
Senthil> No, it is the "Remote Repository". It could be one at
Senthil> bitbucket.org or code.google.com, both of which support
Senthil> creating
On 22 March 2011 12:53, Éric Araujo wrote:
>> I still don't understand what that's supposed to look like. Is it supposed
>> to be a URL which refers to my local repository?
> No, to a repository published somewhere (hg.python.org, bitbucket (make
> a server-side clone of mirror/cpython), any othe
> I still don't understand what that's supposed to look like. Is it supposed
> to be a URL which refers to my local repository?
No, to a repository published somewhere (hg.python.org, bitbucket (make
a server-side clone of mirror/cpython), any other hosting service).
You have to use one public re
On Tue, Mar 22, 2011 at 07:26:25AM -0500, s...@pobox.com wrote:
>
> Senthil> The magical UI is the FORM textbox element "Remote hg repo:"
> Senthil> where the user provided his bitbucket URL for the path he was
> Senthil> working on.
>
> I still don't understand what that's supposed t
Senthil> Have a look at this issue:
Senthil> http://bugs.python.org/issue11591
Senthil> The magical UI is the FORM textbox element "Remote hg repo:"
Senthil> where the user provided his bitbucket URL for the path he was
Senthil> working on.
I still don't understand what that'
> Don't know exactly how it's implemented, but I would guess it's using
> "hg incoming --patch" or similar, which would handle this transparently;
> the newer revisions at hg.python.org would just be ignored in generating
> the diff.
That doesn't work exactly: hg incoming --patch could generate mu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Senthil,
On 03/21/2011 09:57 PM, Senthil Kumaran wrote:
> - In the above issue, why is two same bitbutket urls are provided. (It
> is redundant).
I updated the patch, and the second time around the "remote hg repo" box
was empty. I wasn't sure wha
On Tue, Mar 22, 2011 at 9:02 AM, Guido van Rossum wrote:
> On Mon, Mar 21, 2011 at 5:10 PM, Éric Araujo wrote:
>> Le 13/03/2011 19:03, "Martin v. Löwis" a écrit :
>>> I've added a feature in the bug tracker where submitters can post
>>> Mercurial repository URLs, and then repeatedly create patche
On Mon, Mar 21, 2011 at 5:10 PM, Éric Araujo wrote:
> Le 13/03/2011 19:03, "Martin v. Löwis" a écrit :
>> I've added a feature in the bug tracker where submitters can post
>> Mercurial repository URLs, and then repeatedly create patches. Roundup
>> will extract the current patch (cpython-default:s
Le 13/03/2011 19:03, "Martin v. Löwis" a écrit :
> I've added a feature in the bug tracker where submitters can post
> Mercurial repository URLs, and then repeatedly create patches. Roundup
> will extract the current patch (cpython-default:submitter-default),
> and attach the patch to the issue (
I've added a feature in the bug tracker where submitters can post
Mercurial repository URLs, and then repeatedly create patches. Roundup
will extract the current patch (cpython-default:submitter-default),
and attach the patch to the issue (which then allows Rietveld review
of the patch).
Regard
27 matches
Mail list logo
