Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
On (16/05/07 13:52), Magnus Holmgren wrote:
> svn-buildpackage has a feature called "mergeWithUpstream mode", which means
> that only the files that are actually touched are put under version control
> (I thought most $TLA-buildpackage would have something similar, but it seems
> to be unique to svn-buildpackage).
bzr-builddeb has this feature, it is known as merge mode there. The
README explains how to set it up, if not please file a bug.
It also has a couple of other modes that are useful if you have other
aims.
> This works well when all the differences
> are kept inside the debian directory. The Exim maintainers work this way, for
> example. But since svn checkout doesn't give you the whole thing, how do you
> prefer to work (especially with respect to creating patches)? Do you unpack
> the orig tarball on top and set the svn:ignore property to ".", or always use
> svn-buildpackage --svn-ignore? Or do you find it easy enough to use
> dpatch-edit-patch --debianonly? Other comments?
svn-buildpackage now includes svn-do (in /usr/share/doc I think) that
allows you to execute an arbitrary command in the full source tree.
> I my dreams you can tag individual commits and the VCS lets you extract
> separate patches, even if there are several commits with a certain tag,
> intermingled with commits with other tags. Dropping a particular patch (tag)
> (when merging with a new upstream version) will be easy, even if there are
> overlaps between patches. This should work well with the new W&P source
> package format, and you get the best of both worlds. Maybe some of this is
> already possible?
>
Someone mentioned stgit, and there's mercurial queues that does the
same. These handle most of this well. What I would like to do is come up
with a system like one of these, but specialised for Debian packaging,
so that the patches are stored under debian/patches, and the information
about them is stored in the vcs. However I can't come up with a design
that I like, or even pin down the features that it should have properly.
Thanks,
James
--
James Westby -- GPG Key ID: B577FE13 -- http://jameswestby.net/
seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256
Reply to: