On Wednesday 25 November 2009 21:17:47 Hugo Mills wrote: > On Wed, Nov 25, 2009 at 05:11:48PM +0100, Andreas Gruenbacher wrote: > > On Tuesday 24 November 2009 17:05:50 Hugo Mills wrote: > > > If I'm doing development with quilt, I usually come to the point > > > where I want to commit the changes to subversion, and find the process > > > a bit awkward. So I wrote a quilt module to shift the bottom patch of > > > the stack into svn, taking the patch header as the commit message. > > > > This seems quite useful to me. Some comments: > > > > * The script duplicates a lot of code from the push command; those functions > > should be moved to patchfns instead. > > OK. > > > * I'd like the command to be able to just forget about a patch (or several > > patches) without actually committing them anywhere. > > Well, there's "quilt delete", which has slightly different > semantics. However, committing the changes to a null VCS would > effectively leave the changes sitting in the source tree but > unattached to any quilt patch.
This is also what happens when you commit a patch with your svn script except that the patch ends up in svn, no? > I don't think it's hard to provide the function, but I don't see a use > case for it off-hand. Maybe it's not very useful by itself after all. > > * Other version control systems like cvs, git, hg should be supported as > > well. > > It's been well over 10 years since I last used CVS, and I've only > ever used git and hg for checking out other people's projects. I'm not > sure I could do them justice, but I'll have a go. If it covers more > than just svn, what would a suitable name for it be? "apply", > "commit", "vcs-apply", "vcs", "vcs-commit" are all candidates. I think > I prefer "commit", of those options. "commit" sounds best of the names you have listed. Maybe somebody has yet a better idea. > It should, however, be possible to determine automatically which > VCS is in use, or complain if there's more than one present in the > current source tree. (And to force the use of a particular VCS through > a command-line option -- this would give you the interface to the > "forget" function, too: just use "null" as the VCS). Yes, makes sense. > > * Is it possible to commit an applied patch to svn (or cvs) even when other > > patches are applied on top? Quilt can compute what to commit under which > > filenames, but is svn add flexible enough to let quilt tell it what to do? > > (Git definitely is.) > > svn can do commits on a per-file basis, so in the case where no > other applied patches modify the files that this one does, yes, we can > do that. That's not always the case though. Also, you want to commit an entire patch, not just a single file. Is there a way to pass svn a list of (filename, actual file) tuples to commit or similar? > > > cat_file "$patch_file" \ > > > | patch_header > svn.commit > > > > Can svn read the commit message from stdin instead? > > I think so. I'll have a play. > > > > # Pop the top patch (the one to commit) > > > if ! quilt pop > > > then > > > exit $? > > > fi > > > > > > # Apply the patch outside quilt > > > cat_file "$patch_file" \ > > > | patch -p1 > > > > That's quite ugly. It also doesn't honor different strip levels, default patch > > and push options, etc. > > I thought that line might raise some eyebrows. :) > > The issue I had is that if I use quilt to apply the patch, then > commit the changes to svn and remove the patch from the series file, > there's still a pile of files in .pc that need to be cleaned up. I can > steal the clean-up code from "pop" and move that into patchfns? That would be much cleaner, yes. > > > # Remove the patch from the patch stack > > > if remove_from_series "$patch" > > > > Can the patch be commented out in the series file instead of removing it? > > That should be possible. Is there an existing function to do that, > or should I simply duplicate and modify remove_from_series (or > rename_in_series)? Not sure if an existing function can be abused for that ... Thanks, Andreas _______________________________________________ Quilt-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/quilt-dev
