quilt-dev
[Top][All Lists]
Advanced

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

Re: [Quilt-dev] [patch] Quilt support for committing patches to CVS.


From: Jason M. Felice
Subject: Re: [Quilt-dev] [patch] Quilt support for committing patches to CVS.
Date: Wed, 11 Aug 2004 16:07:37 -0400
User-agent: Mutt/1.3.28i

On Wed, Aug 11, 2004 at 02:37:31PM -0500, Dean Roehrich wrote:
> >From:  Joe Green <address@hidden>
> 
> >Yes, I figured changes like this would not be accepted in this form. 
> >Looking at the various patches should make it easy to figure out where 
> >the hooks need to go, though.
> 
> I think most of us have been keeping these patches to ourselves for that same
> reason.  Now that three have been presented we can see a variety of
> requirements.
> 
> Your patch expects CVS to manage the series file and the individual patch
> files rather than the files being patched.  It has hooks in
> fork/delete/import/refresh/patchfns to coordinate with CVS before modifying
> the series file or any patch file.  Your "quilt commit" commits the series
> file and all patch files to CVS and does not allow the user to specify that
> only a particular patch file or only the series file should be committed.
> 
> Jason's patch presumably requires that "quilt commit" be manually run for each
> file that will be patched by the next "quilt push".  (Again, my knowledge of
> CVS is very thin.)  It also implies that the series file and the individual
> patch files are _not_ managed by CVS.  He does not have hooks in other parts
> of quilt to attempt any kind of coordination with CVS.
> 
> My patch expects the SCM to manage the files being patched, and currently does
> not expect the series file or the individual patch files to be managed by the
> SCM.  I have hooks in add/apatch/patchfns to make quilt coordinate with the
> SCM, and it also determines which SCM is being used so it can issue the
> appropriate commands.
> 
> There's not a lot of overlap here; we're almost solving three different
> problems and I think we have at least two very different ideas of what a
> "commit" is all about.  Maybe I need someone CVS-savvy to elaborate on how
> Jason's "commit" command is used...am I understanding it correctly?

I think so.  I contribute to some OSS projects that use CVS and I use
CVS internally at my company, but I much prefer
patches-as-first-class-objects.  So I use quilt to work on my changes on
the CVS repository, and I make certain that I don't "cvs add" new files,
or "cvs remove" files I delete (after all, I might shelve a patch to
work on something else, mail that patch for review, work on a third
thing and commit that).  The idea is that quilt does all the work to get
the patch into the repository the right way.

This is really useful when someone mails me a patch for some piece of
software I'm maintaining.  It is normally an issue with CVS because CVS
doesn't detect added or removed files as changes (added files are ignored and
removed files are assumed to be "missing" and regenerated with the next
update), and it was quite common when flinging large patches at an OSS
maintainer who uses CVS to find that he didn't cvs add files in your
patch.

On a separate note, though, I really like the idea of tracking the
contents of `patches' in CVS, though :)

> 
> Dean

-- 
 Jason M. Felice
 Cronosys, LLC <http://www.cronosys.com/>
 216.221.4600 x302




reply via email to

[Prev in Thread] Current Thread [Next in Thread]