[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ITP: mercurial-buildpackage (for those who care about Mercurial)

2009/11/21 Goswin von Brederlow <goswin-v-b@web.de>:
> Jens Peter Secher <jps@debian.org> writes:
>> As I see it, there is no need for using Mercurial Queues (mq) with
>> mercurial-buildpackage because dpkg-source format "3.0 (quilt)" has
>> the same purpose as mq, namely to wrap around quilt to achieve
>> automatic patch handling.
> Not quite. The Mecurial Queues are under version control. That means
> I can check out last months patch series, bisect changes, see who
> changed what when and so on.

Hmm, the debian/patches/ are also under version control.

I am afraid I still do not see a real difference...

> All in a way mercurial users are use to.

...except for the above (assuming Mercurial really are used to MQ).

> That means people have to use quilt and mercurial. With mercurisl
> queues you would have only mercurial and the quilt part is hidden.
> I'm not saying mercurial queues should be forced onto the user but I
> think it would be nice to support them.

Sure, but I do not know how to do that at the moment. :-)

> pristine-tar does not put the tarball into the repository. It only
> stores the delta between taring up the upstream branch and the actual
> upstream orig.tar.gz. That way you can clone a repository and build
> without first having to go hunting around for the orig.tar.gz.
> Please look at it and look how git-buildpackage uses pristine-tar.

Heh, I started implementing support for pristine tarballs yesterday,
but now I realise that pristine-tar is a package.  Well, that makes
things a lot easier.  I will incorporate it.

                                                    Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?

Reply to: