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

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

> 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.



  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: