Re: [Quilt-dev] New function: Shift bottom patch to subversion

[Andreas Gruenbacher]

On Wednesday 25 November 2009 18:46:40 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