This is the mail archive of the
mailing list for the Cygwin project.
Re: juggling patches...
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: Max Bowsher <maxb at ukf dot net>
- Cc: Robert Collins <rbcollins at cygwin dot com>, <cygwin-apps at cygwin dot com>
- Date: Wed, 19 Mar 2003 18:49:13 -0500 (EST)
- Subject: Re: juggling patches...
- Reply-to: cygwin-apps at cygwin dot com
On Wed, 19 Mar 2003, Max Bowsher wrote:
> 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
> final merge.
> > patches have history.
> At some point, excess history becomes clutter, though.
> > work-in-progress can be easily reviewed.
> Is it really any easier?
I tend to agree with Max here (even though I have a broadband connection).
I'm *really* wary of touching remote repositories. And we could use
mailing list archives for patch history. ;-) Also, I'd rather be aware of
the conflicts between patches as I'm developing them, rather than when the
time comes to apply them to HEAD... So thanks for the offer, Rob, but I
don't think I'll be using it anytime soon...
|\ _,,,---,,_ pechtcha at cs dot nyu dot edu
ZZZzz /,`.-'`' -. ;-;;,_ igor at watson dot ibm dot com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!