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.
Cheers,
--
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: