Thoughts on 3.0 (quilt) and VCS workflows

[James Westby]

On Tue, 2 Mar 2010 11:25:25 +0000, Colin Watson <cjwatson at ubuntu.com> wrote:
> I thought some people here might be interested in the bug I just filed
> on dpkg-dev:
> 
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204

Interesting, thanks.

It matches some of my impressions.

Do you know if your hack is required for the lp:ubuntu/* branches, where
we store exactly what dpkg-source -x produces?

I assume this writes a .pc directory and so it would allow you
manipulate the patches directly.

That doesn't get us away from the larger issues though.

> This was independent of the discussion in
> https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2010-February/000508.html
> as I hadn't read that yet, but the second problem I mention in that bug
> is essentially the same thing.

Indeed. I think it might be trickier to solve the merging case, as you
have to reconcile differences in two stacks of patches. They come from
the same root issue though, storing redundant data essentially.

>  I realise the solution I propose isn't
> optimal given further bzr development, but I think it's the cleanest
> method that works right now even if the cost is losing bzr conflict
> resolution (which is annoying, but I'd rather that than have to mangle
> quilt patch files by hand or accidentally mis-refresh a quilt patch to
> include the upstream diff or any of the other things that can go wrong
> when you confuse quilt about its base file contents).  Thoughts?

It is probably the best way, you are right.

I would love to improve this situation, but it requires some rather
large changes to bzr to be able to do this well.

I would be happy to implement an interim solution that didn't prejudice
the long-term solution too much.

Thanks,

James