Re: juggling patches...

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

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
> recently.
>
> > 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?
> Max.

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...
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		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!
  -- /usr/games/fortune