This is the mail archive of the
mailing list for the Cygwin project.
Re: juggling patches...
- From: "Max Bowsher" <maxb at ukf dot net>
- To: "Robert Collins" <rbcollins at cygwin dot com>,<cygwin-apps at cygwin dot com>
- Date: Wed, 19 Mar 2003 23:41:44 -0000
- Subject: Re: juggling patches...
- References: <1048033757.5299.6.camel@localhost>
Robert Collins wrote:
> As we have multiple reviews of patches going on, overlapping patches
> will naturally conflict...
> So, I'm repeating an offer made here a long while back: cvs branches can
> be used for developing patches.
> i.e. maxb_UserSettings would be a branch of setup for Max to work on
> user settings.
Thanks for the offer - but I won't be doing this:
I'm currently restricted to dialup internet until I return to university -
CVS operations are just too slow.
Plus, I already get the functionality of cvs merging, by keeping one working
directory per project.
And lastly, I'm always somewhat cautious about touching a remote repository.
For example: I had to get Chris to run some cvs admin commands for me
> Scripts for branch creation and removal are in the cygwin CVS tree.
> If you don't have CVS access write access, don't have a local CVS copy
> of setup, or want to use the sources.redhat.com tree for branched
> development, get my ok, and then fill out the form referenced here a
> week or so ago.
> How it helps?
> Using Igor's work as an example, each patch gets it's own branch.
> i.e : igor_ScriptLogging and igor_ScriptOrdering
> Then as each patch develops, it just gets checked in, along with extra
> files etc.
> As HEAD changes, the patch can be syncronised via a cvsmerge HEAD
> command. (See the scripts :}).
> When the patch is ready, anyone with HEAD write permission (as opposed
> to HEAD write *access*)
What's the difference?
> :} can obtain the patch via a simple cvs rdiff,
> or use the cvsmkpatch script.
> Taken together this means:
> patches won't conflict with each other.
Well, they still will, but the conflicts will be more rigidly isolated until
> patches have history.
At some point, excess history becomes clutter, though.
> work-in-progress can be easily reviewed.
Is it really any easier?