Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
On Wed, 16 May 2007 13:52:28 +0200, Magnus Holmgren [EMAIL PROTECTED] wrote: 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? I usually use dpatch-edit-patch, but when I have more extensive changes in the queue, I unpack the upstream sources besides the debian/-only trunk and symlink debian into the upstream sources. This is a field full of dragons, though. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
On Wed, 16 May 2007 13:52:28 +0200, Magnus Holmgren [EMAIL PROTECTED] wrote: 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 I do svn-do zsh when I plan to work on a lot of patches; this spawns my shell and will copy back the debian tree over the SVN checkout from which I ran svn-do (this script is in /usr/share/svn-buildpackage/contrib), but only if the exit status is 0. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
tjena magnus, just a quick anecdotal experience to throw into the thread... for all its strengths and weaknesses, i'm pretty happy with svn-buildpackage, mergeWithUpstream, and a debian/patches dir. for a long time my biggest issue with this was having to maintain these patches across upstream changes, or introduce new patches. i (and i'm sure others) expressed this to the svn-buildpackage peeps, who responded with the svn-do command (dig around in /usr/share to find it), which i now use on a regular basis. svn-do + quilt has more or less[1] removed the annoyances of debian-only + debian/patches in svn. sean [1] there's still the issue of clutter left behind in build-area, but nothing a cronjob can't fix up. signature.asc Description: This is a digitally signed message part
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
On Wednesday 16 May 2007 14:52, Marcus Better wrote: Magnus Holmgren wrote: Now, how do you combine these? Several people have thought: The VCS can handle the changesets. Putting patches under VCS is silly! I fully agree. Unfortunately Subversion doesn't make it easy for you. You can keep your patches in different feature branches, but it gets messy since Subversion doens't keep track of merges. Is there any fundamental misdesign in Subversion that prevents that from being implemented somewhere in the future? -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgp0xd84EkbeK.pgp Description: PGP signature
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Le jeudi 17 mai 2007 à 13:12 +0200, Magnus Holmgren a écrit : On Wednesday 16 May 2007 14:52, Marcus Better wrote: Magnus Holmgren wrote: Now, how do you combine these? Several people have thought: The VCS can handle the changesets. Putting patches under VCS is silly! I fully agree. Unfortunately Subversion doesn't make it easy for you. You can keep your patches in different feature branches, but it gets messy since Subversion doens't keep track of merges. Is there any fundamental misdesign in Subversion that prevents that from being implemented somewhere in the future? You can use one of the svnmerge scripts instead of svn merge to do things the git way. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
On Thursday 17 May 2007 05:12:52 Magnus Holmgren wrote: On Wednesday 16 May 2007 14:52, Marcus Better wrote: Magnus Holmgren wrote: Now, how do you combine these? Several people have thought: The VCS can handle the changesets. Putting patches under VCS is silly! I fully agree. Unfortunately Subversion doesn't make it easy for you. You can keep your patches in different feature branches, but it gets messy since Subversion doens't keep track of merges. Is there any fundamental misdesign in Subversion that prevents that from being implemented somewhere in the future? No, merge tracking has been in the Subversion roadmap for a long time, but has been lower priority than other things. However, merge tracking is now one of the highest priorities. Basic merge tracking is scheduled to be in the next release; more enhancements will follow. -- Wesley J. Landaker [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpe1ImNx2h76.pgp Description: PGP signature
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Hi On Wed, 16 May 2007 13:52:28 +0200 Magnus Holmgren [EMAIL PROTECTED] wrote: Now, how do you combine these? Several people have thought: The VCS can handle the changesets. Putting patches under VCS is silly! Maybe it is. What's for certain is, that to someone who just does 'apt-get source', the VCS gives no benefit. However, he can read debian/copyright and debian/README.Debian to find out where the maintainer keeps his repository, and reap all the benefits (I can see how a distributed system could benefit downstream maintainers in particular). XS-Vcs headers are for this. You can then see VCS location also in PTS, e.g. http://packages.qa.debian.org/sonata. My question here is: *Whom* is debian/patches *for*? The maintainer or anyone who wants to build a customised package, audit the package, etc? svn-buildpackage has a feature called mergeWithUpstream mode, which means that only the files that are actually touched are put under version control I really like this feature. I have only debian directory in svn and possible patches are in debian/patches. The .diff.gz is then a bit harder to read, but after applying it is easier to get overview of package. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Magnus Holmgren [EMAIL PROTECTED] wrote: Now, how do you combine these? Several people have thought: The VCS can handle the changesets. Putting patches under VCS is silly! Maybe it is. I don't agree. With patches in debian/patches, you can give names to those files. Names that explain what they do, and in debian/changelog you'll use those names when closing bugs or documenting other changes. That makes it much easier to remember why a change was made, and to reuse the changes elsewhere (hand them over to upstream, Ubuntu, SuSE or you mom, or just decide whether it's still needed in the development branch). Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Magnus Holmgren wrote: Now, how do you combine these? Several people have thought: The VCS can handle the changesets. Putting patches under VCS is silly! I fully agree. Unfortunately Subversion doesn't make it easy for you. You can keep your patches in different feature branches, but it gets messy since Subversion doens't keep track of merges. However, he can read debian/copyright and debian/README.Debian to find out where the maintainer keeps his repository, Or check the PTS, if you use XS-Vcs-* control fields. I my dreams you can tag individual commits and the VCS lets you extract separate patches, Have you looked at stgit? Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
On Wednesday 16 May 2007 14:52, Marcus Better wrote: However, he can read debian/copyright and debian/README.Debian to find out where the maintainer keeps his repository, Or check the PTS, if you use XS-Vcs-* control fields. Yeah, I suppose I didn't know that when I started writing my post a while ago. I my dreams you can tag individual commits and the VCS lets you extract separate patches, Have you looked at stgit? I have now. IIUC, it lets you group and name diffs vs. a particular state of the source code, but the end result is a normal .diff.gz, meaning that everyone else has to use stgit too to get all the benefits, right? -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpce1QkD9DWi.pgp Description: PGP signature
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Marcus Better [EMAIL PROTECTED] wrote: Frank Küster wrote: The VCS can handle the changesets. Putting patches under VCS is silly! I don't agree. With patches in debian/patches, you can give names to those files. With a VCS you can also name branches, or changesets (stgit). Personally, I don't like branches very much. Nobody ever explained to me a good receipe to handle them in the case where development proceeds in both, and important fixes are copied from one to the other. Or is there a VCS which would show me a three-way diff: What has changed between the branching point and the branch's latest revision, except those changes which also happened between the branching point and HEAD? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Magnus Holmgren wrote: I have now. IIUC, it lets you group and name diffs vs. a particular state of the source code, but the end result is a normal .diff.gz, meaning that everyone else has to use stgit too to get all the benefits, right? Yes. People working on the same project team should use the same tools anyway. For external people, such as when sending patches upstream, it is trivial to extract patches. It wouldn't be difficult to hack up a web frontend that presents the patches in a nice way. Don't know if it exist already. Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Frank Küster wrote: Personally, I don't like branches very much. Nobody ever explained to me a good receipe to handle them in the case where development proceeds in both, and important fixes are copied from one to the other. I believe git handles that, it should work nicely in most cases. Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 WP 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)T0AM - secp256r1/nistp256 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Frank Küster wrote: Personally, I don't like branches very much. Nobody ever explained to me a good receipe to handle them in the case where development proceeds in both, and important fixes are copied from one to the other. http://youtube.com/watch?v=4XpnKHJAok8 is good to view if you're interested in how the branching can work, using git. Best regards, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
